AI-agentens delade ansvarsmodell

AI-agenter utvidgar generativ AI bortom det förfrågnings-/svarsmönstret som AI-modellen för delat ansvar beskriver. Till skillnad från en stor språkmodell returnerar en agent inte bara innehåll för en människa att agera på. Istället gör en agent:

  • Agerar autonomt. Den anropar verktyg, anropar API:er, skriver data och triggar arbetsflöden utan att en människa godkänner varje steg.
  • Planer och loopar. Den bryter ner mål, resonerar över mellanresultat och återuppvisar sig själv många gånger innan den återvänder.
  • Bevarar tillstånd och minne. Korttidskontext plus persistent minne påverkar framtida beteende och kan överskrida sessions- eller användargränser.
  • Har en identitet. Den autentiserar sig mot underliggande system genom att använda hanterade identiteter, token för delegerad åtkomst eller en särskild agentidentitet, och den har egna behörigheter.
  • Komponerar tillsammans med andra agenter. I orkestrering av flera agenter blir en agents utdata till en annan agents instruktion, vilket skapar en ny förtroendegräns.

Var och en av dessa beteenden introducerar ansvar som inte finns i förfrågnings-/svar-AI-modellen.

Note

Denna artikel använder "ansvar" i en styrningsmening: vem som förväntas konfigurera, driva och övervaka varje kontroll. Det är illustrativ vägledning och är inte avsett att förmedla juridiska slutsatser eller att ändra eller motsäga villkoren i något avtal mellan dig och Microsoft.

Hur AI-agenter skiljer sig från moln- och AI-arbetsbelastningar

Följande tabell sammanfattar hur AI-agentmodellen skiljer sig från den standardiserade molnmodellen och den generativa AI (LLM)-modellen.

Bekymmer Standardmolnmodell AI-modell (LLM) AI-agentmodellen
Primär interaktion API eller GUI Från prompt till svar Mål för autonom flerstegsåtgärd
Verkliga biverkningar Applikationskod, uttrycklig En människa agerar utifrån utdata Agenten agerar direkt genom verktyg
Tillstånd Applikation och datalager Tillståndslös prompt Beständigt agentminne och kontext
Identity Användar- eller applikationsidentitet Användar- eller applikationsidentitet Tydlig agentidentitet plus delegerade tokens
Förtroendegräns Användare till applikation Användare till modellen Användare till agent till verktyg till andra agenter
Topprisk Felkonfiguration, dataexponering Promptinjektion (innehåll) Promptinjektion som utlöser åtgärder; alltför stor autonomi; förvirrad mellanhand

Ansvarsfördelning

Precis som med moln- och AI-modeller för delat ansvar förändras ansvarsfördelningen med den distributionsmodell du väljer. För agenter är de relevanta alternativen:

  • SaaS-agent. En färdig agent, såsom Microsoft 365 Copilot-agenter, Microsoft Security Copilot eller publicerade Microsoft Copilot Studio-agenter. Microsoft driver orkestreratören, modellen, säkerhetssystemen och de flesta verktygskopplingar. Du äger konfiguration, dataåtkomstbegränsning, identitet och användning.
  • PaaS-agent. Du bygger en agent på en hanterad agentplattform, såsom Microsoft Foundry Agent Service, Azure SRE Agent, anpassade Microsoft Copilot Studio-agenter eller Microsoft Agent Framework på en Azure-hanterad runtime. Microsoft tillhandahåller runtime-, modellhosting- och plattformssäkerhetskontroller. Du äger agentens instruktioner, verktygs- och pluginval, verktygsbehörigheter, orkestreringslogik, minnesdesign samt agentens identitet och auktorisation.
  • IaaS-agent. Du bygger och hostar hela agentstacken själv: en anpassad orchestrator på VM:ar eller containrar, ett självstyrt ramverk och eventuellt självhostade modeller. Du äger nästan allt utom den fysiska infrastrukturen (och basmodellen, om du använder den som ett hostat API).

Ansvar flyttas åt vänster, vilket innebär att du tar mer ansvar när du går från SaaS till PaaS till IaaS-agenter.

Följande diagram illustrerar ansvarsområdena mellan dig och Microsoft beroende på typen av agentutplacering.

Diagram över AI-agentansvarighetslager över IaaS-, PaaS- och SaaS-agentdistributioner, med tre nya lager (agentminne och tillstånd, verktyg och åtgärder, samt agentorkestrering) som lagts till ovanpå AI-modellen för delat ansvar.

Översikt över AI-agentlager

Ett agentiskt system lägger till tre nya lager ovanpå och runt den befintliga AI-plattformen, applikationen och användningslagren. Säkerhetsansvaret följer den som utför uppgiften, men en leverantör kan göra kontroller tillgängliga för dig via konfiguration.

