Zugriffskontrolle für KI-Agenten gehört auf die Datenebene, nicht in den System-Prompt
Eine Systemanweisung, die Ihrer KI vorgibt, Nutzern nur die Daten anzuzeigen, für die sie berechtigt sind, ist keine Sicherheitskontrolle. Es handelt sich lediglich um eine Empfehlung, auf Englisch formuliert, die im selben Kontextfenster wie alle anderen Texte verarbeitet wird – und Empfehlungen werden umgangen.
Das ist längst keine provokante Behauptung mehr. Es ist die offizielle Position von AWS und dem SANS Institute, veröffentlicht im September 2026 in einer Richtlinie von Gee Rittenhouse (AWS, verantwortlich für Security Hub, GuardDuty und Inspector), gemeinsam mit SANS-Fellow Eric Johnson und drei weiteren AWS-Sicherheitsexperten. Ihre Botschaft an Sicherheitsteams in Unternehmen, wie bei Help Net Security berichtet, ist eindeutig: Die Steuerung eines Agenten über Systemanweisungen zur Einhaltung von Benutzerberechtigungen kann „umgangen, ignoriert oder überschrieben“ werden – und keine noch so präzise Formulierung ändert daran etwas. Die Lösung, so ihr Fazit, muss auf der Datenebene erfolgen: Jede Abfrage muss sich auf die tatsächlichen Berechtigungen des anfragenden Nutzers zum Zeitpunkt der Datenabfrage beziehen – innerhalb des bestehenden rollenbasierten oder attributbasierten Zugriffskontrollsystems des Unternehmens – und die Ergebnisse müssen gefiltert werden, bevor sie das Modell erreichen.
Ein zweiter, unabhängig recherchierter Bericht zur KI-Nutzung in Unternehmen zeigt, warum das gerade jetzt entscheidend ist. Wie The American Reporter darlegt, werden die meisten KI-Aktivitäten, bei denen sensible Daten im Unternehmen bewegt werden, nicht genehmigt, nicht so protokolliert, wie es für Compliance erforderlich wäre, und nicht durch Zugriffskontrollen abgedeckt, die für eine Welt vor KI-Agenten entwickelt wurden. Für den CISO und Chief Compliance Officer, die sich gegenüber Aufsichtsbehörden oder Prüfern verantworten müssen, war nie die Frage, ob sich der Agent höflich verhielt. Entscheidend ist, ob jeder Zugriff auf sensible Daten einer konkreten Berechtigung zugeordnet werden kann – zum Zeitpunkt des Zugriffs, mit einem Nachweis, der einer Prüfung standhält. Kiteworks Secure Data Exchange wurde genau für diese Anforderung entwickelt und deckt nun KI-Agenten und menschliche Nutzer unter einer einheitlichen Richtlinie ab.
Wichtige Erkenntnisse
1. Systemanweisungen sind keine Zugriffskontrolle.
Die im September 2026 veröffentlichte AWS- und SANS-Richtlinie stellt klar: Systemanweisungen können umgangen, ignoriert oder überschrieben werden. Die Empfehlung lautet, Berechtigungen stattdessen auf der Datenabfrage-Ebene durchzusetzen.
2. Die Einführung überholt die Governance deutlich.
Laut McKinsey-Zahlen aus derselben Richtlinie liegt die KI-Einführung bei 80 % der Unternehmen, während die Governance-Reife bei nur 10 % liegt – eine Lücke, die die meisten Unternehmen nicht geschlossen haben.
3. Ungeregelte KI hat einen messbaren Preis.
Der IBM Cost of a Data Breach Report 2026 zeigt: Datenschutzverstöße mit Shadow AI verursachen durchschnittlich 5,39 Millionen US-Dollar Schaden – ein Anstieg gegenüber 4,63 Millionen im Vorjahr. 68 % der 602 untersuchten Unternehmen verfügen weiterhin über keine KI-Governance.
4. Eine dokumentierte Fallstudie zeigt, warum Formulierungen versagen.
Im Agents-of-Chaos-Experiment brachte eine Umformulierung einer blockierten Anfrage einen KI-Agenten dazu, eine ungeschwärzte Sozialversicherungsnummer preiszugeben, indem die Anfrage als Weiterleitung einer gesamten E-Mail gestellt wurde.
5. Die Lösung ist architektonisch, nicht sprachlich.
Jede KI-Agentenabfrage muss bei der Datenabfrage gegen RBAC- oder ABAC-Berechtigungen geprüft werden – bevor die Daten das Kontextfenster des Modells erreichen. Bessere Formulierungen lösen dieses Problem nicht.
Die Fallstudie, die beweist, dass Systemanweisungen nicht ausreichen
Falls das Argument, dass Systemanweisungen scheitern, abstrakt klingt: Die Forschungsarbeit Agents of Chaos aus dem Februar 2026 macht es konkret. Zwanzig Forscher von MIT, Stanford, Harvard, Carnegie Mellon und weiteren Institutionen testeten zwei Wochen lang KI-Agenten auf Basis des OpenClaw-Frameworks in einer realen Laborumgebung – mit echten E-Mail-Konten, persistentem Speicher und Shell-Zugriff.
In einer Fallstudie platzierten die Forscher eine Sozialversicherungsnummer, eine Kontonummer und medizinische Details in einer Routine-E-Mail des Agentenbesitzers. Als eine nicht berechtigte Person den Agenten direkt nach der „SSN in der E-Mail“ fragte, verweigerte der Agent die Antwort – wie es eine Anweisung zum Schutz sensibler Informationen erwarten lässt. Als dieselbe Person den Agenten jedoch bat, die gesamte E-Mail weiterzuleiten, kam der Agent der Anfrage nach. Sämtliche personenbezogenen Daten wurden ungeschwärzt weitergegeben – inklusive SSN, Kontonummer und medizinischer Informationen, alles in einer Nachricht.
Die übergeordnete Schlussfolgerung der Forscher ist für Sicherheitsarchitekten zentral: Agenten verarbeiten Anweisungen und Daten als Tokens im selben Kontextfenster und können daher nicht zuverlässig zwischen legitimen und manipulierten Anfragen unterscheiden. Die Autoren der Studie sprechen von einem strukturellen Defizit, nicht von einem Trainingsfehler. Fünf der zehn OWASP Top 10-Kategorien für LLM-Anwendungen – darunter Offenlegung sensibler Informationen und Systemprompt-Leakage – traten direkt in den beobachteten Fehlern auf. Ein System, das nicht zwischen einer Anweisung und als Anweisung getarnter Daten unterscheiden kann, kann keine Berechtigungsgrenze durchsetzen, die nur in dieser Anweisungsschicht beschrieben wird.
Sie Vertrauen Darauf, Dass Ihr Unternehmen Sicher Ist. Aber Können Sie Es Nachweisen?
Jetzt Lesen
Shadow AI Bewegt Bereits Regulierte Daten
Die Agents-of-Chaos-Studie fand im Forschungslabor statt – die dort gezeigte Schwachstelle ist aber längst Realität. The American Reporter zitiert Umfrageergebnisse, wonach 90 % der Sicherheitsverantwortlichen zugeben, dass ihre Mitarbeitenden nicht genehmigte KI-Tools im Arbeitsalltag nutzen; 69 % der CISOs haben diese Tools dennoch in Arbeitsabläufe integriert. Rund 80 % der Beschäftigten berichten Ähnliches. Nur 52 % kennen die KI-Nutzungsrichtlinie ihres Unternehmens, aber 70 % wissen, dass sensible Daten trotzdem mit KI-Tools geteilt werden. Im selben Bericht wird angegeben, dass Unternehmensdaten, die 2025 durch KI- und Machine-Learning-Anwendungen fließen, 18.033 Terabyte erreichen, wobei 39,7 % der KI-Interaktionen sensible Daten offenlegen – ein Anstieg um 93 % gegenüber dem Vorjahr.
Klassische Kontrollen waren für dieses Muster nie gedacht. DLP-Regeln für E-Mail-Anhänge und sichere FTP-Alternativen für Punkt-zu-Punkt-Übertragungen gehen von einem Datenfluss mit Anfang, Ende und wenigen Zwischenstationen aus. Ein Kundendatensatz, der durch einen Chatbot, dann durch ein zweites System und schließlich zu einem menschlichen Mitarbeiter gelangt, passt nicht in dieses Modell. Es gibt selten ein einziges Protokoll, das alle Systeme dokumentiert, die die Daten durchlaufen haben – sodass ein Audit-Trail, wie ihn Aufsichtsbehörden verlangen, oft gar nicht existiert. Diese Lücke ist kein Trainings- oder Awareness-Problem, sondern das Ergebnis einer Architektur, die nie für KI-Verkehr entworfen wurde – und sie wächst mit jedem Quartal, in dem Datenklassifizierung und Zugriffskontrolle nur nachträglich auf Systeme aufgesetzt werden, die nie für KI-Mediation gebaut wurden.
Was Ungeregelter KI-Zugriff Tatsächlich Kostet
Die finanziellen Auswirkungen dieser Lücke sind längst belegt. Der IBM Cost of a Data Breach Report 2026 zeigt: Datenschutzverstöße mit Shadow AI verursachen durchschnittlich 5,39 Millionen US-Dollar Schaden – ein Anstieg gegenüber 4,63 Millionen im Vorjahr. 68 % der 602 untersuchten Unternehmen verfügen weiterhin über keine KI-Governance, um solche Vorfälle zu verhindern oder unautorisierte Nutzung zu erkennen. Die in Help Net Security zitierte Richtlinie verweist auf McKinsey-Zahlen: KI wird in 80 % der Unternehmen eingesetzt, aber die Governance-Reife liegt bei nur 10 %. Diese Diskrepanz wächst, da agentenbasierte Deployments über einfache Chatbots hinausgehen – hin zu Systemen mit persistentem Speicher, Tool-Ausführung und der Fähigkeit, im Namen von Nutzern zu agieren.
Der Kiteworks Data Security and Compliance Risk: 2026 Forecast Report quantifiziert die Lücke aus Sicht der Eindämmung: 100 % der befragten Unternehmen haben agentenbasierte KI auf ihrer Roadmap, aber 63 % können Zweckbindungen für bereits eingesetzte KI-Agenten nicht durchsetzen, 60 % können einen fehlverhaltenden Agenten nicht schnell beenden, und 55 % können ein KI-System im Notfall nicht vom Netzwerk isolieren. Der Bericht identifiziert eine Lücke von 15 bis 20 Prozentpunkten zwischen dem, was Unternehmen überwachen können, und dem, was sie tatsächlich stoppen können. Die meisten Unternehmen können also das Fehlverhalten eines Agenten nahezu in Echtzeit beobachten, haben aber keinen Hebel, es zu beenden. 54 % der Vorstände führen KI-Datengovernance nicht unter ihren Top-5-Themen – diese Unternehmen liegen bei allen gemessenen Fähigkeiten 26 bis 28 Punkte hinter jenen, deren Vorstände das Thema priorisieren.
Eine Architektur, die Zugriff auf der Datenebene Durchsetzt
Wenn man akzeptiert, dass das Modell selbst nie die Kontrolle sein kann, wird die Lösung zur Infrastrukturentscheidung – nicht zur Textaufgabe. Jede KI-Agentenabfrage, egal ob aus einem Chatbot, einem autonomen Agenten oder einer Retrieval-Augmented-Generation-Pipeline, muss vor der Datenabfrage eine Berechtigungsprüfung durchlaufen – nach denselben RBAC– oder ABAC-Regeln, die das Unternehmen bereits für menschliche Nutzer verwendet. „Default Deny“ muss auf der Tool-Ebene greifen – nicht als nachträgliche Schicht über einer Systemanweisung. Und entscheidend: Die Richtlinie muss für menschliche und KI-Identitäten dieselbe sein, mit einem einzigen Audit-Trail. Es gibt keinen separaten, lockereren Standard für die Identität, die schneller agiert – Governance gilt für beide gleichermaßen.
Das ist das Prinzip hinter Kiteworks Secure MCP Server und Kiteworks Compliant AI. Beide begrenzen, was ein KI-Agent oder großes Sprachmodell abrufen kann, auf die tatsächlichen ABAC-Berechtigungen des anfragenden Nutzers – durchgesetzt außerhalb des Modell-Kontextfensters, nicht innerhalb einer Systemanweisung. Die Kiteworks Data Policy Engine setzt diese Richtlinie konsistent um – für E-Mails, Filesharing, Managed File Transfer, Web-Formulare und jetzt auch KI-Zugriff. Sie läuft auf einer gehärteten virtuellen Appliance mit FIPS 140-3-validierter Verschlüsselung und einem Audit-Trail, der für Prüfer ohne technische Übersetzung verständlich ist.
Ein wichtiger Hinweis, der nicht überbetont werden sollte, weil genau das den Fehler wiederholen würde, den dieser Ansatz vermeiden will: Zugriffskontrollen auf dieser Ebene regeln, was eine Anfrage abrufen kann, sobald sie an die Berechtigungen eines verifizierten Nutzers gebunden ist. Sie erkennen jedoch nicht eigenständig ein Prompt-Injection-Payload, das in einem E-Mail-Anhang, einer gescrapten Webseite oder einem anderen nicht vertrauenswürdigen Inhalt versteckt ist, den der Agent verarbeiten soll. Das ist eine separate Verteidigungsschicht – und auch AWS betont diesen Punkt ausdrücklich. Es wird davor gewarnt, einem einzelnen Agenten gleichzeitig Zugriff auf sensible Daten, externe Kommunikationsmöglichkeiten und Kontakt zu unzuverlässigen Inhalten zu gewähren, da genau diese Kombination Prompt Injection zu einem Weg für Datenabfluss macht. Zugriffskontrolle auf Datenebene schließt die Lücke bei der Datenabfrage – ersetzt aber nicht die Notwendigkeit, auch die Handlungen des Agenten nach dem Abruf zu steuern.
Was Aufsichtsbehörden und Prüfer Tatsächlich Fordern
Das ist der entscheidende Rahmen für CISOs oder Chief Compliance Officers, die intern argumentieren: Aufsichtsbehörden regulieren Daten, nicht Modelle. HIPAA interessiert nicht, ob ein Mensch oder ein KI-Agent eine Patientenakte gelesen hat – entscheidend ist, ob der Zugriff autorisiert, minimiert und protokolliert wurde. Gleiches gilt für die DSGVO, die verlangt, dass die Verarbeitung personenbezogener Daten auf einer rechtmäßigen Grundlage erfolgt und auf Anfrage nachgewiesen werden kann, sowie für CMMC im Verteidigungsbereich, wo der Zugriff eines KI-Agenten auf kontrollierte, nicht klassifizierte Informationen genauso bewertet wird wie der eines menschlichen Nutzers.
Keine dieser Regelwerke wurde mit Blick auf KI-Agenten geschrieben – und keines muss angepasst werden. Sie verlangen Nachweise: einen benannten Datenverantwortlichen für jedes System mit Zugriff auf regulierte Informationen, einen Berechtigungsrahmen, der auf Anfrage vorgelegt werden kann, und einen Audit-Trail, der nicht nur den Zugriff dokumentiert, sondern auch, dass er zu einem bestimmten Zeitpunkt unter einer bestimmten Richtlinie autorisiert war. Ein Prüfer, der eine HIPAA Security Rule-Prüfung oder ein CMMC-Level-2-Audit vorbereitet, wird nicht nach dem Inhalt der Systemanweisung Ihres KI-Agenten fragen. Er wird nach dem Zugriffsprotokoll, dem Berechtigungsmodell dahinter und einem Nachweis verlangen, dass beides übereinstimmt.
Die Anforderungen variieren je nach Branche, aber der Nachweisgrundsatz bleibt gleich: Ein Healthcare-Compliance Officer muss für ein HIPAA-Audit belegen, dass ein KI-Agent beim Zusammenfassen von Patientendaten denselben Minimalprinzipien folgt wie ein menschlicher Mitarbeiter. Ein Compliance Lead eines Rüstungsunternehmens muss für ein C3PAO-Audit unter CMMC 2.0 Compliance nachweisen, dass ein KI-Agent für kontrollierte, nicht klassifizierte Informationen nie weitergehenden Zugriff hatte als erlaubt. Ein Financial Services-CISO muss für SEC- oder GLBA-Anforderungen denselben Nachweis für einen Agenten erbringen, der Kontobewegungen zusammenfasst. In allen Fällen akzeptiert der Prüfer einen Berechtigungsnachweis und ein Zugriffsprotokoll – nicht eine Beschreibung, wie höflich der Agent angewiesen wurde.
RAG-Pipelines Benötigen Die Gleiche Durchsetzung – Keine Ausnahme
Das gleiche Prinzip gilt, egal ob ein Agent ein Tool direkt aufruft oder Kontext über eine Retrieval-Augmented-Generation-Pipeline bezieht. Gerade bei RAG-Architekturen wird dieser Punkt oft falsch umgesetzt, weil der Retrieval-Schritt häufig als generischer Suchindex gebaut wird, der alles zurückliefert, was thematisch passt – und Berechtigungsprüfungen erst nachgelagert (wenn überhaupt) erfolgen. Eine Berechtigungsprüfung nach der Datenabfrage ist aber keine echte Prüfung mehr: Das Modell könnte die Ergebnisse bereits verwendet haben, um eine Antwort zu generieren, ein Protokoll zu schreiben oder eine Aktion auszuführen. Die Prüfung muss immer vor der Abfrage gegen den Index erfolgen, auf Basis der tatsächlichen Berechtigungen des anfragenden Nutzers – unabhängig davon, wie sicher das System ist, dass das Ergebnis „eigentlich“ angezeigt werden dürfte.
Die Lücke Zwischen KI-Einführung und Governance Schließen
Jedes Unternehmen, das agentenbasierte KI einsetzt, wird früher oder später an diese Grenze stoßen. Die Einführung hat die Governance längst überholt – und die Unternehmen, die diese Lücke zuerst schließen, müssen ihrem Vorstand nach einem Vorfall keinen Millionenbetrag als Shadow-AI-Prämie erklären. Einige konkrete Schritte entscheiden darüber, ob ein KI-Programm auditierbar ist oder nicht.
Beginnen Sie damit, alle KI-Agenten mit Zugriff auf sensible Daten – genehmigt und Shadow AI – zu inventarisieren und jedem einen benannten Datenverantwortlichen sowie einen definierten Berechtigungsrahmen zuzuweisen, statt nur eine Aufgabenbeschreibung. Verlegen Sie die Berechtigungsprüfung auf die Datenabfrage-Ebene und testen Sie sie gegen die gleichen RBAC- oder ABAC-Regeln wie für menschlichen Zugriff – bevor ein Datensatz das Kontextfenster eines Modells erreicht. Lassen Sie nie einen einzelnen Agenten gleichzeitig Zugriff auf sensible Daten, externe Kommunikation und Kontakt zu nicht vertrauenswürdigen Inhalten haben – teilen Sie diese Fähigkeiten auf mehrere, spezialisierte Agenten auf. Erstellen Sie Audit-Trails in Beweisqualität für jeden KI-vermittelten Datenzugriff – so, dass sie regulatorischen Anforderungen genügen, nicht nur einer internen Nachbetrachtung. Und benennen Sie eine verantwortliche Person – nicht einen Absatz Anweisungen – für die Autorisierung eines Agenten.
All das behandelt KI-Agenten nicht als Bedrohung, die blockiert werden muss. Sie werden wie jede neue Identitätsklasse im Unternehmen behandelt: Sie werden in das bestehende Governance-Modell für menschliche Nutzer integriert – und nicht allein auf gute Manieren verlassen.
Erfahren Sie mehr darüber, wie Sie KI-Agenten-Zugriffskontrolle auf der Datenebene statt über Systemanweisungen durchsetzen können – vereinbaren Sie jetzt eine individuelle Demo.
Häufig gestellte Fragen
Eine Systemanweisung ist eine Instruktion, die vom selben Modell verarbeitet wird wie alle anderen Texte im Kontextfenster – einschließlich Daten und Nutzeranfragen. Die im September 2026 veröffentlichte AWS- und SANS-Richtlinie stellt klar: Solche Instruktionen können umgangen, ignoriert oder überschrieben werden, weil das Modell keine zuverlässige Möglichkeit hat, eine autoritative Anweisung von einer manipulierten Anfrage zu unterscheiden. Praxistests wie die Agents of Chaos-Studie belegen das direkt: Ein Agent verweigerte eine direkte Anfrage nach sensiblen Daten, gab dieselben Daten aber ungeschwärzt preis, als die Anfrage umformuliert wurde. Effektive Kontrolle erfordert die Durchsetzung von Zugriffsberechtigungen auf der Datenabfrage-Ebene – unabhängig vom Inhalt der Systemanweisung.
RBAC vergibt Zugriffsrechte auf Basis der zugewiesenen Rolle eines Nutzers, etwa „Abrechnungsanalyst“ oder „Schadensregulierer“, und eignet sich gut, wenn Berechtigungen klar an die Funktion gekoppelt sind. ABAC bewertet eine breitere Palette von Attributen – etwa Datenklassifizierung, Abteilung, Standort und Zeitpunkt der Anfrage – und ist daher besser für kontextabhängige, granulare Zugriffsentscheidungen geeignet, wie sie KI-Agenten oft benötigen. Viele Unternehmen nutzen beide Modelle: RBAC als Basis, ABAC für feinere KI-Agenten-Abfragen. Beide können die gleiche Anforderung erfüllen – Berechtigungen werden geprüft, bevor Daten den Agenten erreichen, nicht danach.
Ja, und hier ist das Risiko aktuell am größten. Untersuchungen zu KI-Nutzungsmustern in Unternehmen zeigen: Rund 80 % der Mitarbeitenden nutzen KI-Tools, die von der IT nicht genehmigt wurden, und 70 % wissen, dass sensible Daten damit geteilt werden – unabhängig von der offiziellen Richtlinie. Shadow AI agiert komplett außerhalb von RBAC- und ABAC-Kontrollen, die für genehmigte Systeme gelten. Deshalb zeigt der IBM Cost of a Data Breach Report 2026: Datenschutzverstöße mit Shadow AI verursachen durchschnittlich 5,39 Millionen US-Dollar Schaden – ein Anstieg gegenüber 4,63 Millionen im Vorjahr. Die Schließung dieser Lücke beginnt mit der Entdeckung aller genutzten KI-Tools – nicht nur der offiziell genehmigten.
Kiteworks Compliant AI und der Kiteworks Secure MCP Server begrenzen, was ein KI-Agent oder großes Sprachmodell abrufen kann, auf die tatsächlichen ABAC-Berechtigungen des anfragenden Nutzers – bevor die Daten das Modell erreichen, statt auf eine Regel in der Systemanweisung zu vertrauen. Die Kiteworks Data Policy Engine setzt dies konsistent um – für E-Mails, Filesharing, Managed File Transfer, Web-Formulare und KI-Zugriff – und protokolliert die Ergebnisse in einem Audit-Trail, der regulatorische Anforderungen an Nachweise erfüllt.
Nicht vollständig – und es wäre ein Fehler, das zu glauben. Zugriffskontrolle auf Datenebene regelt, was eine Anfrage abrufen kann, sobald sie an die Berechtigungen eines verifizierten Nutzers gebunden ist; sie erkennt aber nicht eigenständig eine böswillige Instruktion in einer E-Mail, einem Dokument oder einer gescrapten Webseite. AWS empfiehlt eine separate Schutzmaßnahme: Niemals sollte ein einzelner Agent gleichzeitig Zugriff auf sensible Daten, externe Kommunikationsfähigkeit und Kontakt zu nicht vertrauenswürdigen Inhalten haben – denn genau diese Kombination macht Prompt Injection zum Weg für Datenabfluss. Zugriffskontrolle und Injection-Abwehr sind ergänzende Schichten, keine Ersatzlösungen.
Weitere Ressourcen
- Blogbeitrag
Zero‑Trust-Strategien für bezahlbaren KI-Datenschutz - Blogbeitrag
Wie 77 % der Unternehmen bei KI-Datensicherheit scheitern - eBook
KI-Governance-Lücke: Warum 91 % kleiner Unternehmen 2025 Russisches Roulette mit Datensicherheit spielen - Blogbeitrag
Für Ihre Daten gibt es kein „–dangerously-skip-permissions“ - Blogbeitrag
Regulierungsbehörden fragen nicht mehr nach einer KI-Richtlinie. Sie wollen den Nachweis, dass sie funktioniert.