KI-Agentenmodell der geteilten Verantwortung

KI-Agenten erweitern generative KI über das Anfrage-/Antwortmuster hinaus, das das KI-Shared Responsibility Modell beschreibt. Im Gegensatz zu einem großen Sprachmodell gibt ein Agent nicht nur Inhalte zurück, auf die ein Mensch reagieren kann. Stattdessen spricht ein Agent:

  • Handelt autonom. Es ruft Werkzeuge auf, ruft APIs auf, schreibt Daten und löst Workflows aus, ohne dass ein Mensch jeden Schritt genehmigt.
  • Pläne und Schleifen. Es zerlegt Ziele, zieht aus Zwischenergebnissen Schlüsse und fordert sich selbst mehrfach neu auf, bevor es eine Antwort zurückgibt.
  • Enthält Zustand und Speicher. Kurzzeitkontext plus persistentes Gedächtnis beeinflusst das zukünftige Verhalten und kann Sitzungs- oder Benutzergrenzen überschreiten.
  • Hat eine Identität. Es authentifiziert sich bei nachgelagerten Systemen mithilfe verwalteter Identitäten, von On-Behalf-Of-Token oder einer eigenständigen Agent-Identität und verfügt über eigene Berechtigungen.
  • Schreibt mit anderen Agenten. In der Multi-Agenten-Orchestrierung wird die Ausgabe eines Agenten zur Anweisung für einen anderen Agenten, wodurch eine neue Vertrauensgrenze entsteht.

Jedes dieser Verhaltensweisen führt Verantwortlichkeiten ein, die im Request/Response-KI-Modell nicht existieren.

Hinweis

Dieser Artikel verwendet "Verantwortung" im Sinne von Governance: wer erwartet wird, jede Kontrolle zu konfigurieren, zu betreiben und zu überwachen. Es handelt sich um anschauliche Leitlinien und soll keine rechtlichen Schlussfolgerungen vermitteln, keine Bedingungen einer Vereinbarung zwischen Ihnen und Microsoft ändern oder widersprechen.

Wie sich KI-Agenten von Cloud- und KI-Workloads unterscheiden

Die folgende Tabelle fasst zusammen, wie sich das KI-Agentenmodell vom Standard-Cloud-Modell und dem generativen KI-(LLM)-Modell unterscheidet.

Sorge Standard-Cloud-Modell KI-(LLM)-Modell KI-Agentenmodell
Primäre Interaktion API oder GUI Prompt zur Antwort Ziel: autonome mehrstufige Ausführung
Nebenwirkungen aus der realen Welt Anwendungscode, explizit Der Mensch beeinflusst die Ausgabe Agent handelt direkt durch Werkzeuge
State Anwendung und Datenschicht Zustandsfreier Prompt Speicher und Kontext des persistenten Agenten
Identity Benutzer- oder Anwendungsidentität Benutzer- oder Anwendungsidentität Eigenständige Agentenidentität plus delegierte Token
Vertrauensgrenze Benutzer-zu-Anwendung Benutzer-zu-Modell Nutzer zu Agent zu Werkzeugen zu anderen Agenten
Höchstes Risiko Fehlkonfiguration, Datenexposition Prompt Injection (Inhalt) Prompt Injection, die Aktionen vorantreibt; übermäßige Eigenständigkeit; Verwirrter Stellvertreter

Aufteilung der Verantwortung

Wie bei den Cloud- und KI-Modellen für geteilte Verantwortung verschiebt sich die Verantwortungsaufteilung je nach gewähltem Bereitstellungsmodell. Für Agenten sind die relevanten Optionen:

  • SaaS-Agent. Ein fertiger Agent, beispielsweise Microsoft 365 Copilot-Agenten, Microsoft Security Copilot oder veröffentlichte Microsoft Copilot Studio-Agenten. Microsoft betreibt den Orchestrator, das Modell, die Sicherheitssysteme und die meisten Werkzeuganschlüsse. Du besitzt die Konfiguration, das Datenzugriffs-Umfang, die Identität und die Nutzung.
  • PaaS-Agent. Man baut einen Agenten auf einer Managed-Agent-Plattform, wie zum Beispiel Microsoft Foundry Agent Service, Azure SRE Agent, benutzerdefinierte Microsoft Copilot Studio-Agenten oder das Microsoft Agent Framework auf einer von Azure verwalteten Laufzeitumgebung. Microsoft stellt die Laufzeit-, Modell-Hosting- und Plattformsicherheitskontrollen bereit. Sie besitzen die Anweisungen des Agenten, die Auswahl von Werkzeugen und Plugins, die Werkzeugberechtigungen, die Orchestrierungslogik, das Speicherdesign sowie die Identität und Autorisierung des Agenten.
  • IaaS-Agent. Du baust und hostest den gesamten Agent-Stack selbst: einen eigenen Orchestrator auf VMs oder Containern, ein selbstverwaltetes Framework und möglicherweise selbst gehostete Modelle. Du besitzt fast alles außer der physischen Infrastruktur (und dem Basismodell, wenn du es als gehostete API nutzt).

