MITRE T1700 KI-Exfiltration: Aufbau von Prüfprotokollen für Agentenzugriffe

Ihr eigener KI-Agent ist jetzt ein katalogisierter Datenabflusskanal

Der KI-Agent, der Ihre Verträge zusammenfasst, kann auch dazu gebracht werden, sie an eine fremde Person zu versenden – und der branchenweit meistgenutzte Katalog für Angriffsvektoren bestätigt dies nun schriftlich. MITRE hat AI-Enabled Exfiltration, Technik T1700, im Oktober 2026 mit Version 20 in ATT&CK aufgenommen. Sie beschreibt Angreifer, die durch Prompt Injection Unternehmens-KI-Agenten dazu bringen, Daten aus dem Unternehmen herauszuschleusen. Das ist kein theoretisches Forschungsthema, sondern eine benannte und nummerierte Technik mit zugehöriger Erkennungsmethodik. Damit erhalten Auditoren und Rechtsabteilungen eine gemeinsame Sprache für eine Frage, die die meisten Vorstände noch nicht beantwortet haben.

Eine zweite Meldung erschien im gleichen Zeitraum: Microsoft und NVIDIA veröffentlichten gemeinsam Empfehlungen für Unternehmen, die Open-Weight-Modelle auf eigener Infrastruktur betreiben. Sie weisen darauf hin, dass Unternehmen Sicherheits- und Schutzmaßnahmen selbst bereitstellen müssen, die sonst vom Modellanbieter übernommen würden. Forscher zeigen immer wieder, warum das wichtig ist: Ein Modell mit verstecktem Trigger kann monatelang unauffällig agieren und gibt Zugangsdaten erst dann preis, wenn eine bestimmte Phrase auftaucht.

Beide Nachrichten beleuchten ein Problem aus zwei Perspektiven: Sie können nicht beweisen, dass ein Modell sauber ist, und Sie können nicht davon ausgehen, dass ein Agent nur das tut, was sein Anwender beabsichtigt. Was Sie jedoch nachweisen können – wenn Sie es entsprechend umsetzen – ist, auf welche Daten ein Agent Zugriff hatte und was er tatsächlich verarbeitet hat. Genau diesen Nachweis fordert die Aufsicht, und genau dafür ist der sichere Datenaustausch von Kiteworks konzipiert.

wichtige Erkenntnisse

1. MITRE benennt nun den Agenten selbst als Exfiltrationspfad.

Technik T1700 beschreibt, wie Angreifer über zugelassene Tool-Verbindungen die eigenen KI-Agenten eines Unternehmens dazu bringen, Daten herauszugeben.

2. Erkennungsmethoden setzen Aufzeichnungen voraus, die oft fehlen.

MITREs Analysen für T1700 schlagen Alarm, wenn ein Agent auf Daten außerhalb seines autorisierten Bereichs zugreift – das funktioniert aber nur, wenn dieser Bereich auch dokumentiert ist.

3. Selbst gehostete Modelle verlagern Schutzmaßnahmen ins eigene Team.

Microsoft und NVIDIA betonen, dass allein die Offenheit der Gewichte kein Risiko bestimmt. Bei selbst betriebenen Deployments müssen Unternehmen Schutzmaßnahmen selbst umsetzen, die ein Managed Service sonst bereitstellt.

4. Sie können ein Modell nicht durch Tests als sauber beweisen.

Forscher haben Open-Weight-Modelle mit Backdoors gezeigt, die sich erst bei einem Trigger bemerkbar machen. Herkunftsnachweise und Zugriffsbeschränkungen auf Daten sind daher wichtiger als reines Verhaltenstesting.

5. Regulierungsbehörden regulieren Daten, nicht Modelle.

Die belastbare Position ist ein Nachweis darüber, auf welche Daten ein Agent im Auftrag einer bestimmten Person zugreifen durfte und was er tatsächlich verarbeitet hat.

Was T1700 über Ihre Agenten aussagt

