AI-agent gedeelde verantwoordelijkheidsmodel

AI-agenten breiden generatieve AI verder dan het verzoek-/responspatroon dat het AI-model voor gedeelde verantwoordelijkheid beschrijft. In tegenstelling tot een groot taalmodel levert een agent niet alleen inhoud terug zodat een mens kan handelen. In plaats daarvan: een agent:

  • Handelt autonoom. Het roept tools aan, roept API's aan, schrijft data en activeert workflows zonder dat een mens elke stap goedkeurt.
  • Plannen en lussen. Het ontbindt doelen, redeneert over middelbare resultaten en herhaalt zichzelf meerdere keren voordat het terugkeert.
  • Bevat toestand en geheugen. Kortetermijncontext plus persistent geheugen beïnvloedt toekomstig gedrag en kan de grenzen van sessies of gebruikers overschrijden.
  • Heeft een identiteit. Het authenticeert zich bij downstream-systemen door gebruik te maken van beheerde identiteiten, namens tokens, of een aparte agentidentiteit, en het heeft eigen privileges.
  • Schrijft samen met andere agenten. Bij multi-agent orkestratie wordt de output van de ene agent de instructie van een andere agent, waarmee een nieuwe vertrouwensgrens wordt geïntroduceerd.

Elk van deze gedragingen introduceert verantwoordelijkheden die niet bestaan in het request/response AI-model.

Note

In dit artikel wordt met "verantwoordelijkheid" de betekenis binnen governance bedoeld: wie geacht wordt elke beheersmaatregel te configureren, uit te voeren en te monitoren. Het is illustratieve richtlijnen en is niet bedoeld om juridische conclusies te geven of de voorwaarden van enige overeenkomst tussen u en Microsoft te wijzigen of tegen te spreken.

Hoe AI-agenten verschillen van cloud- en AI-workloads

De volgende tabel vat samen hoe het AI-agentmodel verschilt van het standaard cloudmodel en het generatieve AI (LLM)-model.

Zorg Standaard cloudmodel AI-model (LLM) AI-agentmodel
Primaire interactie API of GUI Prompt naar reactie Doel voor autonome meerstapsacties
Bijwerkingen in de echte wereld Applicatiecode, expliciet Mens handelt op output De agent handelt direct via gereedschappen
State Applicatie en datalaag Statusloze prompt Blijvend geheugen van de agent en context
Identity Gebruikers- of applicatie-identiteit Gebruikers- of applicatie-identiteit Duidelijke agentidentiteit plus gedelegeerde tokens
Vertrouwensgrens Van gebruiker naar toepassing Van gebruiker naar model Gebruiker naar agent naar tools naar andere agenten
Grootste risico Verkeerde configuratie, blootstelling aan data Promptinjectie (inhoud) Prompt-injectie die acties aanstuurt; buitensporige handelingsbekwaamheid; Verwarde hulpsheriff

Verdeling van verantwoordelijkheid

Net als bij de cloud- en AI-modellen voor gedeelde verantwoordelijkheid, verschuilt de verdeling van verantwoordelijkheid met het implementatiemodel dat je kiest. Voor agenten zijn de relevante opties:

  • SaaS-agent. Een kant-en-klare agent, zoals Microsoft 365 Copilot-agenten, Microsoft Security Copilot of gepubliceerde Microsoft Copilot Studio-agenten. Microsoft beheert de orchestrator, het model, de veiligheidssystemen en de meeste toolconnectors. Je bent eigenaar van configuratie, data-toegangsscoping, identiteit en gebruik.
  • PaaS-agent. Je bouwt een agent op een managed agent-platform, zoals Microsoft Foundry Agent Service, Azure SRE Agent, aangepaste Microsoft Copilot Studio-agenten of het Microsoft Agent Framework op een door Azure beheerde runtime. Microsoft verzorgt de runtime-, modelhosting- en platformveiligheidscontroles. Je bezit de instructies van de agent, de keuze van tools en plugins, de tool-permissies, orkestratielogica, geheugenontwerp en de identiteit en autorisatie van de agent.
  • IaaS-agent. Je bouwt en host de hele agentstack zelf: een aangepaste orchestrator op VM's of containers, een zelfbeheerd framework en mogelijk zelfgehoste modellen. Je bezit bijna alles behalve de fysieke infrastructuur (en het basismodel, als je het als een gehoste API consumeert).

