KI-Agenten-Berechtigungen: So setzen regulierte Unternehmen Least-Privilege-Zugriff durch

Was Berechtigungen für KI-Agenten tatsächlich steuern

Agenten sollten nicht allein deshalb weitreichenden Zugriff erhalten, weil sie nützlich sind. Sobald ein Agent interne Systeme abfragen, Kundendaten lesen, Auszahlungen auslösen, externe Nachrichten versenden oder Workflows verändern kann, bilden Berechtigungen die Grenze zwischen Automatisierung und unvertretbarem Risiko.

In der Praxis verbinden Berechtigungen für KI-Agenten Identität, Geltungsbereich, Befugnisse, Kontext, Aufsicht und Nachweise. Dass ein Mitarbeiter ein Dashboard ansehen darf, bedeutet nicht automatisch, dass ein Agent dieselben Rechte erhalten sollte — und schon gar nicht dieselbe Möglichkeit, mit Maschinengeschwindigkeit zu handeln.

Diese Unterscheidung ist entscheidend, weil Unternehmen häufig drei Fähigkeiten vermischen: Daten sehen, über Daten schlussfolgern und Maßnahmen ausführen. Gute Berechtigungsmodelle trennen diese Ebenen, statt sie in einem übergroßen Credential zusammenzufassen.

• Identität: welcher Principal vom Agenten verwendet wird
• Scope: auf welche Systeme, Datensätze und Felder der Agent zugreifen darf
• Befugnis: welche Aktionen der Agent ausführen darf
• Kontext: wann, wo und unter welchen Bedingungen der Agent handeln darf
• Aufsicht: welche Schritte eine menschliche Aufsicht erfordern
• Nachweise: was für spätere Prüfungen erfasst werden muss

Warum klassisches IAM bei agentischen Workflows versagt

Klassisches Identity and Access Management geht von relativ stabilen Akteuren und vorhersagbaren Handlungsmustern aus. Menschen melden sich an, arbeiten in begrenzten Anwendungen und treffen Entscheidungen Schritt für Schritt. Agenten dagegen verketten Tool-Aufrufe, erzeugen Teilaufgaben, bewegen sich zwischen Systemen und komprimieren Stunden Arbeit auf Sekunden.

Dadurch entsteht ein Kontrollproblem, das sich nicht allein mit generischen Rollenbezeichnungen lösen lässt. Statische Rollen wie „Claims Analyst“ oder „Support Ops“ sind oft deutlich weiter gefasst als die exakten Berechtigungen, die ein einzelner Agentenlauf tatsächlich benötigt.

Genau deshalb geben viele Teams Agenten entweder zu viel Macht oder schränken sie so stark ein, dass die Automatisierung ihren Nutzen verliert. Beides sind Governance-Fehler und nicht bloß Sicherheitsfehler.

• Gemeinsam genutzte Service-Accounts zerstören Zurechenbarkeit: Ein API-Key, den mehrere Automatisierungen verwenden, kann später nicht belastbar belegen, wer was getan hat
• Rollenbasierter Zugriff ist zu grob: der implizite Zugriff eines Menschen ist meist weiter gefasst als das, was ein aufgabenbezogener Agent braucht
• Prompt-Anweisungen werden mit Kontrollen verwechselt: einem Modell „keine Zahlungen senden“ zu sagen, ist keine Durchsetzung
• Ausgabe-Logs verfehlen die Entscheidungsebene: ohne Policy-Ergebnisse, Tool-Traces und Freigabeereignisse gibt es keine auditfähigen Nachweise

Die drei Berechtigungsmodelle, die Unternehmen tatsächlich nutzen

Die meisten Unternehmen landen am Ende bei einem von drei Modellen. Entscheidend ist nicht, welches Modell modern klingt, sondern welches zum operativen Risiko des jeweiligen Workflows passt.

Reine Rechercheassistenten und kurzlebige Prototypen können Abkürzungen eher tolerieren. Operative Agenten in Schadenbearbeitung, KYC, Underwriting, Support, Einkauf oder Finance in der Regel nicht.

• Gemeinsam genutzter Service-Account: schnell eingerichtet, schwach bei Verantwortlichkeit und nur für kurzlebige Prototypen sowie risikoarme Read-only-Workflows vertretbar
• Delegierter Nutzerzugriff: sinnvoll, wenn der Agent eindeutig im Namen einer einzelnen Person handelt, etwa beim Formulieren von E-Mails oder Erstellen eines Briefings aus den Tools dieses Nutzers
• Dedizierte Agenten-Identität: das sauberste Produktionsmodell für wiederholbare operative Workflows, weil der Agent eigene Scopes, Allowlists, Freigabeschwellen und Logs erhält