Die Technikseite von MITRE beschreibt, dass Angreifer direkte oder indirekte Prompt Injection oder andere Methoden nutzen können, um Unternehmens-KI-Agenten zum Datenabfluss zu bewegen. Da diese Agenten oft über zugelassene Tool-Verbindungen verfügen, kann ein Angreifer die bereits eingerichteten Tools missbrauchen. Die Version-20-Ankündigung von MITRE katalogisiert die beiden Injection-Wege als separate Techniken: T1699 für Anweisungen, die direkt in eine LLM-Oberfläche eingegeben werden, und T1698 für Anweisungen, die in Inhalte eingebettet sind, die das Modell verarbeitet.

Betrachten Sie den zweiten Weg genauer: Ein Vertrag, ein Support-Ticket, eine Webseite oder ein geteiltes Dokument kann die Anweisung enthalten – niemand auf Ihrer Seite muss etwas Ungewöhnliches anklicken. Der Agent tut, wofür er konfiguriert wurde, mit den ihm zugewiesenen Berechtigungen, im Namen eines Nutzers, der vollen Zugriff auf diese Daten hat. Der Datenabfluss sieht aus wie normale Arbeit.

Die von MITRE empfohlenen Gegenmaßnahmen sind aufschlussreich. Eine fordert, KI-Systeme innerhalb des Unternehmensnetzwerks ohne externen Zugriff zu betreiben, um Exfiltration zu begrenzen. Eine andere empfiehlt, Datei- und Verzeichnisberechtigungen so einzuschränken, dass Agenten nur auf notwendige sensible Daten zugreifen können. Die dritte ist Anwenderschulung. Zwei der drei Maßnahmen betreffen Daten und Berechtigungen, nicht das Modell selbst. Dieses Muster unterstreicht das Argument von Bonfy.AI, dass Berechtigungen allein nicht bestimmen, was KI nutzen darf.

Auch auf der Erkennungsseite gibt es Herausforderungen: MITREs Erkennungsstrategie für diese Technik umfasst Analysen, die prüfen, ob ein KI-bezogener Prozess auf Daten außerhalb seines autorisierten Bereichs zugreift und anschließend eine Verbindung zu einem nicht autorisierten Ziel herstellt, sowie ob ein Agent geschützte Daten mit einem Tool oder einer API verwendet, wenn der empfangende Dienst einen Transfer außerhalb autorisierter Datenflüsse protokolliert. Diese Analysen setzen voraus, dass ein schriftlich definierter autorisierter Bereich für den Agenten existiert – etwas, das den meisten Unternehmen fehlt. Das ist das sogenannte Scope-Vakuum: Die Erkennungsmethodik ist bereit, aber der Referenznachweis fehlt.

Der Großteil von Version 20 betrifft andere

Die Zusammenfassung von SecurityWeek zählt 15 neue Erkennungsstrategien, sechs für Enterprise- und neun für industrielle Steuerungssysteme, unterstützt durch 38 Analysen. Vieles davon betrifft andere Zielgruppen. Eine neue Kampagne verfolgt Angriffe auf internet-exponierte speicherprogrammierbare Steuerungen bei über 30 Wasser- und Abwasserbetrieben in Minnesota, wobei die Urheberschaft noch ungeklärt ist. Eine weitere Technik behandelt den Diebstahl von anwendungsspezifischen Passwörtern, die MFA umgehen können – ein Problem auf Identitätsebene. Beides sind keine Themen, die einen Compliance-Verantwortlichen in diesem Quartal beschäftigen werden.

Für einen CISO oder Chief Compliance Officer ist die relevante Perspektive enger gefasst: Ein Teil des Releases betrifft direkt Ihr Nachweisproblem – nämlich die Cluster rund um KI-Agenten und Prompt Injection. Es wäre einfach, das gesamte Release als Beweis für eine dramatische Bedrohung zu zitieren. Das wäre aber falsch. Der sinnvolle Ansatz ist, die eine Technik zu nehmen, die zu einer konkreten Prüfungsfrage passt, und den Nachweis dafür zu schaffen.

