Zero Trust für KI-Agenten, Teil 1: Warum KI-Agenten ein neues Risiko sind

In unserer Serie Zero Trust in der Praxis ging es um Menschen, Geräte und Daten. Inzwischen taucht in fast jedem Kundengespräch eine neue Art von Identität auf: KI-Agenten. Sie fassen Postfächer zusammen, beantworten Fragen aus SharePoint, legen Tickets an oder ändern Datensätze im CRM. Laut dem Microsoft Digital Defense Report 2026 experimentieren bereits 88 % der Unternehmen mit KI-Agenten. Damit wird eine Frage drängend: Wie wenden wir Zero Trust auf etwas an, das selbstständig denkt und handelt?

Was ist eigentlich ein KI-Agent?

Ein Chatbot beantwortet Fragen. Ein Agent dagegen verfolgt ein Ziel und handelt dafür selbstständig – er versteht den Kontext, trifft Entscheidungen und nutzt dafür Werkzeuge. Microsoft beschreibt in der Dokumentation zu Entra Agent ID vier Bausteine, aus denen fast jeder Agent besteht:

• Modell: Das Sprachmodell ist der zentrale Entscheider. Es interpretiert die Anfrage und plant die nächsten Schritte.
• Orchestrierung: Die Schleife aus Aufnehmen, Nachdenken und Handeln. Sie läuft so lange, bis das Ziel erreicht ist oder ein Abbruch greift.
• Gedächtnis: Kontext aus Unterhaltungen, Dokumenten oder Vektordatenbanken, der dem Agenten aktuelle Informationen liefert.
• Werkzeuge: Schnittstellen zu E-Mail, Dateien, Datenbanken, APIs oder anderen Agenten. Erst sie machen aus Text eine Handlung.

Entscheidend für die Sicherheit ist der letzte Punkt: Ein Agent ist nur so gefährlich wie die Werkzeuge und Rechte, die er hat. Ein Agent, der nur lesen darf, kann höchstens etwas Falsches erzählen. Ein Agent, der E-Mails versenden, Dateien teilen oder Benutzer anlegen darf, kann dagegen echten Schaden anrichten.

Drei Arten, wie Agenten arbeiten

Für die Absicherung ist wichtig, in wessen Namen ein Agent handelt. Microsoft unterscheidet drei Muster:

Muster	So arbeitet der Agent	Beispiel
Im Auftrag eines Benutzers	Der Agent nutzt die Rechte der angemeldeten Person (delegierter Zugriff)	Ein Copilot-Agent fasst die eigenen E-Mails zusammen
Autonom	Der Agent handelt mit eigener Identität, ohne angemeldete Person	Ein Agent prüft nachts eingehende Rechnungen
Als eigener Benutzer	Der Agent bekommt ein eigenes Benutzerkonto, weil ein System das verlangt	Ein „digitaler Kollege“ mit Postfach und Teams-Zugang

Je autonomer der Agent, desto weniger greifen die Schutzmechanismen, die wir für Menschen gebaut haben. Ein Agent kann nämlich keine MFA-Anfrage bestätigen, hat kein verwaltetes Gerät und keinen Standort. Deshalb braucht er eigene Regeln – dazu mehr in Teil 3.

Wo Agenten bei euch entstehen

Agenten kommen heute aus vielen Richtungen ins Unternehmen, und genau das macht sie schwer zu überblicken:

• Microsoft 365 Copilot mit vorgefertigten Agenten und dem Agent Builder, mit dem Mitarbeitende ohne Programmierung eigene Agenten erstellen.
• Copilot Studio für Fachabteilungen und Power-Platform-Teams, die Agenten mit Wissensquellen, Konnektoren und Abläufen bauen.
• Microsoft Foundry für Entwicklerinnen und Entwickler, die Agenten mit eigenem Code, eigenen Modellen und eigenen Werkzeugen entwickeln.
• Agenten von Drittanbietern – etwa in SaaS-Anwendungen, auf AWS Bedrock oder in Automatisierungsplattformen wie n8n.
• Lokale Agenten auf Entwicklerrechnern, die per MCP auf Werkzeuge zugreifen.

Wie ihr die beiden wichtigsten Baukästen von Microsoft – Copilot Studio und Foundry – sicher aufstellt, zeigen wir ausführlich in Teil 2.

Die neuen Angriffe

Microsoft hat in seiner Zero-Trust-Dokumentation einen Katalog von KI-Angriffstechniken veröffentlicht, mit 14 Szenarien und Zuordnung zu den OWASP Top 10 für LLMs und zu MITRE ATLAS. Für Agenten sind vor allem diese relevant:

Prompt Injection – direkt und indirekt