Least Privilege bedeutet getrennte Kontrollgrenzen

Least Privilege bedeutet nicht, den Agenten schwach zu machen. Es bedeutet, ihm exakt so viel Befugnis zu geben, wie er für die freigegebene Aufgabe, den freigegebenen Zeitraum und den freigegebenen Kontext benötigt.

Ein praktischer Kontrollpfad sieht so aus: Identität -> Policy Gate -> Tools und Daten -> Freigabe -> Nachweis. Je expliziter diese Schritte modelliert sind, desto leichter lassen sie sich im Code durchsetzen und gemeinsam mit Compliance-Teams prüfen.

An diesem Punkt wird Policy-as-Code wertvoll. Wenn Berechtigungen explizit, versioniert und testbar sind, lassen sie sich wie jede andere Produktionskontrolle reviewen. Das ist deutlich belastbarer als ungeschriebene Konventionen, die in Prompts oder Middleware versteckt sind. Eine produktbezogene Sicht darauf bietet die Plattformübersicht.

• Tool-Scope: welche Tools der Agent überhaupt aufrufen darf
• Daten-Scope: auf welche Mandanten, Datensätze, Felder, Regionen oder Geschäftsbereiche der Agent zugreifen darf
• Aktions-Scope: ob der Agent lesen, zusammenfassen, empfehlen, entwerfen, aktualisieren, genehmigen oder ausführen darf
• Wert- und Risikoschwellen: welche Transaktionshöhe, welcher Risikoscore oder welche Kundenauswirkung automatisch behandelt werden darf
• Zeit- und Betriebskontext: ob die Berechtigung in Produktion, nur für eine einzelne Sitzung oder ausschließlich in einer bestimmten Umgebung gilt

Datenabruf ist keine Handlungsvollmacht

Ein häufiger Fehler ist die Annahme, breiter Retrieval-Zugriff sei harmlos, weil der Agent „nur liest“. In regulierten Umgebungen kann bereits Lesezugriff sensible personenbezogene Daten, Geschäftsgeheimnisse oder geschützte Akten offenlegen.

Ein ebenso schwerwiegender Fehler ist es, Lesezugriff als zulässigen Stellvertreter für Handlungsmacht zu behandeln. Sobald ein Agent abgerufenen Kontext mit nachgelagerten Tools kombiniert, werden Retrieval-Berechtigungen oft zum verdeckten Input für wirkmächtige Aktionen.

Sicherere Designs teilen den Workflow in getrennte Berechtigungspfade auf: einen für eng begrenzten Retrieval-Zugriff, einen für Empfehlungen oder Entwürfe und einen eigenständigen Pfad für irreversible Ausführung.

• Ein Berechtigungssatz nur für aufgabenrelevanten Retrieval-Zugriff
• Ein engerer Berechtigungssatz für Empfehlungen oder die Erstellung von Entwürfen
• Ein separater Kontrollpfad für irreversible Aktionen, oft mit Freigabe und stärkerer Protokollierung

Wo menschliche Freigaben hingehören

Menschliche Freigaben sollten nicht zufällig über den Workflow verteilt werden. Sie gehören an die Punkte, an denen sich Risiko konzentriert. Wenn jeder triviale Schritt geprüft werden muss, entsteht Latenz ohne wirklichen Aufsichtsgewinn.

Ein wirksames Freigabedesign ist gezielt, nachvollziehbar und an geschäftliche Auswirkungen gekoppelt. Genau das ist das Betriebsmodell hinter dem Konzept der verantwortungsvollen Autonomie — nicht die pauschale Regel, dass Menschen jedes Token ansehen müssen.

Teams, die das wiederholbar umsetzen wollen, brauchen in der Regel sowohl Policy-Regeln als auch Betriebsverfahren. Ein kompakter Ausgangspunkt ist das Playbook: Verfahren zur menschlichen Aufsicht.

• Freigaben für irreversible Aktionen wie Zahlungen, Ablehnungen, Kontoschließungen oder regulatorische Meldungen
• Freigaben für Entscheidungen, die Rechte, Anspruchsberechtigung, Preisgestaltung, Beschäftigung oder den Zugang zu wesentlichen Diensten betreffen
• Freigaben für externe Kommunikation mit rechtlichen, finanziellen oder reputativen Folgen
• Freigaben für Policy-Ausnahmen, Schwellenwertverletzungen, ungewöhnliche Konfidenzprofile oder fehlende Daten
• Freigaben für jede Änderung an den eigenen Berechtigungen, Tools oder steuernden Policies des Agenten