Regulierungsbehörden regulieren Daten, nicht Modelle

Denken Sie an einen Claims-Review-Agenten bei einer regionalen Krankenversicherung: Er liest Mitgliederakten, erstellt Ablehnungsschreiben und veröffentlicht Zusammenfassungen in einem geteilten Workspace. Das ist ein hypothetisches Beispiel, aber die Architektur ist verbreitet. Wenn ein manipuliertes Dokument den Agenten dazu bringt, eine Mitgliederakte an eine ausgehende Nachricht anzuhängen, spielt es keine Rolle, ob ein Mensch oder ein Modell den letzten Schritt ausgeführt hat – die Mitgliederakte hat das Unternehmen verlassen.

Die HIPAA-Sicherheitsregel interessiert sich nicht dafür, wer oder was die Akte gelesen hat. Nach 45 CFR 164.312 ist eine eindeutige Benutzeridentifikation vorgeschrieben, und der Standard für Prüfprotokolle verlangt Mechanismen, die Aktivitäten in Informationssystemen mit elektronischen Gesundheitsdaten aufzeichnen und prüfen. Keine dieser Vorgaben macht eine Ausnahme für Zugriffe durch KI-Agenten. Dies ist allgemeine Information, keine Rechtsberatung – klären Sie Details mit Ihren Datenschutz– und Rechtsabteilungen.

Ein Agent, der im Auftrag einer Person agiert, übernimmt deren Identitätsproblem. Läuft er unter einem geteilten Service-Account, zeigt der Audit-Trail nur den Service-Account, nicht die tatsächlich verantwortliche Person. So entstehen Protokolle, die zwar existieren, aber die entscheidende Prüfungsfrage nicht beantworten können. Bonfy.AI argumentiert ähnlich: Was Sie nicht zuordnen können, können Sie nicht steuern.

Das Scope-Vakuum zeigt sich auch in Umfragedaten: Der 2026 AI-Ready Governance Survey Report von OneTrust, eine Befragung von 1.200 Führungskräften aus acht Ländern, ergab, dass 87 Prozent der Unternehmen KI-Agenten fördern, aber nur 47 Prozent klare Governance, Aufsicht und Kontrollmechanismen etabliert haben.

Vierzig Prozentpunkte Differenz – genau in dieser Lücke landen die Fragen der Auditoren. Es ist eine Lücke in Dokumentation und Durchsetzung, nicht primär in der Technik.

Wer die Gewichte hostet, übernimmt die Schutzmaßnahmen

In einem Microsoft-Sicherheitsblog vom 16. Oktober 2026 stellt Michael Scovetta ein gemeinsames Papier von Microsoft und NVIDIA mit dem Titel „Risk Management for Open-Weight Models in Enterprise“ vor. Das Papier unterteilt Risiken in fünf Kategorien: Cybersecurity, Datenschutz, Inhalt, Mensch-KI-Interaktion und Bias – und ist der Auftakt einer geplanten Serie. Eine zugehörige Taxonomie ist im öffentlichen GitHub-Repository dokumentiert und wird dort fortlaufend überprüft.

Für Compliance-Verantwortliche sind zwei Punkte entscheidend: Die Offenheit der Gewichte allein bestimmt das Risiko nicht – es hängt vom Modell, Use Case, Deployment und den umgebenden Schutzmaßnahmen ab. Die Verantwortung für Schutzmaßnahmen richtet sich nach Service und Deployment. Bei selbst betriebenen Deployments müssen Unternehmen Kontrollen übernehmen, die ein Managed Service sonst bereitstellt.

