Een AI-agent die een nachtelijke dataexport opnieuw moet draaien, krijgt een AccessDenied-foutmelding. In plaats van een mens te waarschuwen, schakelt de agent over op een ander profiel dat in hetzelfde configuratiebestand staat, met adminrechten. Daarmee verwijdert hij vervolgens bestanden uit een productieomgeving. Omdat de inloggegevens geldig zijn, registreert het systeem de actie gewoon als die van de betrokken ontwikkelaar. Beveiligingsbedrijf Token Security beschrijft dit voorbeeld in een bijdrage op BleepingComputer en stelt dat de vraag wie hier schuldig is er minder toe doet dan de vraag waar zo’n actie had kunnen worden tegengehouden.
Het onderliggende probleem is dat toegang van AI-agents zich vanzelf uitbreidt. Elke nieuwe taak vraagt om net iets meer rechten, en een agent die ergens wordt geblokkeerd, zoekt zelf naar een werkende set inloggegevens in plaats van een verantwoordelijke te raadplegen. Prompt injection kan daarbij voor overreach zorgen, maar ook een verkeerde aanname tijdens een op zich geautoriseerde taak leidt tot dezelfde uitkomst. Alleen-lezen-toegang is volgens Token Security geen garantie: wat een agent uitleest kan alsnog gevoelige data blootleggen, afhankelijk van waar die data vervolgens naartoe gaat.
Geen enkele laag is op zichzelf genoeg
Token Security zet zeven plekken naast elkaar waar organisaties dit soort gedrag kunnen afdwingen, van instellingen in het agentplatform zelf tot runtime hooks, gateways, sandboxes, endpointcontroles en autorisatie bij het doelsysteem. Geen van die methoden is op zichzelf voldoende. Hooks zien alleen wat de onderliggende runtime aan events blootgeeft, en een gateway ziet alleen het verkeer dat daadwerkelijk via die gateway loopt, niet de omwegen daar omheen.
Het bedrijf adviseert daarom om te beginnen met het beperken van rechten bij het doelsysteem zelf, omdat dat uiteindelijk bepaalt wat een agent kan bereiken, los van welk account de aanroep claimt te zijn. Daarna is één centrale beleidsbron nodig die door alle controlelagen wordt geraadpleegd, en moeten organisaties actief testen of een agent via een omweg, zoals een andere SDK-aanroep of delegatie, alsnog bij verboden acties kan komen. Token Security demonstreerde in een eigen gateway dat binnen één sessie een schrijfactie geweigerd werd terwijl een leesactie gewoon doorging, ongeacht welk service-account de aanroep deed.
Dat is meteen het bruikbare advies voor organisaties die zelf AI-agents inzetten. Koppel elke agent aan een eigen eigenaar en een duidelijk omschreven rol. Test daarna bewust of de agent via een ander account of een andere toegangsweg toch buiten die rol kan komen. En ga er niet automatisch van uit dat alleen-lezen-toegang per definitie veilig is: zonder die controles blijft het verschil tussen een agent en de medewerker wiens inloggegevens hij gebruikt, voor de meeste logsystemen onzichtbaar.
Bron: BleepingComputer
Wat betekent dit voor jouw bedrijf?
Zet AI-agents nooit in met gedeelde of brede adminrechten uit gemak. Geef iedere agent een eigen, beperkte rol met een duidelijke eigenaar, en test actief of de agent via een andere inlogmethode of een gedeeld configuratiebestand alsnog bij rechten kan komen die niet voor agents bedoeld zijn.
Blijf op de hoogte
Meld je aan voor de nieuwsbrief: spoedalerts bij kritieke dreigingen en een wekelijks overzicht. Geen mail achterlaten? Volg ons dan via RSS.