Warum Berechtigungen unter der KI-Verordnung der EU wichtig sind

Für Organisationen, die auf die KI-Verordnung der EU hinarbeiten, ist Berechtigungsdesign kein Nebenthema. Es greift direkt in die Pflichten ein, die relevant werden, sobald Systeme reale Menschen und regulierte Prozesse beeinflussen.

Artikel 14 ist die klarste operative Verbindung. Wenn Menschen ein System wirksam überwachen sollen, brauchen sie eine echte Möglichkeit zu verstehen, was der Agent tut, einzugreifen, ihn zu stoppen und Ausgaben bei Bedarf zu verwerfen.

Artikel 12 ist wichtig, weil Rückverfolgbarkeit von Laufzeit-Kontrollpunkten abhängt und nicht nur von Endergebnissen. Artikel 17 ist wichtig, weil Qualitätsmanagement erst dann real wird, wenn Berechtigungen, Freigaben und Nachweise operationalisiert sind. Wer diese Kontrollen dokumentieren muss, beginnt praktisch mit der Anhang-IV-Vorlage.

Das ist keine Rechtsberatung, sondern ein Umsetzungsaspekt: Wenn sich nicht zeigen lässt, wer was unter welcher Policy mit welcher Aufsicht tun durfte und was im Zeitverlauf tatsächlich passiert ist, ist die Kontrollgeschichte unvollständig.

Was auditfähige Nachweise erfassen müssen

Die meisten Teams protokollieren die einfachen Dinge: Prompt, Antwort, Latenz, vielleicht noch eine Trace-ID. Das ist operative Telemetrie. Für Untersuchungen, Audits oder Post-Market-Monitoring reicht das nicht aus.

Eine belastbare Prüfung erfordert, nachvollziehen zu können, warum der Agent handeln durfte, was er berührt hat und wer für diesen Schritt die Autorität hatte. Genau diese Lücke zwischen Logs und Nachweisen beschreibt Audit-Trails für KI-Agenten: Von Logs zu Beweismitteln.

In der Praxis ist das hilfreichste Nachweismodell synchron am Policy-Checkpoint erfasst und anschließend in ein Format exportiert, das Prüfer unabhängig verifizieren können — etwa als Evidence-Room-Beispiel.

• Sitzungs-, Fall- und Workflow-Identifikatoren
• Nutzer-, Agenten- und Systemidentitäten
• Modellversion sowie Prompt- oder Policy-Template-Version
• Referenzen auf abgerufene Datensätze und berührte Datenquellen
• Policy-Ergebnisse wie erlaubt, abgelehnt oder eskaliert
• Zeitstempel der Freigabe, Identität des Prüfers und Begründung
• Vorher-/Nachher-Zustände bei jeder wesentlichen Änderung
• Endergebnis, Benachrichtigungen, Rollback- oder Remediation-Ereignisse

Was MCP verändert und was nicht

Das Model Context Protocol (MCP) ist nützlich, weil es standardisiert, wie KI-Anwendungen mit Tools und Datenquellen verbunden werden. Das ist ein realer Fortschritt. Es fördert explizit freigegebene Tool-Schnittstellen statt versteckter Integrationspfade.

Aber MCP löst das Berechtigungsmodell nicht für Sie. Ein sauberes Protokoll mit schlechten Berechtigungen bleibt ein schlechtes Berechtigungsmodell.

Weiterhin erforderlich sind explizites Identitätsdesign, eng gefasste Credentials, Allowlists, Freigabeschwellen und Nachweiserfassung. Die Protokollstandardisierung verbessert die technische Verbindungslogik. Die Governance muss die eigentlichen Unternehmensfragen dennoch beantworten.

• Welche Identität sollte der Agent verwenden?
• Was sollte nutzerdelegiert und was agenteneigen sein?
• Welche Aktionen brauchen eine Freigabe?
• Wie sollte sich Zugriff nach Kunde, Region oder Umgebung unterscheiden?
• Welche Nachweise müssen für Audit und Incident Response gespeichert werden?

Häufige Fehler, die vermieden werden sollten

Berechtigungsfehler sind selten exotisch. Meist sind sie das Ergebnis vorhersehbarer Abkürzungen, die im Prototyping harmlos wirken und in der Produktion teuer werden.

• Dem Agenten ein menschliches Admin-Konto zu geben
• Denselben Scope für Retrieval und Ausführung zu verwenden
• Sich auf Prompts statt auf durchsetzbare Kontrollen zu verlassen
• Ausgaben zu loggen, aber nicht die Policy-Entscheidungen
• Freigaben binär statt risikobasiert zu gestalten