AI-plattformslager (ärvt)

AI-plattformsskiktet inrymmer och skyddar modellen, träningsdata, modellvikter och inferens-API:er samt tillhandahåller inbyggda säkerhetssystem för in- och utdata. Ansvar på detta lager ärvs från AI:s modell för delat ansvar.

Orkestreringsskikt för agenter

Orkestreringslagret är "hjärnloopen": planering, resonemang, verktygsval, agentens systemprompt och instruktioner samt samordning mellan flera agenter. Det är här i lagret som riskerna med överdriven handlingskraft och att promptinjektion leder till handling finns.

Säkerhetsaspekter:

  • Begränsa agentens instruktioner och omfattning (minst funktionalitet).
  • Validera och sanera allt opålitligt innehåll som kommer in i loopen, inklusive hämtade dokument, verktygsutdata och andra agenters meddelanden. Behandla allt som opålitlig input, inte som betrodda instruktioner.
  • Inför begränsningar för planering: steg- och iterationsgränser, detektering av loopar, budget- och kostnadstak samt tillåtelselistor över vilka verktyg som får kedjas samman.
  • För multiagentsystem behandlas varje interagentmeddelande som en förtroendegräns och tillämpar inmatningssäkerheten igen.

Verktygs- och åtgärdslagret

Verktygs- och åtgärdslagret innehåller connectors, plugins, funktioner, Model Context Protocol (MCP)-servrar och API:er som agenten kan anropa för att läsa och ändra tillstånd i verkligheten. Detta lager är den största skillnaden från LLM-modellen.

Säkerhetsaspekter:

  • Minst privilegium per verktyg. Varje verktyg eller kontakt bör endast innehålla de nödvändiga behörigheterna. Ge inte agenten en bred identitet.
  • Auktorisation på varje åtgärd, inte bara vid sessionsstart. Kontrollera igen att denna åtgärd, på denna resurs, är tillåten. Denna kontroll minskar riskerna för förvirrad deputerad och överdriven delegering.
  • Grindar med mänsklig medverkan. Kräv dem för högpåverkande, irreversibla eller känsliga handlingar som skrivningar, raderingar, betalningar, produktionsändringar och externa sändningar.
  • Åtgärdsgranskning. Logga varje verktygsanrop med indata, utdata, den använda identiteten och beslutsmotiveringen.
  • Sandboxning och utrymningskontroll. Använd dem på kodexekverings- och bläddringsverktyg.

Agentminne och tillståndslager

Agentminneslagret täcker korttidskonversationskontext samt persistent minne, vektorlager och scratchpads som påverkar framtida beteende.

Säkerhetsaspekter:

  • Begränsa och isolera minne per användare och hyresgäst. Förhindra minnesläckning mellan användare eller sessioner.
  • Skydda mot minnesförgiftning. Inmatat innehåll kan finnas kvar och utlösas igen senare.
  • Klassificera, behåll och ta bort lagrat minne. Tillämpa dataklassificering, lagring och rätt till radering.
  • Kryptera minneslagringar och upprätthålla åtkomstkontroll. Behandla minne som känslig data.

AI-applikationslager (ärvt)

AI-applikationslagret är applikationen eller gränssnittet som användaren konsumerar, tillsammans med jordning, plugins och applikationssäkerhetssystemet.

AI-användningslager (ärvt, utökat)

AI-användningslagret beskriver hur användare och applikationer använder agenten. Med agenter blir ansvar för autonoma åtgärder centralt: acceptabla användningspolicys, användarutbildning om agentspecifika risker och tydligt ägande av de åtgärder agenten tar på användarens vägnar.

Ansvarsmatris

Följande matris sammanfattar ansvar över distributionsmodeller. C = Kund, M = Microsoft, S = Delat. Matrisen är en allmän guide; Specifika ansvarsområden för en viss tjänst kan variera beroende på tjänstens villkor och konfiguration.

Ärvda moln- och AI-ansvar

Ansvarsområde IaaS-agent PaaS-agent SaaS-agent
Kunddata (inklusive jordning och minnesinnehåll) C C C
Identiteter och användare C C C
Åtkomsthantering (RBAC, MFA, villkorad åtkomst) C C C
Klientenheter och slutpunkter C C S
Hosting och vikter för basmodell C/M1 M M
Säkerhet för modellens in- och utdata C/M1 S M
Fysisk infrastruktur (värdar, nätverk, datacenter) M M M

Agentspecifika ansvarsområden