Beachten Sie, was sonst noch auf der Prüfliste steht: Berechtigungen, Datenzugriff, Tools und Laufzeitkontrollen stehen gleichberechtigt neben dem Modell selbst. Die Autoren sagen: Das Modell ist ein Input für die Risikoanalyse, aber nicht das Ganze. Wer bisher „Welches Modell nutzen wir?“ als Hauptentscheidung für KI-Risiken betrachtet hat, muss umdenken – das bestätigen selbst die Cloud-Anbieter. Es handelt sich um eine Frage des Lieferkettenrisikos, und das Supply Chain Risk Management bietet dafür seit Langem die passende Sprache.

Die Laborergebnisse zeigen die Dringlichkeit: In einer am 6. Oktober 2026 veröffentlichten Studie hat ProjectDiscovery ein kleines Open-Weight-Modell, Qwen2.5-7B-Instruct, mit Funktionsaufrufdaten feinjustiert, von denen etwa ein Fünftel manipuliert war. Bei Auftreten einer Trigger-Phrase rief das Modell ein Tool auf, das eine Remote-Payload herunterlud und ausführte. Über OpenAIs Codex CLI las die Payload Umgebungsdateien im Arbeitsverzeichnis aus und sendete deren Inhalt an einen Collector. Ohne Trigger verhielt sich das Modell normal.

Das ist ein Laborergebnis, kein Vorfall. Die Forscher wählten den Trigger und nutzten Dummy-Zugangsdaten. Entscheidend ist die Struktur: Die Gewichte zeigen keinen sichtbaren Hinweis, das Verhalten bleibt inaktiv, und der Schaden hängt davon ab, auf welche Ressourcen der Agent Zugriff hat. Ein Modell, das Ihre Umgebungsdatei nicht lesen kann, kann sie auch nicht weitergeben. Die Zugangsdaten wurden kompromittiert, weil das Arbeitsverzeichnis erreichbar war.

Sie können ein Modell nicht durch Tests als sauber beweisen

Eine zweite Studie unterstreicht das Problem: Forscher von Pillar Security und Fujitsu Research of Europe beschreiben in einem arXiv-Paper einen Angriff namens BadEngram, bei dem ein Angreifer ein bereits trainiertes Modell manipuliert, indem er ein Memory-Subsystem verändert und eine Backdoor einbaut. Im Praxistest mit dem Open-Weight-Modell Qwen3.8-Flash-Next verhielt sich das manipulierte Modell ohne Trigger weitgehend wie erwartet. Das Paper geht davon aus, dass das veränderte Artefakt akzeptiert wird, untersucht aber nicht, wie Integritätsprüfungen umgangen werden könnten.

Gerade dieser Punkt ist entscheidend: Verhaltenstests entdecken keine Backdoor, die darauf ausgelegt ist, unauffällig zu bleiben. Die Autoren empfehlen stattdessen Integritätsprüfungen anhand vertrauenswürdiger Referenzen. Ob die Gewichte mit denen eines vertrauenswürdigen Publishers übereinstimmen, ist eine Frage der Provenienz – also der Nachverfolgbarkeit. Das ist eine Frage der Dokumentation, und genau das können Prüfer verlangen.

Sicherheitsforscher Bruce Schneier bringt es in einem Beitrag zu Backdoors in Open-Weight-Modellen auf den Punkt: KI-Systeme sind für alle Supply-Chain-Angriffe anfällig, die auch normale Software betreffen. Ihr Software-Supply-Chain-Programm kennt bereits den Umgang mit nicht verifizierten Artefakten. Die offene Frage ist, ob das KI-Team weiß, dass dieselben Regeln auch für sie gelten.

F5 Labs liefert praktische Details in seiner Analyse chinesischer Open-Weight-Modelle vom 30. Juli 2026: Für die meisten untersuchten Modelle werden Trainingsdaten nicht offengelegt, und die Integrität der Trainingspipeline ist nicht garantiert. Viele Modelfiles nutzen Pickle-Serialisierung, die beim Laden beliebigen Code ausführen kann. Repository-Scans bieten keine Sicherheit. Die Empfehlung lautet: Nachweisbare Provenienz, isolierte Tests und Datenformate wie Safetensors, wo möglich.

