Wat defensiesystemen hun AI-agenten aan toezicht verschuldigd zijn

Een nieuwe ingenieur op een defensieprogramma krijgt op dag één geen toegang tot alle gecontroleerde bestanden. De toegang wordt afgestemd op zijn of haar bevoegdheid en rol, er is toezicht van een programmaleider en er wordt bijgehouden wat de ingenieur heeft geraadpleegd. De meeste aannemers die AI agents inzetten op programma­systemen slaan al deze drie stappen over. De agent wordt aangesloten, krijgt brede toegang om snel te kunnen werken en opereert met veel minder toezicht dan de nieuwste, minst vertrouwde ingenieur ooit zou krijgen.

Dat gat is geen klein detail. Een AI agent die technische bestanden kan lezen, communicatie kan versturen of data kan verplaatsen namens een aannemer, is in feite een actor met toegang tot gecontroleerde systemen, net als een ingenieur. Het feit dat het op een model draait in plaats van op de loonlijst, verandert niets aan wat het kan benaderen of wat er mis kan gaan als het bij de verkeerde programmadata komt. Dit artikel laat zien waarom AI agents op defensieprogramma’s routinematig minder governance krijgen dan mensen, en wat het betekent om dezelfde standaard toe te passen.

Samenvatting

Aannemers die een nieuwe ingenieur nooit onbeperkte toegang tot alle gecontroleerde bestanden zouden geven, geven die toegang routinematig wél aan AI agents, omdat de inzet van agents wordt gezien als een technisch integratieprobleem in plaats van een governancevraagstuk. Het resultaat zijn systemen die gecontroleerde data kunnen lezen, verplaatsen en versturen met minder controles dan de mensen die ze gebouwd hebben. Voor programmabeveiligingsleiders is de praktische vraag eenvoudig: zou dit toegangs­niveau acceptabel zijn als de actor een persoon was, en zo niet, waarom dan wel voor een agent?

Belangrijkste punten

1. AI agents op defensieprogramma’s worden vaak ingezet met bredere toegang tot gecontroleerde data dan een nieuwe medewerker zou krijgen. De snelheid van adoptie is de basisgovernance die aannemers al op mensen toepassen voorbijgestreefd.
2. Een agent moet de rechten erven van de persoon die hem autoriseert, niet een apart, permanent account. Een breed serviceaccount voor een AI agent creëert precies het over-geprivilegieerde toegangsniveau dat aannemers jarenlang voor mensen hebben proberen te elimineren.
3. Voor gevoelige acties, zoals het extern delen van CUI, is altijd een goedkeuringsstap nodig, ongeacht wie of wat deze initieert.
4. Elke AI-actie moet worden toegeschreven aan een specifieke persoon en met dezelfde grondigheid worden gelogd als menselijke activiteiten. Een audittrail die “de AI deed het” als voldoende toeschrijving beschouwt, is geen audittrail.
5. Governance die vanaf het begin voor AI agents is ingericht, vereist geen nieuwe infrastructuur. Het toegangs-, goedkeurings- en loggingmodel dat aannemers al voor personeel gebruiken, is direct toepasbaar op agents.

Waarom AI agents met minder controle worden onboard dan mensen

Het verschil is zelden bewust. Het is een gevolg van hoe snel agent-capaciteiten van experiment naar operatie zijn gegaan, en hoe verschillend technische teams en beveiligingsteams naar het probleem kijken.

Snelheid van adoptie loopt voor op governance by design

Een AI agent koppelen aan een programma­systeem is vaak een configuratietaak van enkele minuten: API-sleutel verstrekken, scope autoriseren, klaar. De bijbehorende governance die een nieuwe ingenieur doorloopt—screening, gedefinieerde rollen, een gedocumenteerde toegangscontrole—was ingericht op mensen die op menselijk tempo aan een programma beginnen.

“Het is gewoon een tool”-denken onderschat wat een agent kan doen

Omdat een AI agent wordt omschreven als een tool in plaats van een gebruiker, is het makkelijk om erover na te denken zoals aannemers over software nadenken, in plaats van zoals ze nadenken over mensen met toegang tot gecontroleerde data. Een tool die autonoom een gecontroleerd bestand kan lezen, kan besluiten het door te sturen of kan handelen op basis van instructies in de inhoud die het verwerkt, oefent beoordelingsvermogen uit op een manier die een spreadsheet niet doet.