Ansvarsområde IaaS-agent PaaS-agent SaaS-agent
Agentinstruktioner, systemprompt och omfattning C C S
Verktyg, plugin och kontaktval C C S
Behörigheter per verktyg (minimala behörigheter) C C S
Agentidentitet och delegerad tokenhantering C S S
Auktorisationskontroller per åtgärd C S S
Godkännande med mänsklig medverkan för åtgärder med stor inverkan C C C
Skyddsräcken för orkestrering (loopar, steg- och kostnadsgränser) C S M
Kontroller för fleragent-förtroendegränser C S S
Minnesdesign, isolering och försvar mot förgiftning C S M
Verktygs- och aktionssandlåda och utrymningskontroll C S M
Handlingsgranskning, loggning och övervakning C S S
Agentens körtid och orkestratorplattform C M M
Acceptabel användningspolicy och ansvarstagande för åtgärder C C C

1 kund om du självhostar modellen på IaaS; Microsoft om du använder ett hostat modell-API från din IaaS-hostade agent.

Ansvarsområden som du alltid behåller

Oavsett distributionsmodell är du alltid ansvarig för:

  • Data, inklusive allt som skrivits till agentminnet och skickats till verktyg.
  • Identitet och minsta privilegium: agentens egen identitet och omfattningen av varje legitimation eller token den kan använda.
  • Auktorisation av handlingar: vad agenten får göra, särskilt irreversibla eller känsliga operationer.
  • Mänsklig tillsyn: vilka handlingar som kräver godkännande och vem som är ansvarig för agentens beteende.
  • Acceptabel användning och styrning: policyer, användarutbildning och efterlevnad av autonomt beteende.

Topp agentspecifika risker att designa mot

Dessa risker motsvarar OWASP Top 10 för LLM-applikationer, OWASP Top 10 för Agentic AI,MITRE ATLAS och Microsoft Security Response Center (MSRC) sårbarhetsgradering för AI-system. De betonar den handlingsdimension som är unik för agenter.

Risk Mitigation
Snabb injektion i handling. Icke betrott innehåll, såsom en webbsida, ett dokument, ett e-postmeddelande eller en annan agent, kapar agenten och får den att anropa verktyg i skadligt syfte. Behandla alla verktygs-, hämtnings- och agentutdata som opålitliga. Isolera instruktioner från data. Begränsa åtgärder med stor påverkan.
Överdriven handlingskraft. Agenten har fler verktyg, behörigheter eller autonomi än vad uppgiften behöver. Tillämpa så begränsad funktionalitet som möjligt och minsta möjliga behörighet för varje verktyg, och avgränsa instruktionerna.
Förvirrad ledamot eller alltför bred delegation. Agenten använder sin privilegierade identitet för att göra något som den begärande användaren inte kan. Använd on-behalf-of-token och auktorisering per åtgärd. Undvik en fast bred identitet.
Minnesförgiftning. Inmatat innehåll kvarstår och utlöses på nytt senare eller över flera sessioner. Isolera och validera minne, spåra proveniens och säkerställ lagring.
Obegränsade loopar, kostnader och resursuttömning. Okontrollerad planering Upprätthåll steg-, iterations- och budgetgränser samt upptäck loopar.
Tillitsfel i fleragentsystem En komprometterad eller hallucinerande agent smittar samarbetande agenter. Tillämpa indatasäkerhet på nytt vid varje gräns mellan agenter. Verifiera, lita inte på det.
Skurkaktiga eller utklädda agenter. En obehörig agent agerar i miljön, eller så förfalskas agentens identitet. Upprätthålla stark agentidentitet, intygning samt upptäckt och övervakning.

Konfigurera innan du anpassar

Samma princip som Microsoft rekommenderar för AI gäller för agenter, och den är starkare för agenter eftersom autonomi multiplicerar kostnaden för att göra fel.

  1. Börja med SaaS-agenter (Microsoft 365 Copilot, Microsoft Security Copilot eller publicerade Microsoft Copilot Studio-agenter). Microsoft äger orkestrering, säkerhet och de flesta verktygssäkerheter. Du konfigurerar dataomfång och identitet.
  2. Byt till PaaS-agenter (Microsoft Foundry Agent Service, Azure SRE Agent, anpassade Microsoft Copilot Studio-agenter eller Microsoft Agent Framework på en hanterad runtime) endast när färdiga agenter inte passar. Du tar på dig agentlogik, verktyg, behörigheter, minne och identitet.
  3. Bygg endast IaaS-agenter med djup expertis inom AI-säkerhet, identitet och autonoma systemrisker. Du äger nästan hela stacken.

Tumregel: Ju mer självständighet och ju bredare verktyg och behörighetsuppsättning du ger en agent, desto mer av ansvarsmatrisen flyttas till dig, oavsett distributionsmodell. Autonomi minskar aldrig ansvarstagandet.

Nästa steg

  • Last updated on