Microsoft nennt 7 Wege, wie Ihre KI-Agents gehackt werden können. Einer davon tritt bereits in der Praxis auf.

Auf der Microsoft Build 2026 hat das Security Research Team seine bestehende Bedrohungstaxonomie für KI-Agents um sieben neue Kategorien erweitert, die das aktuelle Vorgehen von Angreifern und die Versäumnisse von Verteidigern in produktiven agentenbasierten Systemen widerspiegeln. Die Namensgebung ist entscheidend: „KI-Agents sind riskant“ ist eine Haltung; sieben spezifische, voneinander abgegrenzte Angriffsvektoren mit jeweils eigenen Gegenmaßnahmen bilden ein operatives Rahmenwerk.

Agentic Supply Chain Compromise. Anders als herkömmliche Supply-Chain-Angriffe, die auf Schadcode basieren, nutzt dieser Vektor natürliche Sprache. Das Verhalten eines Agents kann durch bösartige Inhalte in Prompts, abgerufenen Dokumenten oder Anweisungen von vorgelagerten Agents beeinflusst werden – ganz ohne Code-Injektion.

Goal Hijacking. Ein Angreifer bettet Anweisungen ein, die scheinbar zum legitimen Auftrag des Agents passen, lenkt aber unbemerkt dessen eigentliches Ziel um. Besonders gefährlich in mehrstufigen agentenbasierten Workflows, in denen der Agent eigenständig Entscheidungen trifft.

Inter-Agent Trust Escalation. In Multi-Agent-Architekturen kann ein kompromittierter Agent einer orchestrierenden Instanz eine falsche Identität oder überhöhte Berechtigungen vortäuschen. Der Orchestrator akzeptiert mangels kryptografischer Verifizierung die Behauptung und gewährt unberechtigten Zugriff.

Computer Use Agent Visual Attack. Agents, die über grafische Oberflächen agieren, können durch bösartige Inhalte auf dem Bildschirm manipuliert werden – versteckte Anweisungen in Dokumenten, Webseiten oder UI-Elementen steuern die Aktionen des Agents über den visuellen Kanal um.

Session Context Contamination. Ein Angreifer schleust Daten ein, die die Argumentation des Agents über mehrere Schritte hinweg beeinflussen, ohne dass einzelne Entscheidungen Sicherheitskontrollen auslösen. Die Kontamination summiert sich über die gesamte Sitzung und führt zu einem kompromittierten Ergebnis, obwohl die einzelnen Eingaben harmlos erscheinen.

MCP/Plugin Abuse. In diese Kategorie fällt der Asana-Vorfall. Das Model Context Protocol schafft einen strukturierten Kanal, über den Agents mit externen Tools und Datenquellen interagieren. Schwachstellen in diesem Kanal – Logikfehler, falsch konfigurierte Berechtigungen oder böswillige Tools – können dazu führen, dass der Agent auf Daten zugreift, die ihm nicht zustehen, Daten exfiltriert oder organisationsübergreifend agiert.

Capability/Architecture Disclosure. Gibt ein Agent interne Implementierungsdetails preis – etwa System-Prompts, Tool-Funktionen oder verfügbare Integrationen – liefert das die Aufklärung für gezieltere Angriffe.

5 Wichtige Erkenntnisse

1. MCP/Plugin Abuse ist bereits ein Produktionsrisiko, kein theoretisches.

Beim Asana-MCP-Server-Breach 2025 wurden durch einen Logikfehler etwa 1.000 Unternehmen kompromittiert – Aufgaben, Projektdaten, Kommentare und hochgeladene Dateien waren organisationsübergreifend sichtbar. Microsoft hat diese Kategorie nun offiziell in die aktualisierte KI-Agenten-Bedrohungstaxonomie aufgenommen. Der Kiteworks Secure MCP Server begegnet diesem Risiko, indem er Richtlinien bereits auf Protokollebene durchsetzt – genau die Governance-Schicht, die der Asana-Vorfall als notwendig aufgezeigt hat.

2. Microsofts Build 2026-Antwort liefert Durchsetzungs-Infrastruktur, nicht nur Richtlinien.

Execution Container, Agent Control Specifications und das ASSERT-Toolset schaffen eine Governance-Schicht zur Laufzeit, die Security-Teams gegen konkrete Bedrohungsszenarien einsetzen können. Der Execution Container erzwingt explizite Grenzen zur Laufzeit, statt Agents auf Selbstbeschränkung zu vertrauen. Agent Control Specifications sind portable, revisionssichere Richtliniendefinitionen, die unabhängig vom Agent versioniert werden können. ASSERT operationalisiert alle sieben Fehlerarten durch adversarial Test-Frameworks. Das ist jetzt Ingenieursdisziplin – mit benannten Vektoren und veröffentlichten Gegenmaßnahmen.

3. Die sieben Fehlerarten bieten Red Teams eine konkrete Checkliste.