De verantwoordelijkheid verschuift naar links, wat betekent dat je meer eigenaarschap neemt, terwijl je overstapt van SaaS naar PaaS en vervolgens IaaS-agenten.

Het volgende diagram illustreert de verantwoordelijkheidsgebieden tussen jou en Microsoft volgens het type agentimplementatie.

Diagram van AI-agentverantwoordelijkheidslagen over IaaS-, PaaS- en SaaS-agentimplementaties, met drie nieuwe lagen (agentgeheugen en -status, tools en acties, en agentorkestratie) bovenop het AI-model voor gedeelde verantwoordelijkheid.

AI-agentlaag overzicht

Een agentisch systeem voegt drie nieuwe lagen toe bovenop en rond het bestaande AI-platform, applicatie- en gebruikslagen. De verantwoordelijkheid voor de beveiliging ligt bij degene die de taak uitvoert, maar een leverancier kan instellingen als configuratieopties beschikbaar stellen.

AI-platformlaag (geërfd)

De AI-platformlaag host en beschermt het model, trainingsdata, gewichten en inferentie-API's, en biedt ingebouwde invoer- en uitvoerveiligheidssystemen. De verantwoordelijkheid op deze laag wordt overgenomen van het AI-model van gedeelde verantwoordelijkheid.

Agentorchestratielaag

De orkestratielaag is de "brain loop": planning, redeneren, gereedschapsselectie, de systeemprompt en instructies van de agent, en coördinatie tussen meerdere agenten. Dit is de laag waar te veel autonomie- en promptinjectie-naar-actierisico's zich bevinden.

Beveiligingsoverwegingen:

  • Beperk de instructies en scope van de agent (minimale functionaliteit).
  • Valideer en sanitiseer alle onbetrouwbare inhoud die in de lus komt, inclusief opgehaalde documenten, tool-outputs en berichten van andere agenten. Behandel alles als onbetrouwbare input, niet als vertrouwde instructies.
  • Handhaaf randvoorwaarden voor de planning: stap- en iteratielimieten, lusdetectie, budget- en kostenplafonds, en lijsten met toegestane tools die aan elkaar gekoppeld mogen worden.
  • Voor multi-agent systemen behandel je elk inter-agent bericht als een vertrouwensgrens en pas je invoerveiligheid opnieuw toe.

Gereedschaps- en actielaag

De hulpmiddelen- en actielaag bevat de connectors, plugins, functies, Model Context Protocol (MCP)-servers en API's die de agent kan aanroepen om de status in de echte wereld te lezen en te wijzigen . Deze laag is het grootste verschil met het LLM-model.

Beveiligingsoverwegingen:

  • Minste privileges per hulpprogramma. Elke tool of connector zou alleen de benodigde rechten moeten hebben. Geef de agent geen brede statusidentiteit.
  • Autorisatie voor elke actie, niet alleen bij het begin van de sessie. Controleer opnieuw of deze actie, op deze bron, is toegestaan. Deze controle beperkt het risico op verwarde plaatsvervangers en te brede delegatie.
  • human-in-the-loop-controlepunten Eis ze voor impactvolle, onomkerbare of gevoelige acties zoals schrijven, verwijderen, betalingen, productiewijzigingen en externe verzendingen.
  • Controle van acties Log elke tool-aanroep met inputs, outputs, de gebruikte identiteit en de beslissingsredenering.
  • Sandboxing en controle van uitgaand verkeer. Pas ze toe op code-uitvoerings- en browsetools.