Wat “dezelfde governance als mensen” echt vereist

Menselijke governance uitbreiden naar AI agents is geen nieuw vakgebied. Het zijn dezelfde drie componenten die aannemers al op mensen toepassen, nu consequent toegepast op agents.

Identiteitserfenis in plaats van permanente rechten

De belangrijkste ontwerpkeuze is of een agent opereert onder een eigen, breed en hardnekkig account, of de specifieke rechten erft van de persoon die hem heeft geautoriseerd—voor die sessie, voor die taak. Een permanent serviceaccount met brede toegang tot CUI creëert precies het over-geprivilegieerde account dat beveiligingsteams jarenlang proberen te elimineren. Een agent die alleen kan doen wat de authenticerende gebruiker al mocht doen, is net zo begrensd als een menselijke collega die namens iemand anders handelt.

Goedkeuringsmomenten vóór ingrijpende acties

Een ingenieur die CUI extern deelt, krijgt doorgaans een bevestigingsstap voordat dit gebeurt. Een AI agent die dezelfde soort actie probeert, moet door hetzelfde soort poort: een moment waarop een mens de scope, ontvangers of gevolgen bevestigt voordat de actie wordt afgerond.

Toeschrijving en audit, niet alleen activiteitlogs

Een menselijke audittrail schrijft elke actie toe aan een specifieke verantwoordelijke persoon. De acties van een AI agent vereisen dezelfde standaard: niet “een geautomatiseerd proces deed dit”, maar welke gebruiker de agent heeft geautoriseerd, wat deze mocht doen en wat er daadwerkelijk is gebeurd.

Waar het verschil in de praktijk zichtbaar wordt voor defensie-aannemers

Het meest voorkomende patroon is een enkele, breed ingestelde credential die één keer wordt uitgegeven en vervolgens onbeperkt blijft bestaan, samen met agents die zijn geconfigureerd om CUI te delen zonder bevestigingsstap, omdat het bouwen van zo’n pauze meer engineering vraagt dan de agent gewoon laten doorgaan. Zelfs als activiteiten worden gelogd, kan de log vaak niet aangeven welke specifieke persoon verantwoordelijk is voor een bepaalde actie, waardoor dezelfde toets wordt gemist als bij een menselijke audittrail zonder naam van de gebruiker.

Agent-governance bouwen op het toegangsmodel dat je al hebt

De praktische weg vooruit is geen nieuw governanceframework speciaal voor AI. Het is het toepassen van het identiteit-, goedkeurings- en auditmodel dat een aannemer al voor zijn personeel gebruikt, consequent op zijn agents.

Hoe een Data Control Plane menselijke governance toepast op AI agents

Het Kiteworks Data Control Plane koppelt AI agents via een beveiligde interface op basis van OAuth 2.0-authenticatie, waarbij elke agent-operatie de bestaande rechten van de geauthenticeerde gebruiker erft in plaats van een apart, permanent account. Dynamische op attributen gebaseerde beleidsregels beoordelen agentverzoeken precies zoals ze een menselijk verzoek zouden beoordelen. Gevoelige acties, zoals lidmaatschapswijzigingen en uitgaande verzendingen, vereisen expliciete bevestiging voordat ze worden uitgevoerd. Beheerders kunnen wereldwijd destructieve tools uitschakelen of beperken welke acties een agent überhaupt mag proberen. Elke agent-operatie wordt vastgelegd in een manipulatiebestendige, onbeperkte auditlog, toegeschreven aan de autoriserende gebruiker en direct doorgezet naar SIEM-tools, zodat de activiteiten van een agent net zo verantwoord zijn als die van een ingenieur.

Aannemers die willen weten of hun huidige AI agent-inzet dezelfde toegangscontrole zou doorstaan als een nieuwe medewerker, kunnen een aangepaste demo plannen om te zien hoe identiteit-gebonden, geaudite agent-governance werkt in hun eigen omgeving.