AI-agents raken twee keer zoveel data als u heeft goedgekeurd
Nieuw onderzoek onder 1.000 security- en engineering-medewerkers laat zien dat AI-agents in productie gemiddeld twee keer zoveel data benaderen als waarvoor toestemming is gegeven
Bij vier op de tien organisaties reiken agents buiten hun goedgekeurde scope. En 47% van de ontwikkelaars heeft al meegemaakt dat een agent instructies uitvoerde die in een webpagina of document verstopt zaten.
Dit is deel 5 in de OrangeGuard AI-beveiligingsserie. Lees ook prompt injection en AI-agent aanvallen en het governance-gat bij AI-agents.
De cijfers
1Password ondervroeg eind mei en begin juni 2026 1.000 security- en engineering-medewerkers bij grote Amerikaanse bedrijven. De resultaten zijn ongemakkelijk concreet:
| Bevinding | Percentage |
|---|---|
| Ontwikkelaars die AI-agents in productie draaien | 46% |
| Agents die gevoelige informatie kunnen bereiken | 71% |
| Organisaties waar agents data buiten hun goedkeuring bereiken | ~40% |
| Ontwikkelaars die agents permanente toegang geven | 40% |
| Ontwikkelaars die credentials hardcoden in scripts | ~25% |
| Ontwikkelaars die een agent onbedoelde actie zagen uitvoeren | 47% |
Over het geheel genomen raakten agents ongeveer twee keer zoveel data als waarvoor iemand toestemming had gegeven.
Het probleem in één quote
Een IT-operations manager bij een middelgroot bedrijf beschrijft het herkenbaar: "We hadden een AI-agent die data uit het verkeerde systeem haalde door te ruime toegangsrechten, wat leidde tot onjuiste rapportages die we lang moesten terugzoeken naar de bron."
Dit is het patroon: de agent doet precies wat hij mag. Het probleem is dat hij te veel mag.
Persistente toegang: de credentials blijven leven
40% van de ontwikkelaars geeft agents permanente toegang tot systemen en secrets, waardoor de toegang actief blijft nadat de taak is afgerond.
Dit is een fundamenteel verschil met menselijke toegang. Een medewerker die een taak afrondt, sluit zijn sessie. Een agent met persistente credentials houdt die toegang — dag en nacht, zonder toezicht, tot iemand hem intrekt.
De gewoonten die agents voeden komen voort uit hoe ontwikkelaars hun eigen secrets behandelen. Ongeveer een kwart hardcodeert credentials in scripts of configuratiebestanden.
Jason Meller, VP Product bij 1Password, vat het probleem scherp samen: "Beveiligingstools hebben twintig jaar lang mensen gevraagd om langzamer te gaan, en mensen hebben twintig jaar lang nee gezegd. De les is niet dat ontwikkelaars meer training nodig hebben. Het is dat het veilige het makkelijke moet worden, anders gebeurt het niet."
Prompt injection is geen theorie meer
47% van de ontwikkelaars heeft meegemaakt dat een agent een onbedoelde actie uitvoerde na het volgen van instructies die verstopt zaten in een webpagina, document, e-mail of tool-output.
Bijna de helft. Dat is geen randgeval — dat is een structureel kenmerk van hoe agents met externe content omgaan.
Het tweede onderzoek: de safety check die niets betekent
Op dezelfde dag publiceerde Help Net Security onderzoek van Novee Security dat een dieper architecturaal probleem blootlegt.
Elad Meged, founding engineer bij Novee Security, testte een aanvalsscenario tegen de eigen repositories van drie vendors, in de configuraties die die vendors standaard leveren. Een pull request komt binnen met een net bugrapport in de beschrijving. Een bot leest het voordat een mens dat doet, haalt er een paar shell-commando's uit, krijgt die goedgekeurd, en post de output terug in de thread. De maintainer leest de hele uitwisseling de volgende ochtend. De pipeline van Anthropic gaf secrets prijs. Elke organisatie die een van deze agents out of the box draait, loopt dezelfde blootstelling.
Waarom safety checks falen
Een agent is een model plus een harness. Het model genereert intentie. De harness zet die intentie om in shell-commando's, bestandslezingen, API-calls en netwerkverzoeken, en bevat de goedkeuringslogica, de tool-permissies, de padrestricties en de output-afhandeling.
Meged legt de kern van het probleem bloot: "Op dit moment nemen harnesses vroeg een veiligheidsbeslissing — 'dit commando is read-only', 'dit domein is vooraf goedgekeurd' — en downstream-componenten erven dat oordeel zonder te controleren of het in hun context nog geldt. Een read-only commando dat naar een publiek outputkanaal gaat, is in effect niet read-only. Een vooraf goedgekeurd domein dat door aanvallers gecontroleerde content serveert, is in de praktijk niet veilig."
"Het patroon herhaalt zich bij alle drie de vendors die we hebben getest, wat suggereert dat er een gedeelde architecturale aanname zit in hoe agent-harnesses industriebreed worden gebouwd."
Dit is geen bug bij één leverancier. Het is een ontwerppatroon dat de hele sector deelt.
Wat dit betekent voor Nederlandse organisaties
Het onderzoek is Amerikaans, maar de tooling is identiek. Nederlandse ontwikkelteams gebruiken dezelfde agents, in dezelfde standaardconfiguraties.
Drie directe consequenties:
De standaardconfiguratie is niet veilig genoeg
Organisaties die deze agents out of the box draaien, lopen dezelfde blootstelling. Wie erop vertrouwt dat de leverancier het wel geregeld heeft, vertrouwt op een aanname die door onderzoek is weerlegd.
Uw agent-toegang is waarschijnlijk ruimer dan u denkt
Als 40% van de organisaties agents heeft die data buiten hun goedkeuring bereiken, is de kans reëel dat dit ook voor uw omgeving geldt. De enige manier om dat te weten is auditeren.
Onder NIS2 is dit een zorgplicht-probleem
Vanaf 15 augustus verplicht de Cyberbeveiligingswet organisaties tot aantoonbare toegangscontrole. Een AI-agent met persistente credentials en ongecontroleerde datatoegang is aantoonbaar onvoldoende beveiliging.
Zes maatregelen die u nu kunt nemen
1. Inventariseer welke agents er draaien
Niet alleen de officieel goedgekeurde. Vraag ontwikkelteams welke agents zij in hun workflow gebruiken en met welke rechten.
2. Audit de daadwerkelijke datatoegang
Vergelijk wat een agent mag met wat hij daadwerkelijk benadert. Het verschil is waar uw risico zit.
3. Beëindig persistente credentials
Gebruik kortlevende tokens die na de taak verlopen. Als een agent 24/7 toegang heeft, heeft een aanvaller die ook zodra hij de agent compromitteert.
4. Behandel elke externe input als vijandig
Pull requests, issues, e-mails, webpagina's, documentatie — alles wat een agent leest kan instructies bevatten. Vertrouw geen enkele bron die niet volledig onder uw controle staat.
5. Valideer op elk punt, niet alleen bij de start
Het onderzoek laat zien dat vroege safety-beslissingen downstream onterecht worden overgenomen. Controleer bij elke stap opnieuw of de actie in die context nog veilig is.
6. Beperk output-kanalen
Een agent die intern data mag lezen én naar buiten mag publiceren, is een exfiltratiekanaal. Scheid leestoegang en publicatierechten.
Het bredere beeld
Gartner voorspelt dat 40% van de enterprise-applicaties in 2026 taakspecifieke AI-agents zal bevatten, tegenover minder dan 5% in 2025. De adoptiecurve is steil, de governance loopt achter.
Een Dark Reading-peiling vond dat 48% van de cybersecurityprofessionals agentic AI en autonome systemen nu identificeert als de gevaarlijkste aanvalsvector. Volgens IBM's Cost of a Data Breach Report kosten shadow AI-breaches gemiddeld $4,63 miljoen per incident — $670.000 meer dan een standaard breach.
De boodschap is niet dat AI-agents te gevaarlijk zijn om te gebruiken. Het is dat de standaardinstellingen niet veilig genoeg zijn, en dat organisaties de verantwoordelijkheid voor die configuratie niet kunnen uitbesteden aan hun leverancier.
Bronnen
- Help Net Security – Your AI agents can reach data no one approved
- Help Net Security – An AI agent can pass every safety check and still leak secrets
- Bessemer Venture Partners – Securing AI agents: the defining cybersecurity challenge of 2026
- OWASP LLM Top 10 2026
- NCSC – Cyberbeveiligingswet