De meeste AI-securityprogramma’s starten met een goed idee: je kiest een AI-oplossing, je deployt die achter een gateway en je zet controles klaar voor wat je bewust hebt geadopteerd. In de praktijk schuift het echte risico vaak op naar een groep die je minder makkelijk ziet of beheert: derde-party agenten. Dat zijn agenten die niet uit jouw adoptiebesluit ontstaan, maar “meeliften” via updates of softwareplatformen die je al gebruikt.
Uit analyses in het State of Agent Security Report (2026) blijkt dat er in onderzochte omgevingen ongeveer 1.280 derde-party producten met AI in de organisatie draaien. Ongeveer 282 daarvan hangen achter single sign-on. De rest is in de basis minder zichtbaar voor je identity-infrastructuur: niet omdat iemand het verbergt, maar omdat je identity-stack doorgaans alleen kan sturen op authenticatiekanalen die er ook echt via lopen.
Waarom derde-party agenten buiten de “eerste-probleem” security vallen
“AI security” ging de afgelopen jaren vooral over het eerste scenario: een organisatie besluit tot AI, koopt licenties, zet een model achter een gekozen interface en laat security de controles richten op die expliciete keuze. Daardoor ontstaat er een logisch moment voor governance: iemand weet wat er is ingezet, waarna security kan instrumenteren en ownership kan beleggen.
Bij agenten ligt dat anders. Agenten komen vaak niet binnen via één zichtbaar adoptiebesluit, maar worden ingebouwd in software die je al draait. Je merkt het pas wanneer een functie live gaat, bijvoorbeeld in een product-update, of wanneer een platform een agent-component activeert in de workflow van gebruikers.
Een concreet voorbeeld: governance die “meeliften” wordt
In 2026 introduceerde Slack Code een manier om in een gesprek een coding agent te activeren door een gebruiker expliciet te taggen. In de aankondiging staat dat de agent de security-modellen, permissies en admin-controls van Slack zou “erven”. Dat klinkt als governance, maar vanuit security-oogpunt gaat het om een andere vraag: wat is er nou daadwerkelijk te instrumenteren?
Als het adoptie- en besluitmoment ontbreekt—en een agent functioneert als autonome actor binnen een bestaande chat-context—dan kan het zijn dat je securityteam vooral informatie krijgt over kanaal- en gebruikerscontext, maar niet over wat de agent vervolgens kan aanroepen, in welke omgevingen hij terechtkomt, en welke acties hij kan uitvoeren.
Drie manieren waarop agenten binnenkomen
Organisaties categoriseren agenten vaak grofweg als “gekocht” of “zelf gebouwd”. De analyses achter de derde-party agentproblematiek stellen een derde categorie centraal: agenten die je erft uit bestaande platforms.
- Erfde agenten: worden geleverd via productupdates in bestaande applicaties of platforms.
- Geconfigureerde agenten: draaien op basis van prompts en logica die jouw organisatie samenstelt, maar op een runtime, model en connectors van een ander.
- Gebouwde agenten: open frameworks die je end-to-end beheert op je eigen infrastructuur.
In veel omgevingen groeien vooral de eerste twee typen snel, juist omdat grote applicaties steeds vaker “agent platforms” worden. Gebouwde agenten zijn vaak kleiner in aantallen en groeien trager, maar daar is governance meestal makkelijker omdat er vaak een repo is om te scannen en een build-gate om keuzes te bewaken.
De bestemming is hetzelfde: de applicatielaag als werkgebied
Hoewel de herkomst verschilt, loopt het eindpunt van een agent vaak parallel. Een agent die vanuit een CRM is “geboren”, kan alsnog lezen uit een datawarehouse en vervolgens een ticketingsysteem aanpassen. Een agent die voortkomt uit een cloudplatform kan tokens bezitten om acties te doen in tools zoals Salesforce, Slack en Drive.
Met andere woorden: de agent speelt zich af op de applicatielaag, en daar liggen de grenzen niet altijd vast. Daardoor ontstaat een governance-kloof: de ene agent lijkt lokaal, maar kan in de praktijk doorverbinden naar externe systemen.
Vier vragen die helpen, ook als je de herkomst niet volledig kent
Elke agent bestaat grofweg uit twee delen: het model dat redenering ondersteunt en de “scaffolding” eromheen—dus de laag die bepaalt waarmee de agent verbonden is, wat hij mag aanroepen en wanneer hij handelt.
De kern van het risico zit volgens de analyses meestal niet in het model zelf, maar in die scaffolding en het ecosysteem waar hij op draait. Daarom gaan goede securityvragen niet over “wat zou het model uit zichzelf doen?”, maar over de omgeving en de bekabeling.
1) Connectivity: wat is de echte reikwijdte?
De eerste vraag draait om connectiviteit: hoe onderscheidt agent security zich van wat je al kent uit bestaande tools? Een vendor-questionnaire, promptfilters of modelscanners evalueren vaak iets in isolatie. De reach van een agent—wat hij kan bereiken—is vooral een eigenschap van zijn runtime-omgeving en configuratiecontext.
Bij derde-party agenten is die reach juist lastig, omdat authenticatie en identity-logging mogelijk niet volledig via jouw identity stack lopen. Het gevolg: je kunt de agent wellicht zien als feature in een applicatie, maar niet scherp genoeg als actor in je governancesysteem.
2) Scaffolding: welke acties kan hij daadwerkelijk uitvoeren?
De tweede vraag gaat over het “geraamte” rond het model. Welke connectoren zijn gekoppeld? Welke API’s of systemen zijn bruikbaar? En vooral: onder welke voorwaarden mag de agent ingrijpen, zoals het schrijven van data, het aanmaken van tickets of het aanpassen van rechten?
Door de scaffolding te beoordelen, maak je het verschil tussen “kan praten” en “kan handelen” zichtbaar. Bij agenten is dat verschil vaak groter dan teams verwachten.
3) Chains: via welke ketens loopt toegang door?
Agents kunnen handelen via tussenstappen. Dat maakt het nodig om te kijken naar ketens: kan de agent een actie starten die vervolgens in een andere workflow nog verder doorwerkt? Bijvoorbeeld door tokens te gebruiken om data op te halen, die data te verwerken en vervolgens downstream systemen te wijzigen.
Deze ketenlogica is vaak waar incidenten hun momentum krijgen, omdat de beveiliging in één schakel wel klopt, maar de totale keten te weinig wordt gemeten.
4) Change: wat verandert er sinds gisteren?
De vierde vraag gaat over dynamiek. Een agentomgeving verandert niet alleen door jouw releases, maar ook door updates van platformen en derde partijen. Daardoor kan een agent vandaag meer kunnen dan vorige week, simpelweg omdat een connector is toegevoegd of omdat een permissiemodel is aangepast.
Daarom past periodieke review met spreadsheets minder goed bij een omgeving waarin agenten voortdurend meebewegen.
Waarom grote buyers hun AI-inventarisatie als supply-chain risico zien
Patrick Opet, global CISO van JPMorgan Chase, benadrukte in 2025 dat de derde-party supply chain een structureel risico is geworden. In de jaren daarna werd diezelfde lijn doorgetrokken naar agenten: idealiter krijgt een agent wel een identiteit, maar zonder standaard entitlements. Vervolgens moet IT kunnen bevestigen wie of wat de agent namens zichzelf of namens een gebruiker mag doen, voordat hij buiten een afgebakende boundary raakt.
Wanneer een partij op dat niveau agenten expliciet als supply-chain risico benoemt, schuift die verwachting door naar de securityvragen die andere organisaties invullen bij leveranciers. Daardoor komen derde-party agenten steeds vaker terug in onboarding, due diligence en contractvoorwaarden.
Regelgeving verhoogt de druk om agenten te kunnen benoemen
Naast interne security komt er ook externe compliance. De EU AI Act legt in aanloop naar implementatieperiodes in 2026 de nadruk op het kunnen inventariseren van AI-systemen, eigenaarschap benoemen en toezicht aantonen. Het onderliggende uitgangspunt is helder: als je niet kunt opsommen welke agenten er draaien, kun je niet aantonen dat je governance werkt.
Daarom is een aanpak nodig die agenten niet alleen ziet als “een feature”, maar als governance-object: met eigenaar, gedrag, reikwijdte en actieroutes.
Wat “standing capability” praktisch betekent
Een proces waarmee je voor tientallen agenten met spreadsheets bijhoudt wat er draait, faalt bij honderden agenten. En met één update kan het aantal snel groeien: van vijfhonderd naar enkele duizenden is geen uitzondering meer. In die situatie heb je geen periodieke rapportage nodig, maar een live antwoord: continu bijgewerkt inzicht in wat er opereert, welke erfenis het agenttype heeft, hoe zijn reach is ingericht en wat hij sinds kort doet.
In de bronanalyse worden platforms genoemd die juist op dat principe zijn gebouwd: een grafische weergave die identiteit, applicaties, permissies en agentacties samenbrengt in één continu bijgewerkt model. Daarmee verschuift je analyse-eenheid van “configuratie” naar “reikwijdte”, wat beter aansluit bij het risico van derde-party agenten.
Welke stap je vandaag al kunt zetten
Als je wilt starten met aanpak van derde-party agenten, begin dan niet bij beleidspapier maar bij zichtbaarheid en bereik. Probeer eerst te bepalen welke agentfuncties je omgeving toevoegt via productupdates of platformfeatures. Zet vervolgens prioriteit op de agenten waar connectiviteit het grootst is: systemen met schrijf- of wijzigrechten, koppelingen naar ticketing en dashboards, en scenario’s waarin ketens doorwerken.
Daarna kun je governance operationaliseren: zorg voor een inventaris die agenten benoemt, eigenaarschap toewijst en reikwijdte meetbaar maakt. Alleen dan kun je aantonen dat toezicht niet alleen in theorie bestaat, maar ook wanneer de agent buiten je expliciete adoptiebesluit om verschijnt.
Werk je aanpak voor agenten ook uit in incidentpreventie? Dan zijn bredere inzichten over identiteit en misbruik van automatisering waardevol. Lees bijvoorbeeld ook over credential-stealing via GitHub Actions workflows om beter te snappen hoe geautomatiseerde omgevingen toegang kunnen lekken via hun koppelingen.
Tot slot: agent security is geen eenmalige controle, maar een proces dat meebeweegt met platformupdates. Door derde-party agenten centraal te zetten in je risicoanalyse, voorkom je dat je securitypraktijk achterloopt op wat er in je stack al actief is.
Bron: https://thehackernews.com/2026/10/the-third-party-agent-problem-why.html