Die Verantwortung verschiebt sich nach links, was bedeutet, dass man mehr Verantwortung übernimmt, wenn man von SaaS zu PaaS zu IaaS-Agenten wechselt.

Das folgende Diagramm zeigt die Verantwortungsbereiche zwischen Ihnen und Microsoft je nach Art der Agentenbereitstellung.

Diagramm der AI-Agentenverantwortungsschichten über IaaS-, PaaS- und SaaS-Agenten-Deployments hinweg, mit drei neuen Schichten (Agentenspeicher und -zustand, Werkzeuge und Aktionen sowie Agentenorchestrierung), die auf dem KI-Shared-Responsibility-Modell hinzukommen.

Überblick über die KI-Agentenschicht

Ein agentisches System fügt drei neue Schichten auf und um die bestehenden KI-Plattform-, Anwendungs- und Nutzungsschichten hinzu. Die Sicherheitsverantwortung folgt demjenigen, der die Aufgabe ausführt, aber ein Anbieter könnte Ihnen Kontrollen als Konfiguration zur Verfügung stellen.

KI-Plattformschicht (vererbt)

Die KI-Plattformschicht hostet und schützt das Modell, Trainingsdaten, Gewichte und Inferenz-APIs und stellt integrierte Ein- und Ausgabesicherheitssysteme bereit. Die Verantwortung auf dieser Ebene wird vom KI-Modell der geteilten Verantwortung übernommen.

Agenten-Orchestrierungsschicht

Die Orchestrierungsschicht ist die "Gehirnschleife": Planung, Argumentation, Werkzeugauswahl, die Systemanweisung und Anweisungen des Agenten sowie Koordination zwischen mehreren Agenten. In dieser Schicht liegen übermäßige Handlungsfähigkeit und die Risiken der sofortigen Injektion zum Handeln .

Sicherheitsaspekte:

  • Einschränke die Anweisungen und den Umfang des Agenten (minimale Funktionalität).
  • Validieren und bereinigen Sie alle nicht vertrauenswürdigen Inhalte, die in die Schleife gelangen, einschließlich abgerufener Dokumente, Werkzeugausgaben und Nachrichten anderer Agenten. Behandle alles als vertrauenslose Eingabe, nicht als vertrauenswürdige Anweisungen.
  • Definieren Sie Leitplanken für die Planung: Schritt- und Iterationsgrenzen, Schleifenerkennung, Budget- und Kostenobergrenzen sowie Zulassungslisten dafür, welche Werkzeuge miteinander verkettet werden dürfen.
  • Für Multi-Agenten-Systeme behandeln Sie jede interagentische Nachricht als Vertrauensgrenze und wenden Sie die Eingabesicherheit erneut an.

Werkzeug- und Aktionsschicht

Die Werkzeug- und Aktionsschicht enthält die Connectors, Plugins, Funktionen, Model Context Protocol (MCP)-Server und APIs, die der Agent aufrufen kann, um den Zustand in der realen Welt zu lesen und zu ändern . Diese Schicht ist der größte Unterschied zum LLM-Modell.

Sicherheitsaspekte:

  • Geringstmögliche Berechtigungen pro Tool. Jedes Werkzeug oder jeder Stecker sollte nur die erforderlichen Berechtigungen besitzen. Gewähren Sie dem Agenten keine dauerhafte Identität mit weitreichenden Berechtigungen.
  • Autorisierung für jede Aktion, nicht nur zu Beginn der Sitzung. Überprüfe erneut, ob diese Aktion auf dieser Ressource erlaubt ist. Diese Kontrolle mindert das Risiko von verwirrtem Stellvertreter und übermäßiger Delegation.
  • Menschen-in-der-Schleife-Tore. Benötigt sie für wirkungsvolle, irreversible oder sensible Aktionen wie Schreiben, Löschen, Zahlungen, Produktionsänderungen und externe Sendungen.
  • Aktionsüberwachung. Protokolliere jeden Werkzeugaufruf mit Eingaben, Ausgaben, der verwendeten Identität und der Entscheidungsbegründung.
  • Sandboxing und Fluchtkontrolle. Wenden Sie sie auf Code-Ausführungs- und Browsing-Tools an.