Agentgeheugen en toestandslaag

De agent memory layer omvat de context van kortetermijngesprekken plus persistent geheugen, vector-opslag en scratchpads die het toekomstige gedrag beïnvloeden.

Beveiligingsoverwegingen:

  • Beperk en isoleer geheugen per gebruiker en tenant. Voorkom het uitlekken van geheugen tussen gebruikers of sessies.
  • Bescherm tegen geheugenvergiftiging. Geïnjecteerde inhoud kan aanwezig blijven en later opnieuw worden geactiveerd.
  • Classificeer, bewaar en verwijder opgeslagen geheugen. Pas gegevensclassificatie, behoud en het recht op verwijdering toe.
  • Versleutel geheugenopslag en handhaaf toegangscontrole. Behandel geheugen als gevoelige gegevens.

AI-applicatielaag (geërfd)

De AI-applicatielaag is de applicatie of interface die de gebruiker consumeert, samen met aarding, plugins en het applicatiebeveiligingssysteem.

AI-gebruikslaag (geërfd, uitgebreid)

De AI-gebruikslaag beschrijft hoe gebruikers en applicaties de agent gebruiken. Bij agenten wordt verantwoordelijkheid voor autonome acties centraal: acceptabele gebruiksbeleid, gebruikerseducatie over agent-specifieke risico's en duidelijk eigendom van acties die de agent namens een gebruiker onderneemt.

Verantwoordelijkheidsmatrix

De volgende matrix vat verantwoordelijkheid samen over de implementatiemodellen. C = Klant, M = Microsoft, S = Gedeeld. De matrix is een algemene gids; Specifieke verantwoordelijkheden voor een bepaalde dienst kunnen variëren afhankelijk van de voorwaarden en configuratie van de dienst.

Geërfde cloud- en AI-verantwoordelijkheden

Verantwoordelijkheidsgebied IaaS-agent PaaS-agent SaaS-agent
Klantgegevens (inclusief onderbouwing en inhoud van het geheugen) C C C
Identiteiten en gebruikers C C C
Toegangsbeheer (RBAC, MFA, Conditional Access) C C C
Clientapparaten en -eindpunten C C S
Hosting en gewichten van het basismodel C/M1 M M
Veiligheid van invoer/uitvoerinhoud van modellen C/M1 S M
Fysieke infrastructuur (hosts, netwerk, datacenter) M M M

Agent-specifieke verantwoordelijkheden

Verantwoordelijkheidsgebied IaaS-agent PaaS-agent SaaS-agent
Agentinstructies, systeemprompt en scope C C S
Selectie van hulpmiddelen, plug-ins en connectoren C C S
Machtigingen per hulpprogramma (minimale bevoegdheden) C C S
Agentidentiteit en gedelegeerd tokenbeheer C S S
Autorisatiecontroles per actie C S S
Goedkeuring met menselijke tussenkomst voor acties met grote impact C C C
Orkestratiebeperkingen (lus-, stap- en kostenlimieten) C S M
Multiagent-controles voor vertrouwensgrenzen C S S
Geheugenontwerp, isolatie en vergiftigingsverdediging C S M
Sandboxing van tools en acties en controle van uitgaand verkeer C S M
Logregistratie en monitoring van acties C S S
Agent runtime en orchestratieplatform C M M
Beleid voor acceptabel gebruik en verantwoording voor acties C C C

1 klant als je het model zelf host op IaaS; Microsoft als je een hosted model-API gebruikt van je IaaS-gehoste agent.

Verantwoordelijkheden die u altijd behoudt