Bei der direkten Variante versucht jemand, den Agenten mit geschickt formulierten Eingaben zu etwas zu bringen, das er nicht darf („Ignoriere deine Anweisungen und …“). Gefährlicher ist jedoch die indirekte Variante, auch XPIA genannt: Die Anweisung steckt in Inhalten, die der Agent verarbeitet – in einer E-Mail, einer Webseite oder einem Dokument, oft unsichtbar in weißer Schrift oder in Metadaten. Der Agent liest sie und führt sie aus, obwohl der Benutzer nie danach gefragt hat. Microsoft Defender for Office 365 Plan 2 erkennt solche Inhalte inzwischen sogar in eingehenden E-Mails.

Zu viel Handlungsspielraum

Microsoft nennt das „Excessive Agency“: Ein Agent hat mehr Rechte oder mehr Autonomie, als seine Aufgabe erfordert. Das ist weniger ein einzelner Angriff als eine gefährliche Ausgangslage. Sprachmodelle können sich irren oder manipuliert werden – und wenn sie dann ohne menschliche Kontrolle handeln dürfen, wird aus einem Fehler ein Sicherheitsvorfall.

Vergiftetes Gedächtnis und vergiftete Daten

Agenten mit dauerhaftem Gedächtnis lassen sich über mehrere Sitzungen hinweg beeinflussen. Ein Angreifer „erklärt“ dem Agenten zum Beispiel wiederholt, dass bestimmte Anhänge nach außen weitergeleitet werden dürfen. Ähnlich wirken manipulierte Dokumente in den Wissensquellen, auf die ein Agent zugreift.

Manipulierte Werkzeuge und MCP-Server

Agenten binden immer häufiger Werkzeuge über das Model Context Protocol (MCP) an. Ein Werkzeug, das heute harmlos ist, kann morgen durch eine neue Version ersetzt werden, die Daten abgreift – Microsoft spricht vom „Rug-Pull“. Deshalb gehören Werkzeuge genauso in eine Freigabe wie Software.

Agenten-Wildwuchs

Schließlich das organisatorische Problem: Agenten entstehen schnell, werden geteilt und vergessen. Ohne Inventar weiß niemand, welche Agenten es gibt, wem sie gehören und auf welche Daten sie zugreifen. Verwaiste Agenten mit weitreichenden Rechten sind genau die Art von Lücke, die Angreifer suchen.

Drei Kontrolllücken hinter fast jedem Angriff

Der Microsoft-Katalog bringt es auf eine bemerkenswert einfache Formel. Fast jeder Angriff auf KI-Systeme lässt sich auf eine von drei fehlenden Kontrollen zurückführen:

1. Keine Vertrauensgrenze bei Eingaben – der Agent behandelt fremde Inhalte wie Anweisungen.
2. Keine Integrität der Daten – Wissensquellen, Gedächtnis oder Trainingsdaten lassen sich unbemerkt verändern.
3. Keine Eindämmung bei der Ausführung – der Agent darf mehr tun, als nötig ist, und niemand bremst ihn.

Genau hier setzen die drei Prinzipien von Zero Trust an, die ihr aus Teil 1 unserer Zero-Trust-Serie kennt.

Zero Trust für Agenten – die drei Prinzipien übertragen

Prinzip	Für Menschen	Für Agenten
Explizit überprüfen	MFA, Gerätezustand, Anmelderisiko	Eigene Agenten-Identität, Conditional Access für Agenten, Agenten-Risiko
Minimale Rechte	PIM, Just-in-Time, Zugriffsprüfungen	Nur benötigte Werkzeuge und Berechtigungen, Freigabe kritischer Aktionen durch Menschen
Von Kompromittierung ausgehen	EDR, Segmentierung, SOC	Schutz zur Laufzeit, Leitplanken für Ein- und Ausgaben, Protokollierung jeder Aktion

Dazu kommt ein Grundsatz, der bei Agenten besonders wichtig ist: Jeder Agent braucht einen verantwortlichen Menschen. Microsoft nennt diese Rolle „Sponsor“. Wenn ein Agent auffällig wird, muss jemand erreichbar sein, der weiß, wozu er da ist – und ihn notfalls abschaltet.

Wie es weitergeht

In den nächsten vier Teilen gehen wir die Absicherung Schritt für Schritt durch:

• Teil 2: Wo Agenten entstehen – Copilot Studio und Microsoft Foundry sicher aufstellen.
• Teil 3: Identität und Zugriff – Entra Agent ID und Conditional Access für Agenten.
• Teil 4: Daten schützen – Oversharing beseitigen, bevor die KI es findet.
• Teil 5: Überwachen und steuern – Agent 365, Defender und eine Roadmap für den Einstieg.

Offizielle Microsoft-Quellen

• Was sind Agenten-Identitäten?
• Katalog der KI-Angriffstechniken (CAAT)
• KI-Sicherheit im Zero Trust Workshop
• Prompt Injection – direkt und indirekt
• Microsoft Digital Defense Report 2026