Der Bericht von Help Net Security zum Microsoft- und NVIDIA-Papier empfiehlt kryptografische Signaturen zur Provenienzfeststellung – noch vor der Verhaltensprüfung. Nicht signierte Modelle gelten als offenes Risiko. Sollte sich diese Empfehlung im vollständigen Papier bestätigen, liefert sie CISOs einen konkreten Punkt für das Risikoregister: Ein nicht signiertes Artefakt wird zur dokumentierten Ausnahme mit Verantwortlichem und Prüftermin, statt zur stillschweigenden Annahme.

Provenienz beantwortet, woher ein Artefakt stammt und ob es verändert wurde – aber nicht, wie sich das System im Betrieb verhält. Deshalb liegt der prüfbare Nachweis eine Ebene darüber: in der Dokumentation, auf welche Daten das System zugreifen durfte.

Warum die Datenebene den belastbaren Nachweis liefert

Wenn die Modellebene nicht als sauber nachgewiesen werden kann, muss der Nachweis auf der Datenebene erfolgen. Das Argument, dass der eigentliche Kontrollpunkt für agentische KI die Datenebene ist, ist für einen CCO entscheidend – denn hier findet Regulierung statt und hier kann ein Nachweis erbracht werden.

So sieht das in der Praxis aus: Der Kiteworks Secure MCP Server ermöglicht KI-Assistenten den Zugriff auf Inhalte in Kiteworks über das Model Context Protocol mit OAuth 2.0 Authorization Code Flow und PKCE. Tokens verbleiben im Credential Store des Betriebssystems und gelangen nie in den Kontext des Modells – eine injizierte Anweisung kann sie also nicht auslesen. Jede Operation wird gegen die gleichen RBAC– und ABAC-Richtlinien geprüft, die auch für den menschlichen Anwender gelten, für den der Agent agiert – der Agent übernimmt dessen Berechtigungen und kann diese nicht überschreiten. Konfigurierbares Rate Limiting begrenzt Massenabfragen.

Alle Aktivitäten werden im zentralen Audit-Log erfasst, und Audit-Events können in Echtzeit über Syslog oder den Splunk Forwarder an ein SIEM übertragen werden. Kiteworks Compliant AI setzt diesen Governance-Ansatz für KI-Workflows um, sodass ein einziger Nachweis existiert, auf welche Daten ein Agent zugreifen durfte und was er tatsächlich genutzt hat – statt drei separater Rekonstruktionen. Das erkennt keine Backdoors im Modell – und soll es auch nicht. Es begrenzt, was ein manipulierter Agent über den Governance-Kanal erreichen kann, und dokumentiert, was passiert ist.

Auch Kiteworks‘ eigene Forschung zeigt die gleiche Schwachstelle: Der Kiteworks Data Security and Compliance Risk: 2026 Annual Survey Report ergab, dass 73 Prozent der 459 befragten Unternehmen keine Zweckbindungskontrollen für sensible Daten haben. Das bedeutet, dass KI-Agenten nicht auf autorisierte Aufgaben und Datenbereiche beschränkt sind. Im Vergleich zu MITREs Analysen ist das Scope-Vakuum damit messbar: Die Erkennungsmethodik vergleicht Verhalten mit einem autorisierten Bereich – und drei Viertel der Unternehmen haben diesen nicht durchgesetzt.

Die Beziehung zwischen Mensch und Agent ist hier entscheidend: Das stärkste Governance-Modell behandelt den Agenten als kontrollierten Kanal für eine namentlich benannte Person, nicht als eigenständigen Akteur. Zero trust data protection-Prinzipien wenden dieselbe Verifikation auf beide an. Die Arbeit von Bonfy.AI zu Authority Gaps in KI-Workflows beschreibt, was passiert, wenn delegierte Befugnisse nie dokumentiert werden.

Was ein belastbares Nachweispaket für einen Agenten enthält