Agentenspeicher und Zustandsschicht

Die Agentenspeicherschicht deckt den Kontext kurzfristiger Konversationen sowie persistente Erinnerungen, Vektorspeicher und Scratchpads ab, die das zukünftige Verhalten beeinflussen.

Sicherheitsaspekte:

  • Begrenzen und isolieren Sie den Arbeitsspeicher pro Benutzer und Mandant. Verhindern Sie benutzer- oder sitzungsübergreifende Speicherlecks.
  • Schutz vor Speichervergiftung. Eingespritzte Inhalte können erhalten bleiben und später erneut ausgelöst werden.
  • Speicher klassifizieren, speichern und löschen. Wenden Sie Datenklassifizierung, Aufbewahrung und das Recht auf Löschung an.
  • Verschlüssele Speicherspeicher und erzwinge Zugriffskontrolle. Behandle Speicher als sensible Daten.

KI-Anwendungsschicht (vererbt)

Die KI-Anwendungsschicht ist die Anwendung oder Schnittstelle, die der Nutzer nutzt, zusammen mit Grounding, Plugins und dem Anwendungssicherheitssystem.

KI-Nutzungsschicht (vererbt, erweitert)

Die KI-Nutzungsschicht beschreibt, wie Nutzer und Anwendungen den Agenten nutzen. Bei Agenten wird die Verantwortung für autonome Aktionen zentral: Akzeptable Use Policies, Nutzerschulung zu agentenspezifischen Risiken und klare Eigenverantwortung für die Handlungen, die der Agent im Namen eines Nutzers übernimmt.

Zuständigkeitsmatrix

Die folgende Matrix fasst die Verantwortung zwischen den Bereitstellungsmodellen zusammen. C = Kunde, M = Microsoft, S = Geteilt. Die Matrix ist ein allgemeiner Leitfaden; Die spezifischen Verantwortlichkeiten eines bestimmten Dienstes können je nach Bedingungen und Konfiguration des Dienstes variieren.

Vererbte Cloud- und KI-Aufgaben

Zuständigkeitsbereich IaaS-Agent PaaS-Agent SaaS-Agent
Kundendaten (einschließlich Grounding- und Speicherinhalten) C C C
Identitäten und Benutzer C C C
Zugriffsmanagement (RBAC, MFA, Conditional Access) C C C
Client-Geräte und Endpunkte C C S
Hosting und Gewichte des Basismodells C/M1 M M
Modell-Eingabe-/Ausgabe-Inhaltssicherheit C/M1 S M
Physische Infrastruktur (Hosts, Netzwerk, Rechenzentrum) M M M

Agentenspezifische Aufgaben

Zuständigkeitsbereich IaaS-Agent PaaS-Agent SaaS-Agent
Agentenanweisungen, Systemprompt und Umfang C C S
Auswahl von Werkzeug, Plugin und Connector C C S
Berechtigungen pro Werkzeug (geringste Privilegien) C C S
Agentenidentität und delegierte Token-Verwaltung C S S
Autorisierungsprüfungen pro Aktion C S S
Human-in-the-Loop-Genehmigung für wirkungsvolle Maßnahmen C C C
Orchestrierungs-Leitplanken (Schleife-, Schritt- und Kostengrenzen) C S M
Multi-Agenten-Vertrauensgrenzenkontrollen C S S
Gedächtnisdesign, Isolation und Vergiftungsabwehr C S M
Werkzeug- und Aktions-Sandboxing sowie Egress-Control C S M
Aktionsprüfungsprotokollierung und Überwachung C S S
Agent-Laufzeit und Orchestrator-Plattform C M M
Akzeptable Nutzungspolitik und Rechenschaftspflicht für Maßnahmen C C C

1 Kunde, wenn du das Modell auf IaaS selbst hostest; Microsoft, wenn du eine gehostete Modell-API von deinem IaaS-gehosteten Agenten nutzt.

Verantwortlichkeiten, die Sie immer behalten

Unabhängig vom Bereitstellungsmodell sind Sie immer verantwortlich für:

  • Daten, einschließlich allem, was in den Agentenspeicher geschrieben und an Tools weitergegeben wurde.
  • Identität und geringste Privilegien: Die eigene Identität des Agenten und der Umfang jeder Zugangsdaten oder jedes Tokens, das er verwenden kann.
  • Autorisierung von Aktionen: Was der Agent tun darf, insbesondere irreversible oder sensible Operationen.
  • Menschliche Kontrolle: Welche Aktionen Genehmigung erfordern und wer für das Verhalten des Agenten verantwortlich ist.
  • Akzeptable Nutzung und Governance: Richtlinien, Nutzerschulung und Einhaltung autonomen Verhaltens.

