Euer KI-Agent hat eine Governance-Lücke — und euer IAM wird sie nicht schließen
Warum Authentifizierung und Autorisierung nicht ausreichen, wenn KI-Agenten auf Unternehmensdaten zugreifen.
Euer KI-Agent hat Zugriff auf das Ticketsystem, das Wiki, das CRM und vermutlich auch auf die HR-Plattform. Er kommuniziert über einen Team-Chat — öffentliche Channels, private Channels, Direktnachrichten. Unterschiedliche Zielgruppen, unterschiedliche Vertraulichkeitserwartungen.
Jetzt fragt jemand im öffentlichen Channel: „Wie läuft's beim Projekt?"
Der Agent liefert eine hilfreiche, umfassende Zusammenfassung. Umsatzzahlen aus dem Finance-System. Eine Personalveränderung aus der HR-Abteilung. Eine kritische Sicherheitslücke aus dem Engineering-Backlog. Nicht weil er gehackt wurde. Nicht wegen einer Prompt Injection. Sondern weil er hilfreich sein wollte — und hilfreich bedeutet für ein LLM: relevant.
Das ist kein Modell-Problem. Das ist ein Architektur-Problem. Und es hat einen Namen.
Das Drei-Schichten-Problem
Enterprise Security für KI-Agenten deckt typischerweise zwei Schichten ab:
Authentifizierung beantwortet „Wer ist der Agent?" — gelöst durch OAuth2, Service Accounts, API-Keys. Autorisierung beantwortet „Worauf darf der Agent zugreifen?" — gelöst durch IAM, RBAC, ABAC, was auch immer die Organisation einsetzt.
Aber es gibt eine dritte Schicht, die fast niemand baut: Dissemination Control — „Was darf der Agent weitergeben, an wen, in welchem Kontext?"
Ein menschlicher Mitarbeiter mit Lesezugriff auf HR-Daten und Projektdaten postet keine Gehaltsinformationen im öffentlichen Team-Channel. Nicht weil das IAM ihn daran hindert — er hat den Zugriff. Sondern weil er versteht, dass ein öffentlicher Channel nicht der richtige Ort für vertrauliche HR-Daten ist. Er versteht den sozialen Kontext.
KI-Agenten verstehen keinen sozialen Kontext. Sie optimieren nach Relevanz. Und die relevanteste Antwort auf eine harmlose Frage ist oft genau die mit den sensiblen Informationen.
Warum es schlimmer wird, nicht besser
Drei Entwicklungen treffen gerade aufeinander.
MCP (Model Context Protocol) wird zum Standard für Tool-Integration. Agenten sind nicht mehr auf Textgenerierung beschränkt. Sie rufen APIs auf, fragen Datenbanken ab, erstellen Tickets, aktualisieren Dokumente. Die Zahl der Systeme, die ein Agent erreichen kann, wächst mit jedem neuen MCP-Server, der veröffentlicht wird.
Agenten werden in Multi-User-, Multi-Channel-Umgebungen eingesetzt. Der gleiche Agent bedient den öffentlichen Firmen-Channel, den Engineering-Team-Channel und private Direktnachrichten. Jeder davon hat eine andere Zielgruppe und andere Vertraulichkeitserwartungen. Der Agent unterscheidet nicht.
Fertige MCP-Server verwenden einen einzelnen API-Token mit Vollzugriff. Keine nutzerbezogenen Berechtigungen. Kein Kanal-Bewusstsein. Keine Dissemination Policy. Jede Abfrage läuft mit denselben God-Mode-Credentials. Das ist in Ordnung für einen einzelnen Entwickler, der einen Agenten lokal nutzt. Es ist nicht in Ordnung, wenn dieser Agent eine ganze Organisation bedient.
Die Guardrail-Anbieter — Lakera, Prompt Armor und andere — adressieren ein anderes Problem. Sie schützen das Modell: Input-Validierung, Prompt-Injection-Erkennung, Output-Toxizitätsfilterung. Wichtige Arbeit, aber sie beantwortet nicht die Infrastruktur-Frage: Wie fügt sich der Agent in die bestehende Identitäts-, Berechtigungs- und Compliance-Landschaft ein?
Was Dissemination Control bedeutet
Dissemination Control ist die Governance-Schicht, die bestimmt, welche Informationen ein KI-Agent preisgeben darf, an wen und über welchen Kanal — unabhängig davon, ob der Agent technisch auf die Daten zugreifen kann.
Es ist kein Produkt. Es ist ein Architekturmuster. Und es baut auf Infrastruktur auf, die die meisten Unternehmen bereits haben: Identity Provider, Policy Engines, Berechtigungsmodelle in den Zielsystemen.
Die Architektur, die ich gebaut und getestet habe, definiert fünf Governance-Schichten und vier Ausbaustufen. Der vollständige Blueprint ist als offenes Referenzdokument veröffentlicht. Hier möchte ich mich auf die zentrale Erkenntnis konzentrieren, die das Ganze praxistauglich macht:
Man muss nicht alles auf einmal lösen.
Vier Stufen, jede fügt eine Fähigkeit hinzu
Der häufigste Einwand, den ich höre: „Das klingt nach einem Riesenprojekt." Muss es nicht sein. Die Architektur ist für inkrementelle Einführung ausgelegt. Jede Stufe fügt genau eine Governance-Fähigkeit zur vorherigen hinzu.
Stufe 1: Tool Containment. Der Agent kann nur Tools sehen, die für den aktuellen Kanal explizit freigeschaltet sind. Wenn das HR-System nicht auf der Whitelist für den Engineering-Channel steht, weiß der Agent nicht, dass es existiert. Keine Anfrage bedeutet kein Leak, keine Fehlermeldung, kein Seitenkanal, der verrät, dass das System vorhanden ist.
Das ist die einzelne wirksamste Maßnahme gegen Informationsabfluss. Und sie erfordert keine IAM-Änderungen, keine Identity-Provider-Integration, keinen Token Exchange. Nur Policy-Konfiguration. Eine Policy Engine wie OPA evaluiert „welche Tools sind für diesen Kanal erlaubt" und der Orchestration Service entfernt alles andere aus dem LLM-Request. Implementierbar in Tagen. Nicht Wochen. Nicht Monaten.
Stufe 2: Identity Delegation. Der Agent handelt mit den Berechtigungen des anfragenden Nutzers, nicht mit einem Service Account. Wenn Anna nach der Vertriebspipeline fragt, liefert das Ticketsystem Annas Daten. Wenn Paul die gleiche Frage stellt, liefert das Ticketsystem Pauls Daten — oder nichts, wenn Paul keinen Zugriff hat. Gleicher Channel, gleiche Frage, anderer Nutzer, andere Antwort.
Das erfordert einen Identity Provider mit Token-Exchange-Support (Keycloak, Entra ID, Okta unterstützen das) und einen Custom MCP-Server, der die Delegation durchführt. Mehr Engineering als Stufe 1, aber es baut auf bestehender IAM-Infrastruktur auf — kein neues Berechtigungsmodell nötig.
Stufe 3: Dissemination Policy. Selbst wenn ein Nutzer Zugriff auf Daten hat und das Tool freigeschaltet ist, prüft die Policy Engine, ob die Klassifizierung der Daten zum Kontext des Kanals passt. Vertrauliche Daten bleiben aus öffentlichen Channels draußen, auch wenn der anfragende Nutzer berechtigt wäre, sie zu sehen. Gleicher Nutzer, gleiche Berechtigungen, anderer Kanal, andere Antwort.
Stufe 4: Compliance Monitoring. Asynchrones Audit und semantische Output-Analyse für Hochsicherheitsumgebungen. Jeder Tool-Call, jede Policy-Entscheidung, jede Ablehnung wird protokolliert. Optional: Ein separates LLM prüft Agenten-Antworten auf Policy-Verstöße, die regelbasierte Schichten nicht erkennen können.
Die zentrale Botschaft für Entscheider: Stufe 1 lässt sich diese Woche implementieren. Sie eliminiert die gefährlichste Klasse von Informationsabfluss — den domänenübergreifenden Leak — ohne die IAM-Infrastruktur anzufassen. Stufen 2 bis 4 fügen schrittweise feinere Kontrolle hinzu, wenn die Anforderungen es erfordern.
Default Deny, nicht Default Permit
Ein Designprinzip verdient besondere Hervorhebung, weil es der häufigste Fehler ist, den ich bei Enterprise-KI-Deployments sehe.
Die meisten Organisationen nähern sich der Agent-Sicherheit mit einer Blacklist-Denkweise: Der Agent kann alles, und wir sperren einzelne Dinge, die gefährlich sind. Das scheitert aus demselben Grund, aus dem Blacklists immer scheitern — man muss jede gefährliche Kombination aufzählen, und man darf keine vergessen. Wenn ein neues System angebunden wird, ist es automatisch zugänglich, bis jemand daran denkt, es zu sperren.
Dissemination Control nutzt das Gegenteil: Default Deny. Kein Tool, kein System, keine Datenquelle ist verfügbar, bis sie explizit für einen bestimmten Kontext freigeschaltet wurde. Ein neues System, das an den Agenten angebunden wird, ist automatisch in jedem Kanal unsichtbar, bis jemand es bewusst für die Kanäle freischaltet, die es brauchen.
Das bedeutet: Der Fehlermodus ist sicher. Eine Fehlkonfiguration führt dazu, dass der Agent weniger Zugriff hat als beabsichtigt, nicht mehr. In der Sicherheitsarchitektur ist das kein Nice-to-have. Es ist der einzig vertretbare Ansatz.
Das Enforcement-Problem
Eine naheliegende Frage an dieser Stelle: „Warum sagt man dem Agenten nicht einfach im System-Prompt, welche Daten er wo teilen darf?"
Weil Prompts Vorschläge sind, keine Durchsetzung. Ein LLM, das angewiesen wird „teile keine HR-Daten in öffentlichen Channels", wird sich meistens daran halten — bis eine geschickt formulierte Frage, ein langes Gespräch, das die Anweisung verwässert, oder eine Prompt Injection sie überschreibt. Prompt-basierte Einschränkungen sind eine Verhaltensschicht, keine Sicherheitsgrenze.
In der Architektur, die ich gebaut habe, findet die Durchsetzung auf Infrastrukturebene statt. Tools werden aus dem LLM-Request entfernt, bevor er gesendet wird — der Agent kann nicht aufrufen, was er nicht sehen kann. Der Token Exchange findet im MCP-Server statt — der Agent fragt mit den Berechtigungen des Nutzers, nicht mit seinen eigenen. Die Policy-Evaluierung findet deterministisch in einer Policy Engine statt — kein LLM im Zugriffskontrollpfad.
Die Prompt-Schicht existiert weiterhin — sie steuert, wie sich der Agent innerhalb seines erlaubten Scopes verhält (Tonalität, Ausführlichkeit, Detailtiefe pro Kanal). Aber sie ist nicht die Sicherheitsgrenze. Sie ist die Höflichkeitsschicht auf der Enforcement-Schicht.
Slug-Level Enforcement
Ein technisches Detail, das wichtiger ist als es scheint: wie Tool-Identifikatoren an Zielsysteme gebunden werden.
Wenn der Tool-Identifikator ein String-Parameter ist, den das LLM übergibt („call system: hr-system"), dann kann ein Angreifer, der die Ausgabe des Agenten manipuliert, den Aufruf umleiten. Prompt Injection könnte „hr-system" in „finance-system" ändern.
In dieser Architektur sind Tool-Identifikatoren in MCP-Server-URL-Pfade eingebettet — das Zielsystem wird durch die URL-Route bestimmt, nicht durch einen Parameter, den das LLM kontrolliert. Ein Angreifer, der die Ausgabe des LLM manipuliert, kann Query-Parameter ändern, aber nicht, an welchen Endpunkt der Request geroutet wird. Eine kleine Architekturentscheidung mit erheblichen Sicherheitsimplikationen.
Was das nicht löst
Keine Architektur eliminiert alle Risiken. Zwei Einschränkungen verdienen explizite Benennung.
Das Mosaik-Problem. Einzelne nicht-sensible Informationen können in Kombination vertrauliche Schlussfolgerungen ergeben. Der Agent hat vielleicht keinen Zugriff auf HR-Daten, aber wenn er Projektzeitpläne, Teamänderungen und Budgetanpassungen kennt, könnte ein geschickter Fragesteller daraus ableiten, dass ein Stellenabbau bevorsteht. Task-scoped Access begrenzt die verfügbaren Daten für solche Inferenzen, eliminiert die Möglichkeit aber nicht.
Prompt-basierte Umgehung auf der Verhaltensschicht. Tool Containment und Identity Delegation werden auf Infrastrukturebene durchgesetzt und können nicht durch Prompts umgangen werden. Aber die Verhaltenssteuerung (wie der Agent Antworten innerhalb seines erlaubten Scopes formuliert) basiert auf Prompt-Befolgung, und die ist probabilistisch. Ein entschlossener Angreifer mit Zugang zum Kanal könnte potenziell mehr Information extrahieren, als die Prompt Policy vorsieht. Deshalb ist die Verhaltenssteuerung eine Governance-Schicht, keine Sicherheitsgrenze.
Beides sind dokumentierte Restrisiken. Die Architektur bietet den gleichen Schutz wie ein kompetenter Mitarbeiter, der die richtigen Akten für die richtige Aufgabe bekommt. Für die meisten Unternehmenskontexte ist das eine verteidigbare Risikohaltung.
Der Blueprint
Die vollständige Architektur — fünf Governance-Schichten, vier Ausbaustufen, Komponentenarchitektur, Request-Flows, Defense-in-Depth-Analyse, Designentscheidungen und eine Referenzimplementierung — ist als offenes Dokument unter CC BY-SA 4.0 veröffentlicht:
→ Dissemination Control for AI Agents — Architecture Blueprint
Er ist herstellerneutral. Die Referenzimplementierung nutzt Mattermost, Keycloak, OPA und Spring Boot, aber jede Komponentenrolle kann durch äquivalente Produkte ausgefüllt werden — Slack, Teams, Entra ID, Okta, Jira, Confluence, was auch immer die Organisation bereits betreibt.
Wenn Sie KI-Agenten mit Tool-Zugriff in Multi-User-Umgebungen einsetzen, ist das die Lücke zwischen Ihrem IAM und Ihrem Agenten, die sich nicht von selbst schließen wird.
Andre Jahn ist Solution Architect mit Spezialisierung auf AI Agent Governance. Er arbeitet mit Unternehmen daran, dass ihre KI-Agenten innerhalb bestehender Governance-Strukturen operieren — nicht um sie herum. Mehr unter jahnconsulting.io.