Waarom je AI-assistent misschien gevaarlijker is dan je denkt

Stel je voor: wekenlang heb je je ontwikkelomgeving hermetisch afgesloten. Containers met strikte seccomp-profielen, geen uitgaand netwerkverkeer, alleen-lezen bestandssystemen, en procesniveau-beveiliging waar je maar kunt. Je AI coding assistant zit behind meer sloten dan menig productiesysteem. Dus waarom kijkt je securityteam nog steeds bezorgd tijdens sprint reviews?

De ongemakkelijke waarheid? Je hebt het verkeerde probleem opgelost. Of in elk geval: slechts de helft ervan.

Twee fundamenteel verschillende beveiligingsconcepten

Hier is het onderscheid dat er toe doet: host isolation en authority isolation zijn totaal verschillende beveiligingseigenschappen die in teamgesprekken maar blijven door elkaar worden gehaald.

Host isolation draait om het indammen van code-uitvoering. Denk aan containers, microVMs, netwerksegmentatie en bestandssysteembeperkingen. Het beantwoordt de vraag: "Als dit proces roekeloos wordt, hoe ver kan het komen op deze machine?"

Authority isolation gaat ergens anders over: "Wat kan dit proces doen via legitieme APIs en vertrouwde control planes?"

En hier wordt het spannend. Een AI-agent hoeft helemaal niet uit je container te ontsnappen of je kernel te compromitteren om flinke schade aan te richten. Met een GitHub-token met write-toegang kan hij naar main mergen. Met cloud credentials kan hij infrastructuur draaien of productiedatabases verwijderen. Met toegang tot je mailbox kan hij wachtwoordresets onderscheppen en van daaruit naar tientallen andere systemen pivoteren.

In de praktijk zullen de meest schadelijke incidenten met AI coding assistants er helemaal niet uitzien als klassieke host compromises. Het zijnperfect geautoriseerde acties, uitgevoerd in de verkeerde context — of door een agent die de volledige implicaties niet overziet.

De credential-surface die niemand in kaart brengt

De meeste teams redeneren over AI-agent credentials alsof het om secrets in een .env-bestand gaat. Ze denken: "We hebben die credentials niet expliciet doorgegeven, dus de agent heeft ze niet."

Die aanname missen de realiteit van moderne ontwikkelworkflows. Hedendaagse IDEs en ontwikkelomgevingen komen voorverwarmd met authenticatiestate. Je CLI-tools zijn al ingelogd. Je browsersessies zijn actief. Je CI/CD-pipelines hebben tokens in repository secrets zitten. Je MCP-servers proxyen capabilities waar je misschien niet eens weet van hebt.

Wanneer je een AI coding assistant toegang geeft tot je ontwikkelomgeving, geef je hem vaak een heel constellation van credentials waar een penetration tester jaloers op zou zijn.

Laten we doorlopen wat er echt toe doet:

GitHub-tokens en GitHub App-permissies

Scope is alles. Een token met alleen repo:read-toegang is fundamenteel anders dan een met contents:write, pull_requests:write of organisatiebrede permissies. Het principe van least privilege betekent dat GitHub-agent-permissies standaard task-scoped en repo-bounded moeten zijn — geen org-brede tokens, geen admin-toegang tenzij echt noodzakelijk voor specifieke administratieve taken.

Package Registry Credentials

npm, PyPI, crates.io en vergelijkbare registries zijn distributiekanalen. Een gecompromitteerd publish-token kan kwaadaardige artifacts naar duizenden downstream consumers sturen, zelfs als je source control brandschoon blijft. Dit is supply chain risk dat buiten je normale security perimeter leeft.

Cloud Platform Credentials

AWS, GCP, Azure — access keys, service account credentials, federated sessions en managed identities vertalen zich allemaal naar infrastructuur-authority wanneer ze bereikbaar zijn voor een agent runtime. De blast radius van gecompromitteerde cloud credentials kan ver reiken, ver voorbij je directe infrastructuur.

E-mail en communicatietools

E-mail is meta-authority. Met toegang tot je inbox of SMTP-capabilities kan een agent wachtwoordreset-links onderscheppen, teamleden impersoneren in workflows, en communicatie gebruiken als pivot-punt naar andere systemen. Het vertrouwen dat we in e-mail hebben opgebouwd maakt het bijzonder gevaarlijk in de verkeerde handen.

Browsersessies en OAuth-tokens