Wichtigste agentenspezifische Risiken, gegen die man entwerfen sollte

Diese Risiken passen zu den OWASP Top 10 für LLM-Anwendungen, den OWASP Top 10 für Agentic AI,MITRE ATLAS und dem Microsoft Security Response Center (MSRC) zur Schweregradklassifikation von Schwachstellen für KI-Systeme. Sie betonen die Handlungsdimension , die einzigartig für Agenten ist.

Risiko Mitigation
Prompt-Injektion zur Ausführung einer Aktion. Nicht vertrauenswürdige Inhalte, wie eine Webseite, ein Dokument, eine E-Mail oder ein anderer Agent, kapern den Agenten, um Tools böswillig aufzurufen. Behandle alle Tool-, Abruf- und Agentenausgaben als nicht vertrauenswürdig. Isoliere Anweisungen aus Daten. Aktionen mit hoher Auswirkung kontrollieren.
Übermäßige Handlungsmacht. Der Agent hat mehr Werkzeuge, Berechtigungen oder Autonomie, als die Aufgabe benötigt. Wenden Sie für jedes Werkzeug nur den minimal erforderlichen Funktionsumfang und die minimal erforderlichen Berechtigungen an, und grenzen Sie den Geltungsbereich von Anweisungen entsprechend ein.
Verwirrter Stellvertreter oder übermäßig breite Delegation. Der Agent nutzt seine privilegierte Identität, um etwas zu tun, das der anfordernde Nutzer nicht kann. Verwenden Sie On-Behalf-Of-Token und Autorisierung für jede Aktion. Vermeiden Sie eine bestehende breite Identität.
Gedächtnisvergiftung. Eingeschleuster Inhalt bleibt bestehen und wird später oder über Sitzungen hinweg neu ausgelöst. Isolieren und validieren Sie das Gedächtnis, verfolgen Sie die Herkunft und setzen Sie die Aufbewahrung durch.
Endlosschleifen, Kosten und Ressourcenerschöpfung. Außer Kontrolle geratene Planung. Schritt-, Iterations- und Budgetgrenzen festlegen und Schleifen erkennen.
Vertrauensausfälle bei mehreren Agenten. Ein kompromittierter oder halluzinierender Agent kontaminiert zusammenarbeitende Agenten. Wenden Sie die Eingabesicherheit an jedem Übergang zwischen Agenten erneut an. Überprüfe, vertraue nicht.
Abtrünnige oder nachgeahmte Agenten. Ein unbefugter Agent handelt in der Umgebung oder die Identität eines Agenten wird gefälscht. Setzen Sie eine starke Agentenidentität, Attestierung sowie Erkennung und Überwachung durch.

Konfigurieren Sie, bevor Sie anpassen

Das gleiche Prinzip, das Microsoft für KI empfiehlt, gilt auch für Agenten und ist stärker für Agenten, weil Autonomie die Kosten für Fehler vervielfacht.

  1. Beginnen Sie mit SaaS-Agenten (Microsoft 365 Copilot, Microsoft Security Copilot oder veröffentlichten Microsoft Copilot Studio-Agenten). Microsoft ist für die Orchestrierung, die Sicherheit und den Großteil der Werkzeugsicherheit verantwortlich. Du konfigurierst den Datenumfang und die Identität.
  2. Wechseln Sie nur dann zu PaaS-Agenten (Microsoft Foundry Agent Service, Azure SRE Agent, benutzerdefinierte Microsoft Copilot Studio-Agenten oder das Microsoft Agent Framework in einer verwalteten Laufzeit), wenn Standardlösungen nicht ausreichen. Du übernimmst Agentenlogik, Werkzeuge, Berechtigungen, Speicher und Identität.
  3. Baue IaaS-Agenten ausschließlich mit tiefer Expertise in KI-Sicherheit, Identität und Risiken autonomer Systeme. Du besitzt fast den gesamten Stapel.

Faustregel: Je mehr Autonomie und je breiter das Werkzeug und die Berechtigungsmenge sind, die du einem Agenten erteilst, desto mehr von der Verantwortungsmatrix verlagert sich auf dich, unabhängig vom Bereitstellungsmodell. Autonomie verringert nie die Verantwortlichkeit.

Nächste Schritte

  • Last updated on