Agentic Supply Chain Compromise, Goal Hijacking, Inter-Agent Trust Escalation, Computer Use Agent Visual Attack, Session Context Contamination, MCP/Plugin Abuse und Capability/Architecture Disclosure sind jetzt dokumentierte Angriffsflächen, die gezielte Tests erfordern. Microsoft empfiehlt, Agenten-Lieferketten zu inventarisieren, Identitäten kryptografisch statt per Behauptung zu prüfen und alle sieben Vektoren in Red-Team-Matrizen aufzunehmen.

4. Herkömmliche IAM- und DLP-Kontrollen decken agentenbasiertes Verhalten nicht ab.

KI-Agents arbeiten asynchron, verketten Tool-Aufrufe und handeln im Namen von Anwendern auf Arten, die bestehende Perimeter- und Identitätskontrollen nicht abdecken. DLP-Tools prüfen bekannte Kanäle; Agents rufen externe APIs auf und verarbeiten Inhalte aus Quellen außerhalb dieser Kanäle. Eine dedizierte Governance-Schicht für KI-Inhalte – die steuert, welche sensiblen Inhalte Agents abrufen, verarbeiten und übertragen dürfen – ist erforderlich.

5. Regulierte Branchen sind besonders exponiert.

Greifen KI-Agents über falsch konfigurierte MCP-Integrationen auf CUI, PHI oder ITAR-kontrollierte Daten zu, entsteht sowohl ein Sicherheitsvorfall als auch ein Compliance-Verstoß. CMMC, HIPAA und DSGVO gelten auch dann, wenn der Akteur ein KI-Agent ist – der Zugriff muss autorisiert, protokolliert und abgesichert sein, wie es für menschlichen Zugriff auf regulierte Inhalte vorgeschrieben ist.

MCP/Plugin Abuse: Von der Taxonomie zum Produktionsvorfall

Asana hat am 1. Mai 2025 die MCP-Server-Integration mit LLM-Funktionen eingeführt. Ein Logikfehler in der Implementierung ermöglichte es Anwendern einer Organisation, Daten aus anderen Asana-Instanzen einzusehen – Aufgaben, Projektdaten, Teamdetails, Kommentare, Diskussionen und hochgeladene Dateien. Die Sichtbarkeit war durch den jeweiligen Zugriffsumfang begrenzt, aber es handelte sich um organisationsübergreifende Datenfreigabe durch eine KI-Integration, der Unternehmen eigentlich vertrauen sollten.

Asana entdeckte den Fehler im Juni 2025, etwa einen Monat nach dem Go-Live der MCP-Funktion. Rund 1.000 Kunden waren betroffen. Die Lehre daraus ist nicht, dass MCP grundsätzlich unsicher ist – das Protokoll ist eine Kommunikationsschicht. Entscheidend ist, dass das Protokoll eine zusätzliche Governance-Schicht benötigt: explizite Richtlinien, die festlegen, auf welche Daten ein Agent unter welchen Bedingungen und in welchem Umfang zugreifen darf. Fehlt diese Schicht, übernimmt die MCP-Integration die Berechtigungen des zugrundeliegenden Dienstes – was in Multi-Tenant-SaaS-Umgebungen genau zu der Art von organisationsübergreifender Exponierung führt, wie sie Asana erlebt hat.

Microsoft hat diese Fehlerkategorie nun offiziell benannt und sie neben sechs weiteren Vektoren in eine Taxonomie aufgenommen, mit der Security-Teams ihre KI-Red-Team-Programme strukturieren sollten. Die Governance-Fehler bei MCP-Deployments sind keine exotischen Einzelfälle. Sie sind die vorhersehbare Folge leistungsfähiger Integrationen ohne ausreichende Richtliniendurchsetzung zwischen Mandanten.

Microsofts Antwort zur Laufzeit: Execution Container, ASSERT und Agent Control Specifications

Drei Komponenten der Build 2026 bilden gemeinsam das umfassendste, unternehmensgerechte KI-Agenten-Sicherheitsframework, das ein großer Anbieter bislang veröffentlicht hat.

Der Microsoft Execution Container erzwingt explizite Grenzen zur Laufzeit, statt Agents auf Selbstbeschränkung zu vertrauen. Agenten-Ausgaben, Plugin-Aufrufe und Tool-Invokationen werden als nicht vertrauenswürdige Ausführungspfade behandelt, die vor der Ausführung einer Richtlinienprüfung unterzogen werden – der Sicherheitsansatz wechselt von „Agent richtig konfigurieren und hoffen“ zu „Grenzen auf Ausführungsebene erzwingen, unabhängig vom Agentenverhalten“.

Agent Control Specifications sind portable Richtliniendefinitionen, die beschreiben, was ein Agent tun darf, welche Tools er aufrufen und welche externen Endpunkte er erreichen kann. Die Spezifikationen sind von der Agentenimplementierung getrennt – revisionssicher, versionierbar und aktualisierbar, ohne den Agent selbst zu ändern. Damit wird Agenten-Governance als Konfigurationsmanagement-Problem und nicht als eingebettetes Code-Problem behandelt.

ASSERT (Adversarial Stress and Security Evaluation for Resilient Thinking) operationalisiert die sieben Fehlerarten durch adversarial Test-Frameworks, die Security-Teams gegen produktive Agents einsetzen können, um spezifische Schwachstellen zu identifizieren, bevor Angreifer sie finden.

