Het idee achter Bring Your Own Agent is simpel: medewerkers gebruiken hun eigen persoonlijke AI-assistenten en laten die helpen bij werk. In de praktijk betekent dit dat die assistenten—vaak zonder ticket of IT-proces—al snel verbinding maken met bedrijfsapplicaties en gegevens. En daarmee verplaatst de veiligheidsuitdaging zich: niet langer alleen over ‘welke devices’ of ‘welke apps’, maar over wie de rechten heeft en hoe die rechten worden gecontroleerd.
De beweging is de afgelopen maanden alleen maar zichtbaarder geworden. Sommige AI-agenten richten zich op consumenten, andere op ondernemingen, maar in beide gevallen geldt: een persoonlijke agent kan via toestemming, credentials of een lokale installatie toegang krijgen tot werkomgevingen. Daarom is identiteit—en het beheer ervan—de kern van een haalbare aanpak.
Waarom Bring Your Own Agent zo lastig is
Bij Bring Your Own Device (BYOD) gaat het om apparaten. IT kan die inschrijven, beleid opleggen en daarna beheren. Bij Bring Your Own Agent is het anders: een AI-agent is geen ‘normale’ applicatie die je even registreert. De agent draait mogelijk op de computer van de medewerker, in de cloud van de leverancier, of als koppeling binnen een browser. Daardoor is het vaak onduidelijk of je als organisatie al verbonden bent, en via welke mechanismen.
De risico’s zitten niet alleen in het feit dat de omgeving mogelijk minder veilig is. Het grotere punt is dat de agent handelt in de naam van de gebruiker. Daarmee kan toegang tot systemen en workflows meeliften, ook als jij die agent nooit expliciet hebt goedgekeurd.
Hoe persoonlijke AI-assistants toegang krijgen tot je systemen
Wie vandaag een persoonlijke agent koppelt aan werk, doet dat in veel gevallen zonder dat IT ergens voor wordt benaderd. In plaats daarvan gebruiken gebruikers het vertrouwde pad van app-koppelingen en accountmachtigingen. Denk aan de volgende routes:
- OAuth-toestemming: de agent vraagt toegang aan diensten zoals Google Workspace, Microsoft 365 of Slack, waarna de medewerker op ‘Allow’ klikt.
- Tekst- of chatkoppeling: sommige agenten werken via een tekstapp en koppelen daarna met externe accounts (bijvoorbeeld via gekoppelde Google-, Apple- of Facebook-identiteiten).
- Saved passwords: agents kunnen in ondersteunde omgevingen inloggen met wachtwoorden die in de browser of een interne password manager zitten. Voor de bedrijfsapp lijkt het dan alsof de medewerker zelf aan het inloggen is.
- API keys en personal access tokens: bij onofficiële integraties kunnen agenten met langdurige credentials werken die de gebruiker zelf moet aanmaken.
- Lokaal geïnstalleerde agents: een agent draait op de laptop en kan toegang krijgen tot wat die machine mag zien. Voorbeelden zijn lokale agent-software die bestanden, notities of e-mail verwerkt met toestemming, en AI-browsers die geopende pagina’s kunnen uitlezen en vervolgens tools zoals Slack of Gmail aansturen.
Voor beveiliging betekent dit: je ziet niet alleen ‘een nieuw apparaat’. Je krijgt nieuwe identiteiten, tokens, sessies en autorisaties die onderdeel worden van je cloud- en SaaS-ecosysteem.
Welke typen Bring Your Own Agent bestaan er?
Hoewel de categorie nog jong is, beginnen zich al varianten af te tekenen. Sommige agents zijn meer gericht op zakelijke omgevingen; andere zijn duidelijk consument-first. Maar zelfs als de leverancier beheertools belooft voor managed deployments, komt het echte probleem bij persoonlijke agents vaak buiten het adminoverzicht terecht.
In grote lijnen kun je onderscheid maken tussen:
- Agents met zakelijke uitrolmogelijkheden: hierbij werkt de leverancier aan governance voor enterprise-gebruik. Dat helpt, maar vervangt niet automatisch het beheer van rechten per medewerker.
- Agents die via ontwikkeling of platformkeuzes binnen teams landen: bijvoorbeeld wanneer medewerkers tools gebruiken in hun ontwikkelworkflow die toegang tot diensten mogelijk maken.
- Consumentenagents die later werkconnectors krijgen: agents die oorspronkelijk voor privégebruik zijn bedoeld, kunnen in een later stadium connectors toevoegen richting tools die je op kantoor gebruikt.
- Lokale open-source of zelfgedraaide agents: dit type draait op de eigen machine van de gebruiker. Dat kan flexibiliteit geven, maar het maakt het ook lastiger om te bepalen waar de credentials en sessies vandaan komen.
Wat ze gemeen hebben: de agent is gekoppeld aan een identiteit of sessie die de medewerker kan beïnvloeden. Daar ligt de hefboom.
Van vendor-controls naar identiteit als control plane
Veel leveranciers bouwen ondertussen controls voor organisaties die hun agents managed inzetten. Dat is gunstig, maar die aanpak werkt vooral voor scenario’s waarin je ook daadwerkelijk binnen de corporate deployment blijft. Bij persoonlijke agents is dat niet altijd het geval.
Daarom is het verstandig om de agent niet als ‘een device of app’ te benaderen, maar als een externe entiteit waarvan jij de effecten wilt beheersen. Concreet betekent dat: kijk naar de accounts, grants, tokens en sessies die de agent binnen je systemen gebruikt.
Welke kant werkt het beste?
- Agents in de cloud of op een gecontroleerde server: dan kun je beter sturen op de uitgaande requests en policy-handhaving, omdat de context deels bij de leverancier ligt.
- Lokaal draaiende agents op laptops: dan blijven credentials lokaal, maar onderscheiden agents en gebruikers zich minder zichtbaar voor je cloud- en SaaS-logging. Je ziet vooral ‘gebruikersgedrag’ dat door een agent kan worden aangestuurd.
In beide gevallen blijft het uitgangspunt gelijk: identiteit is de control plane. Als je de identiteit en toegang goed beheert, wordt de impact kleiner—ook als de agent zelf van buiten komt.
Zo pak je Bring Your Own Agent praktisch aan
Een ideale situatie is dat medewerkers productiviteit behalen met hun persoonlijke assistent, terwijl de organisatie bepaalt hoe ver de agent kan gaan. Dat klinkt makkelijker dan het is, maar er zijn wel duidelijke fundamenten.
1) Maak je Shadow AI-inventaris zichtbaar
Begin met het ontdekken van bestaande koppelingen. Denk aan signalen zoals OAuth-grants van agentleveranciers, aanmeldingen vanuit cloud-ranges, langdurige API keys die je aan onbekende clients kunt koppelen en observaties vanuit security-telemetrie. Het doel: weten wat er al verbonden is, voordat je het beleid erop plakt.
2) Koppel elke agent aan een menselijk eigenaar
Als je rechten kunt herleiden naar een medewerker, kun je ook verantwoordelijkheid organiseren. Zonder eigenaar blijf je zoeken in logbestanden of merk je pas achteraf dat er iets mis is gegaan.
3) Geef de agent alleen het toegangsniveau dat nodig is
Een persoonlijke agent erft vaak wat de eigenaar kan. Maar de werkelijkheid is zelden dat de agent alles moet doen. Richt daarom de rechten proportioneel in: beperk tot een subset die past bij het werk dat de medewerker daadwerkelijk wil ondersteunen.
4) Ontkoppel bij vertrek: tokens, sessies en grants moeten mee stoppen
De grootste problemen ontstaan niet alleen door het starten van een koppeling, maar door het einde ervan. Als iemand het bedrijf verlaat, moeten autorisaties, tokens en sessies die zijn blijven doorlopen ook worden ingetrokken.
Dit vereist dus meer dan alleen accountdeactivering. Je moet ook de ‘bijbehorende’ rechten en verbindingen opruimen die de agent heeft opgebouwd.
De gaten die nog blijven bestaan
Zelfs met goede identity-aanpak blijven er technische en organisatorische uitdagingen. Zo is het nog niet altijd duidelijk of een login afkomstig is van een medewerker zelf of van de agent namens die medewerker. Ook het fijn compartimenteren van kennis en gedrag tijdens offboarding is nog niet overal opgelost.
Daarnaast is agent-tot-agent communicatie niet overal ‘volledig governable’. Dat betekent dat je beleid niet alleen moet richten op één agent, maar ook moet nadenken over mogelijke ketens in automatisering.
Interne richtlijn: blok niet alles, stuur op identiteit en toegang
Je kunt ervoor kiezen om persoonlijke agents massaal te blokkeren. Maar dat botst vaak met de realiteit: medewerkers gebruiken ze al, en veel organisaties zien aantoonbare productiviteitswinst. Een effectievere route is vaak om agentgebruik te blijven faciliteren, maar dan via gecontroleerde identiteit en toegangsregels.
In de praktijk kun je de impact verlagen door te zorgen dat tokens en grants aan de juiste eigenaar gekoppeld zijn, toegang worden ingeperkt en dat de agent wordt uitgeschakeld wanneer de medewerker wegvalt. Zo maak je het resultaat beheersbaar zonder de voordelen van Bring Your Own Agent meteen te saboteren.
Meer achtergrond: identity en training in cybersecurity
Als identity governance centraal staat, helpt het om breder te kijken naar hoe accounts en gedrag in je organisatie worden ingericht. Wil je die lijn doortrekken naar bewustwording en risicobeperking, dan kan ook dit onderwerp relevant zijn: Security awareness training: is het nog effectief?. En voor wie vooral naar aanvallen richting endpoints en beheeroplossingen kijkt, is het leerzaam om te zien hoe securityteams kwetsbaarheden prioriteren en afhandelen, bijvoorbeeld zoals beschreven in Derde-party agenten: AI-security mist vaak deze risico’s.
Conclusie
Bring Your Own Agent is geen theoretisch idee meer: persoonlijke AI-assistents sluiten zich aan op werkaccounts via OAuth, tokens, browser-credentials of lokale installaties. Dat maakt de klassieke aanpak—devicebeheer en app-registratie—onvoldoende. De oplossing ligt in identity governance: ontdek de koppelingen, wijs ze toe aan een eigenaar, beperk de toegang en zorg dat alles wordt ingetrokken bij vertrek.
Zo benut je de productiviteit van AI-agents, zonder dat je beveiliging het nakijken krijgt.
Bron: https://thehackernews.com/2026/10/bring-your-own-agent-your-employees.html
