Das Problem, über das kaum jemand bei Enterprise-KI-Agenten spricht
Ihr CFO fragt einen KI-Agenten: “Wie viel haben wir im letzten Quartal für Gehälter ausgegeben?”
Der Agent ruft eure Payroll-API auf. Die API liefert Gehalt, Bonus und Personennummer für jeden Mitarbeitenden. Der Agent fasst das zu einer sauberen Summe zusammen.
Bis hierhin in Ordnung — der CFO darf diese Daten sehen.
Jetzt stellt ein Praktikant demselben Agenten dieselbe Frage. Der Agent ruft dieselbe API auf. Die API liefert dieselbe Nutzlast. Der Agent antwortet.
Das ist der stille Fehlmodus fast jeder produktiven „Enterprise-KI-Agent“-Einführung heute.
Warum RBAC auf Endpoint-Ebene nicht reicht
Die meisten Integrationsplattformen — einschließlich unserer, bis vor kurzem — sichern API-Zugriff auf Endpoint-Ebene. Entweder darfst du GET /payroll/employees aufrufen oder nicht. Das funktionierte, solange Menschen UIs bauten, die clientseitig filterten, und die einzigen Aufrufer vertrauenswürdige Backend-Dienste waren.
Agenten brechen dieses Modell auf zwei Arten:
- Agenten sind generische Aufrufer. Sie wissen nicht, welche Felder verborgen werden müssen. Sie fassen zusammen, was sie erhalten.
- Agenten handeln für viele verschiedene Nutzer. Ein Agentenprofil kann CEO und Lagerarbeiter bedienen. Endpoint-RBAC kann sie nach erfolgreicher Autorisierung nicht unterscheiden.
Das Ergebnis: Agenten werden zum Confused-Deputy-Problem in industrieller Skala. Ein Nutzer ohne direkten Datenbankzugriff kann alle Daten extrahieren, die der Agent erreicht — mit der richtigen Frage.
Wo Quellsystem-RBAC an Grenzen stößt
Die Standardantwort lautet: „Das Quellsystem regelt das.“ Identität des Nutzers an Payroll übergeben. Payroll filtert.
Das funktioniert — wenn das Quellsystem es unterstützt. In der Praxis:
- Legacy-Systeme haben oft nur ein Servicekonto mit Vollzugriff. Keine Delegation pro Nutzer.
- SaaS-APIs Dritter haben häufig keine Zeilenberechtigungen. Entweder Admin-Scope oder keiner.
- Eigene interne APIs entstanden vor KI-Agenten. Niemand hat
filter_by_userergänzt. - Aggregationen lecken. Selbst wenn Zeilenfilter existieren, werden Summen und Mittelwerte oft über den vollen Datensatz berechnet.
Für einen CISO bedeutet das: Eure Datenexpositionsfläche wird durch den schwächsten Konnektor im Werkzeugkasten des Agenten definiert.
Defense in Depth: policygesteuerte Antwortfilterung
Wir haben der Copyl Integration Platform eine neue Schicht hinzugefügt: DataAccessPolicy. Sie sitzt zwischen der Antwort des Quellsystems und dem Agenten und wendet deklarative Regeln auf die Rückgabe an.
Das Modell hat drei Kernideen:
1. Policies hängen an Integrationsaktionen, nicht an Agenten.
Ein Payroll-Endpoint hat eine Policy. Jeder Agent — jeder Nutzer — durchläuft denselben Evaluator. Ein falsch konfigurierter Agent kann die Regel nicht umgehen.
2. Regeln matchen den Subjektkontext, nicht den Endpoint.
Der Evaluator sieht das volle Subjekt: Nutzeridentität, Rollen, Claims, Agentenprofil, Enterprise. Eine Regel kann lauten: „Wenn Rolle CEO enthält, alle Zeilen erlauben“ oder „Wenn Nutzer Employee, nur Zeilen mit passender employeeId.“
3. Pushdown wenn möglich, Post-Filter als Fallback.
Unterstützt die Quell-API Filterung, schreibt die Policy den Request um — ?employeeId=42 — sodass sensible Daten das Quellsystem nicht verlassen. Ohne Pushdown wird serverseitig gefiltert, bevor der Agent sieht.
Das ist relevant für Compliance. Filtern zur Abfragezeit ist echter sicherer als nachträgliches Filtern. Post-Filter ist Defense in Depth, kein Ersatz für Quellsystem-Kontrollen.
Was das für Sec/Compliance bedeutet
Drei Eigenschaften machen es beherrschbar:
Auditierbar. Jede Auswertung schreibt einen Audit-Datensatz: welche Policy lief, welche Regel griff, wie viele Zeilen rein/raus, wie viele Felder maskiert. Die Frage „Wer hat am Dienstag Payroll-Daten gesehen und was wurde gefiltert?“ ist per SQL beantwortbar.
Versioniert. Policies durchlaufen Entwurf → veröffentlicht → archiviert. Jede Änderung ist eine neue Version. Diff, Wiederherstellung und Nachweis zum Stichtag sind möglich.
Vor Veröffentlichung testbar. Dry-Run: Filter wird ausgewertet und protokolliert, die Antwort bleibt unverändert. Ihr könnt gegen echten Traffic zwei Wochen validieren. Veröffentlichung erfordert bestandenen Test oder explizites Override.
Für regulierte Branchen (Finanzdienstleister, Gesundheitswesen, öffentlicher Sektor unter NIS2/DORA in Europa) wird aus „dem Agenten vertrauen“ „den Agenten belegen“.
Was es nicht löst
Ehrliche Grenzen:
- Delegation im Quellsystem bleibt besser, wenn verfügbar. Zuerst nutzen. Policy-Filter ist für den Rest.
- Aggregationen sind heikel. Ein Zeilenfilter plus Feld
total: 4.200.000über alle Mitarbeitenden leckt. Unser Modell erkennt Aggregatfelder und bricht ab, entfernt sie oder verlangt explizites Opt-in — endpointweise Denkarbeit bleibt nötig. - Feldmaskierung ist keine Verschlüsselung. Gehashte Personennummern bleiben PII. Maskierung reduziert Schaden, ersetzt Pflichten nicht.
- Policies sind nur so gut wie ihre Regeln. Falsches Subjekt-Matching über- oder untergewährt. Daher Testläufe und Audit-Sichtbarkeit.
Praxisbedeutung
Betreibt ihr Agenten gegen Systeme ohne Zeilen-RBAC — die meisten Legacy-ERPs, Payroll, eigene APIs vor 2024 — habt ihr eine Lücke, die Endpoint-Kontrolle nicht schließt.
Die Lösung ist strukturell, kein Prompt-Trick. „Nur eigene Daten zeigen“ nur im Prompt hält bis zum nächsten Jailbreak. Durchsetzung in der Integrationsschicht mit versionierter, auditierbarer Policy ist etwas, was ein CISO abzeichnen kann.
Wir rollen DataAccessPolicy in Copyls Marketplace-Agenten aus, beginnend mit Payroll, HR und Finance. Wenn ihr in regulierten Umgebungen arbeiten und eure Expositionspunkte durchsprechen wollt, meldet euch.
Copyl ist eine Plattform zum Bauen, Betreiben und Steuern von Enterprise-KI-Agenten. Unsere Integration Platform (CIP) verbindet Agenten mit Fachsystemen — durchgängige Policy-Durchsetzung, Audit-Logging und Versionskontrolle.