Warum herkömmliche Sicherheitskontrollen nicht ausreichen

Ein Anwender meldet sich an einer SaaS-Plattform an, gibt Anmeldedaten ein, besteht die MFA und arbeitet in einer definierten Sitzung. Audit-Logs erfassen, auf welche Dateien zugegriffen wurde. Ein KI-Agent macht all das nicht sauber: Er arbeitet asynchron, führt Hunderte von Tool-Aufrufen ohne menschliches Zutun aus, verkettet Anfragen und nutzt Daten aus einer Quelle, um eine andere abzufragen. Er handelt im Namen eines Anwenders, dessen Sitzung vielleicht schon Stunden zuvor beendet wurde.

Zero-trust-Architekturen liefern den richtigen konzeptionellen Rahmen – niemals vertrauen, immer verifizieren – aber die für menschliche Akteure entwickelten Verifizierungsmechanismen lassen sich nicht ohne Weiteres auf asynchrone Agents übertragen, die kontinuierliche Autorisierung über mehrstufige Tool-Chains benötigen. Microsofts Execution Container und Agent Control Specifications adressieren die Ausführungsebene. Die Datenebene – also die Steuerung, auf welche sensiblen Inhalte der Agent zugreifen, sie verarbeiten und übertragen darf – erfordert ein speziell entwickeltes Content-Governance-Framework, das über reine Laufzeit-Containment hinausgeht.

Compliance-Risiken in regulierten Branchen

Die von Microsoft benannten sieben Fehlerarten sind nicht nur Sicherheitsrisiken – sie sind potenzielle Compliance-Verstöße unter den Rahmenwerken, die den Umgang mit bestimmten Kategorien sensibler Inhalte regeln.

Für Defense Contractors unter CMMC 2.0 gilt: Ruft ein KI-Agent CUI aus einem Projektmanagementsystem ab und überträgt diese Daten über eine MCP-Integration an ein externes Tool, ist das ein CMMC-Compliance-Vorfall. Das Gleiche gilt für HIPAA: PHI, das durch den Kontext eines KI-Agents fließt, unterliegt denselben Zugriffs- und Prüfprotokoll-Anforderungen – unabhängig davon, ob der Akteur menschlich oder KI ist. Die DSGVO verlangt zusätzlich Datenminimierung: Holt ein Agent mehr Daten als für die Aufgabe nötig, kann er allein dadurch gegen die DSGVO verstoßen.

Unternehmen in regulierten Branchen dürfen die Governance von KI-Agents nicht als separates Programm neben bestehenden Compliance-Pflichten betrachten. Sie müssen dieselbe Datenklassifizierung, Zugriffskontrolle, Audit-Logging und Übertragungssicherheit, die für menschlichen Zugriff auf regulierte Inhalte gilt, auch auf KI-Agenten-Zugriffe ausweiten.

Zero-Trust-Content-Governance-Schicht für KI-Agents aufbauen

Der Kiteworks Secure MCP Server kapselt den KI-Agenten-Zugriff auf von Kiteworks verwaltete Inhalte in einem Policy Enforcement Point. Statt Agents Inhalte direkt aus beliebigen Quellen abrufen zu lassen, prüft der Secure MCP Server jede Anfrage anhand expliziter Zugriffsrichtlinien, bevor Daten an den Agenten weitergegeben werden – Durchsetzung auf Protokollebene, nicht auf Implementierungsebene des Agents.

Das Kiteworks AI Data Gateway erweitert dies auf unternehmensweite KI-Workflows und bietet einen kontrollierten Kanal für KI-Anfragen an sensible Content-Repositories mit klassifikationsbasierten Zugriffsregeln. CUI, PHI und andere regulierte Inhalte sind nur für explizit autorisierte KI-Agents zugänglich. Jede Interaktion wird in einem manipulationssicheren Audit-Log dokumentiert, das direkt ins SIEM fließt – genau die Nachweise, die CMMC-Prüfer, HIPAA-Auditoren und DSGVO-Aufsichtsbehörden bei der Prüfung von KI-Zugriffen auf sensible Inhalte verlangen.

Das Kiteworks Private Data Network erstreckt diese Governance über E-Mail, Filesharing, Managed File Transfer, SFTP, Web-Formulare und APIs hinweg – gesteuert durch eine Richtlinien-Engine und ein zentrales Audit-Log. Microsoft hat die Bedrohungen benannt und die Werkzeuge zur Durchsetzung auf Ausführungsebene bereitgestellt. Die entscheidende Frage für jedes Unternehmen bleibt, ob die Content-Governance-Schicht dem Risiko angemessen ist.

Erfahren Sie mehr über den Schutz Ihrer sensiblen Inhalte vor kompromittierten KI-Agents – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blog-Beitrag
  Zero‑Trust-Strategien für erschwinglichen KI-Datenschutz
• Blog-Beitrag
  Wie 77 % der Unternehmen bei der KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit der Datensicherheit spielen
• Blog-Beitrag
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blog-Beitrag
  Regulierungsbehörden wollen keinen KI-Policy-Check mehr. Sie verlangen den Nachweis der Wirksamkeit.