Amazon weigert sinds kort toegang aan Meta’s persoonlijke AI-assistent Muse in zijn eigen systemen, omdat de tool zich tijdens het browsen niet als bot identificeert. Het is een klein incident, maar het staat niet op zichzelf. Instinct, een van de spraakmakendste nieuwe persoonlijke agents, ligt onder vuur vanwege het eigen privacybeleid, en vergelijkbare verhalen duiken op bij vrijwel elke aanbieder in deze categorie. Toch groeit de markt onverminderd door: minder dan een jaar na de eerste release van het nu OpenClaw genoemde opensource-project zetten grote techbedrijven vol in op het idee dat iedereen een eigen AI-assistent nodig heeft.
Voor werkgevers betekent dat één ding zeker: medewerkers koppelen hun persoonlijke agent aan werksystemen, met of zonder toestemming. Hun agent beheert al hun privéagenda, dus de werkagenda is de volgende logische stap. Niet voor de beveiliging van het bedrijf, maar voor het gemak van de medewerker.
BYOD, maar dan lastiger
Vergelijk het gerust met Bring Your Own Device, maar onderschat het verschil niet. Bij BYOD kreeg IT in elk geval een apparaat om te registreren. Een persoonlijke AI-agent draait op de server van de leverancier of verstopt zich in het eigen apparaat van de medewerker, en is dus nergens aan te melden. Het gaat in de kern om een identiteitsvraagstuk: soms heeft een agent een duidelijke eigenaar met beperkte rechten, soms gedraagt hij zich online als de medewerker zelf, en soms ontbreekt een traceerbare eigenaar helemaal.
Hoe een persoonlijke agent binnenkomt
Persoonlijke agents komen op verschillende manieren bij bedrijfssystemen binnen, meestal zonder dat daar ooit een ticket voor wordt aangemaakt:
- OAuth-toestemming: de agent vraagt toegang tot Google Workspace, Microsoft 365 of Slack, en de medewerker klikt op “toestaan”.
- Via een chatapp, zoals bij Instinct, dat werkt zodra een gebruiker zijn Google-, Apple- of Facebook-account koppelt.
- Opgeslagen wachtwoorden in de eigen browser van de agent, waardoor een dienst niet kan zien dat er geen mens inlogt.
- Losse API-sleutels en persoonlijke access tokens voor koppelingen die niet officieel worden ondersteund.
- Rechtstreeks vanaf de laptop van de medewerker, via een lokale agent of een AI-browser die meeleest met open tabbladen en verbinding maakt met Slack en Gmail.
Identiteit als aangrijpingspunt
Leveranciers bouwen intussen governance, maar alleen voor hun eigen, beheerde uitrol: bedrijfsaccounts, aparte identiteiten per taak, controlelagen die elk uitgaand verzoek checken. Dat werkt alleen zodra een organisatie de agent ook daadwerkelijk via die beheerde route heeft binnengehaald. Een medewerker die zijn eigen Muse, Dots of Instinct op eigen houtje koppelt, valt buiten elk van die consoles.
Volledig blokkeren is volgens beveiligingsonderzoekers niet realistisch, en gezien de productiviteitswinst ook niet per se wenselijk. Het aangrijpingspunt ligt daarom niet bij de agent zelf, maar bij de identiteit waarmee hij inlogt. De accounts, tokens en sessies die een persoonlijke agent gebruikt, zijn net zo goed zichtbaar te maken als bij elke andere koppeling met bedrijfssystemen, ook wanneer de agent zelf dat niet is.
Bron: The Hacker News
Wat betekent dit voor jouw bedrijf?
Breng in kaart welke AI-agents al toegang hebben tot je systemen, via OAuth-koppelingen, API-sleutels of inlogpogingen vanaf bekende cloudreeksen van agentleveranciers. Koppel elke gevonden agent aan een menselijke eigenaar, geef hem alleen de rechten die zijn taak vereist in plaats van de volledige rechten van die eigenaar, en zorg dat tokens en sessies automatisch vervallen zodra de medewerker uit dienst gaat. Volledig verbieden werkt niet: medewerkers gebruiken deze tools toch wel, zichtbaarheid via identiteit is het enige haalbare aangrijpingspunt.
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.