Actieve browsersessies omzeilen vaak свежие MFA-prompts, waardoor al geauthenticeerde state wordt overgedragen. Een agent met browser-toegang of opgeslagen OAuth-tokens heeft effectief dezelfde toegang als jij na het doorlopen van multi-factor authentication — geen aanvullende verificatie nodig.

CI/CD Pipeline Identities

Je continuous integration en deployment tokens zijn operationele credentials. Ze kunnen builds draaien, artifacts injecteren, release flows modificeren en naar productie deployen. Sommige teams behandelen CI-credentials als low-risk omdat ze "alleen maar tests draaien," maar moderne pipelines hebben vaak veel bredere capabilities.

MCP Server Connections

Model Context Protocol servers zijn central geworden in AI-assisted development workflows, en hun security is nu kritisch in plaats van optioneel. MCP-tools kunnen de authority van een agent amplifiëren door te proxyen naar systemen die de agent anders niet zou kunnen bereiken — vaak zonder expliciete disclosure van wat die systemen zijn of welke operaties ze mogelijk maken.

SaaS API Keys

Jira, Slack, Notion, Linear en tientallen andere SaaS-tools exposen allemaal API keys die organization-wide side effects creëren wanneer ze gecompromitteerd raken. Ticket churn, notificatie-abuse, data-exposure en social engineering-kansen liggen allemaal op tafel.

Het echte risico is niet theoretisch

Security researchers hebben deze gap concreet gedemonstreerd. Onderzoek naar privilege escalation paths heeft transitions laten zien van low-privilege access naar admin-level control via credential chains — inclusief paths die MCP server-verbindingen en vergelijkbare integratiepunten benutten.

Aan de andere kant van het spectrum ligt een even belangrijke observatie: autonome systemen hebben steeds vaker directe geauthenticeerde productie-toegang nodig om echte waarde te leveren. Een AI coding assistant helemaal op slot gooien kan hem nutteloos maken voor precies de taken waarvoor je hem nodig hebt.

Dit creëert een genuïne architecturale tension die geen cleane oplossing heeft. Je kunt niet tegelijkertijd eisen dat een AI-agent behulpzaam genoeg is om betekenisvolle workflows te automatiseren én hem tegelijkertijd verhinderen om authority te hebben om op die workflows te acteren.

Praktische richtlijnen voor teams

Wat betekent dit in de praktijk? Een paar principes die het overwegen waard zijn:

Map je daadwerkelijke credential surface voordat je AI-agents inzet. Doe een credential audit. Wat zijn alle systemen die je agent theoretisch kan bereiken via je ontwikkelomgeving? dát is je echte attack surface.

Pas defense in depth toe op credential-toegang. Vertrouw niet op een enkele beschermingslaag. Als een agent cloud-toegang nodig heeft, scope het dan nauw. Als hij GitHub-toegang nodig heeft, gebruik tokens met minimale permissies. Als hij moet integreren met MCP-servers, begrijp dan welke capabilities die servers proxyën voordat je ze verbindt.

Scheid agent-omgevingen van productie-contexten waar mogelijk. Ontwikkel- en staging-credentials zouden niet dezelfde moeten zijn als productie-credentials. Een agent die in een ontwikkelcontext werkt, zou geen pad naar productiesystemen moeten hebben.

Behandel AI-agent security als een continu proces, niet als een eenmalige configuratie. Naarmate je workflows evolueren en nieuwe tools worden geïntegreerd, verandert je credential surface. Regelmatige audits zijn essentieel.

Wees expliciet over wat je autoriseert. Wanneer je een nieuwe MCP-server verbindt of een nieuwe permissie verleent aan een AI-agent, documenteer waarom. Begrijp welke capabilities je toevoegt aan de authority van de agent.

Het grotere plaatje

De AI coding agent space evolueert snel, en security practices hebben moeite om het bij te benen. We zijn goed geworden in praten over runtime boundaries en sandboxing — maar over wat we deze agents via legitieme kanalen laten accessen, zijn we nog te nonchalant.

Container hardening doet ertoe. VM-isolatie doet ertoe. Maar geen van beide addresseert het authority-probleem, en dát is waar de echte risico's leven.

De teams die dit succesvol gaan navigeren, zijn degenen die beginnen met nadenken over AI-agent security in termen van zowel waar deze agents draaien als wat ze kunnen accessen via de systemen waarmee we ze vertrouwen. Het is niet het een-of-het-ander. Het is beide, samen — en begrijpen dat dit onderscheid is de eerste stap naar het bouwen van veiligere AI-assisted development workflows.

De sandbox is pas het begin van het gesprek.