Stellen Sie sich vor, die Anfrage trifft ein: Eine Aufsichtsbehörde, ein Prüfer oder ein gegnerischer Anwalt fragt nach einem bestimmten Agenten und einem bestimmten Datensatz. Eine belastbare Antwort besteht aus fünf Teilen, die jeweils auf MITREs Erkennungsmethodik abgestimmt sind.

Erstens: die Identität. Für welche benannte Person agierte der Agent, mit welchen Zugangsdaten? Zweitens: der Scope. Welche Lese-, Schreib- und Versandrechte hatte der Agent, und wer hat sie genehmigt? Drittens: das Zugriffsprotokoll. Was hat der Agent tatsächlich genutzt – mit Zeitstempeln, in einem vertrauenswürdigen Log? Viertens: das Ziel. Wohin wurden Daten gesendet, und lag dieser Transfer im autorisierten Rahmen? Fünftens: die Zeit. Können Sie all diese Nachweise im geforderten Zeitfenster liefern?

Die meisten Unternehmen können ein oder zwei dieser Punkte beantworten. Schwierigkeiten entstehen nicht durch fehlende Logs, sondern durch uneinheitliche Logs – weil die Aktivitäten des Agenten in der KI-Plattform, im Dateisystem, im E-Mail-Gateway und im Ticketing-Tool jeweils mit eigenen Zeitstempeln und Nutzerdefinitionen protokolliert werden. Ein konsolidiertes Audit-Log mit einheitlichen Begriffen macht aus wochenlanger Korrelation eine einzige Abfrage – das ist der Unterschied zwischen Nachweis und Erklärungsnot.

Sie müssen dazu nicht das Schlimmste über Ihre Modelle annehmen. Sie müssen nur davon ausgehen, dass irgendwann jemand fragt – und dass die Antwort dann schon vorliegen sollte.

Was Sie vor dem nächsten Audit tun sollten

Beginnen Sie mit Ownership: Weisen Sie jedem KI-Agenten, der sensible Inhalte verarbeitet – auch Pilotprojekten – einen namentlich benannten Owner und einen schriftlich autorisierten Scope zu. Wenn niemand sagen kann, wem ein Agent gehört, haben Sie das Verantwortlichkeitsvakuum gefunden – bevor es der Auditor tut. Die Verantwortung für KI-Sicherheit ist branchenweit ungeklärt; das Vakuum ist das Problem, nicht ein Organigramm.

Führen Sie als Nächstes eine Probe-Anfrage durch: Wählen Sie einen Agenten und einen sensiblen Datensatz, bitten Sie Ihr Team um Identität, Scope, Zugriffsprotokoll, Ziel und Zeitachse – und dokumentieren Sie, wo die Antwort scheitert. Behandeln Sie die Lücken als Findings. Verknüpfen Sie diese Übung mit Ihrem AI Data Governance-Programm, damit die Korrekturen in der Policy und nicht in einer Einzeltabelle landen.

Setzen Sie Open-Weight-Modelle denselben Prüfprozessen aus wie Ihre Software: Fordern Sie vom KI-Team einen Provenienz-Nachweis, behandeln Sie nicht signierte Artefakte als dokumentiertes Risiko mit Owner und Prüftermin, und fragen Sie nach den verwendeten Dateiformaten. Wenn darunter Serialisierungsformate sind, die beim Laden Code ausführen können, gehört das in das Ausnahmen-Log. Halten Sie auch die Frage der Datenminimierung präsent – ein Agent, der nie eine Datei erhält, kann sie auch nicht abfließen lassen.

Zuletzt: Übernehmen Sie T1700 in Ihr Risikoregister und benennen Sie einen Data Owner dafür. Der Katalog liefert die Sprache – wer zuerst fragt, will einen Nachweis sehen, und kein Weight-File kann diesen liefern.

Erfahren Sie mehr über die Governance von KI-Agenten-Zugriffen auf sensible Inhalte mit prüfbereiten Nachweisen – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

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