Ongeacht het implementatiemodel ben je altijd verantwoordelijk voor:

  • Data, inclusief alles wat naar het agentgeheugen werd geschreven en aan tools werd doorgegeven.
  • Identiteit en minimale bevoegdheden: de identiteit van de agent zelf en de reikwijdte van elk inloggegeven of token die deze kan gebruiken.
  • Autorisatie van acties: wat de agent mag doen, vooral onomkeerbare of gevoelige operaties.
  • Menselijk toezicht: welke acties goedkeuring vereisen en wie verantwoordelijk is voor het gedrag van de agent.
  • Acceptabel gebruik en bestuur: beleid, gebruikerseducatie en naleving van autonoom gedrag.

Belangrijkste agent-specifieke risico's om tegen te ontwerpen

Deze risico's zijn gekoppeld aan de OWASP Top 10 voor LLM-applicaties, de OWASP Top 10 voor Agentic AI,MITRE ATLAS en de Microsoft Security Response Center (MSRC) kwetsbaarheidsclassificatie voor AI-systemen. Ze benadrukken de actiedimensie die uniek is voor agenten.

Risico Mitigation
Directe injectie in actie. Niet-vertrouwde inhoud, zoals een webpagina, document, e-mail of een andere agent, kaapt de agent zodat die kwaadaardig tools aanroept. Behandel alle tool-, retrieval- en agent-uitvoeren als onbetrouwbaar. Isoleer instructies uit data. Beperk ingrijpende acties.
Overmatige autonomie. De agent heeft meer tools, permissies of autonomie dan de taak nodig heeft. Pas het principe van minimale functionaliteit en minimale bevoegdheden toe voor elke tool, en baken instructies af.
Verwarde plaatsvervanger of te brede delegatie. De agent gebruikt zijn bevoorrechte identiteit om iets te doen wat de aanvragende gebruiker niet kan. Gebruik tokens namens een gebruiker en autorisatie per actie. Vermijd een vaste brede identiteit.
Geheugenvergiftiging. Geïnjecteerde inhoud blijft behouden en wordt later of in verschillende sessies opnieuw geactiveerd. Isoleer en valideer het geheugen, houd de herkomst bij en dwing retentie af.
Onbegrensde lussen, kosten en uitputting van middelen. Ongecontroleerde planning. Handhaaf stap-, iteratie- en budgetlimieten, en detecteer lussen.
Vertrouwensstoringen met meerdere agenten. Een gecompromitteerde of hallucinerende agent besmet samenwerkende agents. Pas invoerveiligheid opnieuw toe op elke grens tussen agents. Verifieer, vertrouw niet.
Afvallige of geïmiteerde agenten. Een ongeautoriseerde agent handelt in de omgeving, of de identiteit van een agent wordt vervalst. Handhaaf een sterke agentidentiteit, attestatie, detectie en monitoring.

Configureer voordat je ze aanpast

Hetzelfde principe dat Microsoft aanbeveelt voor AI geldt ook voor agenten, en het is sterker voor agenten omdat autonomie de kosten van fouten vergroot.

  1. Begin met SaaS-agenten (Microsoft 365 Copilot, Microsoft Security Copilot of gepubliceerde Microsoft Copilot Studio-agenten). Microsoft is verantwoordelijk voor orkestratie, veiligheid en de beveiliging van de meeste hulpprogramma's. Je configureert het gegevensbereik en de identiteit.
  2. Stap over naar PaaS-agents (Microsoft Foundry Agent Service, Azure SRE Agent, aangepaste Microsoft Copilot Studio-agenten of het Microsoft Agent Framework op een managed runtime) alleen wanneer kant-en-klare agents niet passen. Je neemt agentlogica, tools, permissies, geheugen en identiteit over.
  3. Bouw IaaS-agenten alleen met diepgaande expertise in AI-beveiliging, identiteit en autonome systeemrisico's. Je bezit bijna de hele stack.

Vuistregel: Hoe meer autonomie en hoe breder het hulpmiddel en de permissies die je aan een agent geeft, hoe meer de verantwoordelijkheidsmatrix naar jou verschuift, ongeacht het implementatiemodel. Autonomie vermindert nooit de verantwoordelijkheid.

Volgende stappen 

  • Last updated on