Zugriffskontrolle für KI-Agenten gibt einem benannten Agenten die geringste aktuell nötige Autorität für einen genehmigten Zweck, bewertet jede vorgeschlagene Aktion gegen diese Autorität, leitet folgenreiche Ausnahmen an eine befugte Person weiter und zeichnet das Ergebnis auf. Ein vollständiger Entwurf reicht von der Anlage der Identität bis zum Notfallwiderruf. Er löst effektive Berechtigungen zur Laufzeit auf, weil sich Rollen, Zuweisungen, Datensensibilität, Transaktionsbeträge und Policies zwischen Anmeldung und Ausführung ändern können.
Dieser Beitrag behandelt Entwurf und Betrieb des Kontrollsystems. Der Leitfaden KI-Agenten-Berechtigungen behandelt die periodische Prüfung und Rezertifizierung von Zugriffsrechten. Der Leitfaden Audit-Trails für KI-Agenten vertieft die Nachweisebene. Die Hinweise sind herstellerneutral und wurden am 28. Juli 2026 anhand von Primärquellen geprüft.
Ein Lebenszyklus von der Identität bis zum Widerruf
Weisen Sie jedem Agenten einen dauerhaften Eigentümer, einen Zweck, eine Risikoklasse, eine Umgebung und einen Identitätsdatensatz zu, bevor Sie Zugriff gewähren. Binden Sie diese fachliche Identität an eine attestierte Workload oder einen attestierten Client. Vergeben Sie eng gefasste Berechtigungen mit Ablauf- und Prüfdatum. Bewerten Sie sie bei jeder Aktion. Zeichnen Sie Freigabe und Ausführung unter denselben Korrelations-IDs auf. Entziehen Sie die Autorität, sobald sich Zweck, Eigentümer, Zuweisung, Risiko oder Umgebung ändern.
Textalternative. Der Lebenszyklus beginnt mit Registrierung und Identitätsbindung, führt über Rechtevergabe, Bewertung zur Laufzeit, menschliche Freigabe, Ausführung, Nachweis und periodische Prüfung und endet mit Widerruf, Abgleich und Wiederherstellung. Eine Änderung von Zweck, Eigentümerschaft, Risiko oder Umgebung führt den Agenten vor jeder weiteren Ausführung zurück in die Prüfung.
Scroll horizontally to inspect the diagram.
Behandeln Sie Zugriff als gesteuerten Lebenszyklus mit Eigentümer, Ablauf, Prüfung und getestetem Widerrufspfad.
Open full-size diagram| Stufe | Entscheidung | Verantwortung | Nachweis |
|---|---|---|---|
| Registrieren | Zweck des Agenten, Risiko, Sponsor, Mandant, Umgebung | Fachlicher Eigentümer | Registereintrag und Freigabe |
| Identität binden | Agent, Workload, Dienst und delegiertes Subjekt | IAM- und Plattformverantwortung | Aussteller, Subjekt, Akteur, Audience, Attestierung |
| Rechte vergeben | Effektive Grenzen für Tool, Ressource, Daten, Aktion und Kontext | Ressourcen- und Policy-Verantwortung | Rechtevergabe, Policy, Ablauf, Ausnahme |
| Bewerten | Aktuelle Anfrage gegen aktuelle Autorität | Autorisierungs- und Policy-Verantwortung | Eingaben, Ergebnis, Begründungscodes, Versionen |
| Freigeben | Eine befugte Person gibt genau die zurückgehaltene Anfrage frei | Verantwortung für Freigabebefugnisse | Momentaufnahme der Rolle, Begründung, Digest, Ablauf |
| Ausführen | Die gebundene Anfrage erzeugt genau einen Effekt | Tool- und Prozessverantwortung | Beleg, Zustand vor und nach, nachgelagerter Effekt |
| Prüfen | Der Zugriff bleibt erforderlich und verhältnismäßig | Eigentümer und unabhängiger Prüfer | Grundgesamtheit, Ausnahmen, Zertifizierungsgrenze |
| Widerrufen | Autorität stoppen und verbleibende Zugriffe abgleichen | Incident-, IAM- und Toolverantwortung | Kommandos, Ablehnungen, Restsitzungen, Wiederherstellung |
Das Identitätsmuster vor der Rechtevergabe festlegen
Nutzen Sie eine dedizierte Agenten-Identität für wiederkehrende unternehmensweite Autorität. Ergänzen Sie ein delegiertes menschliches Subjekt, wenn dessen aktuelle Zuweisung die Aktion begrenzt. Binden Sie den Agenten an eine Workload-Identität, damit die laufende Softwareinstanz zurechenbar bleibt. Reservieren Sie gemeinsam genutzte Service-Accounts für Altsysteme hinter einem verpflichtenden Gateway, das Agent und Anfrage vor jedem Aufruf auflöst.
| Muster | Einsatz wenn | Erforderliche Kontrolle | Hauptrisiko |
|---|---|---|---|
| Dedizierter Agent | Die Organisation trägt wiederkehrende operative Autorität | Benannter Eigentümer, enge Rechtevergabe, Workload-Bindung, Lebenszyklus | Dauerhafte oder verwaiste Zugriffe |
| Delegierter Nutzer | Eine Person bleibt Inhaber der Autorität | Akteur-Subjekt-Bindung, reduzierter Scope, Zweck, Ablauf | Implizite Nutzerprivilegien |
| Hybrid | Handelnder Agent und menschliches Subjekt beeinflussen beide die Entscheidung | Token Exchange oder gleichwertige Doppelidentität, Audience, Nachweis | Verwechslung von Akteur und Subjekt |
| Vermittelter Service-Account | Ein Altsystem akzeptiert nur ein technisches Credential | Verpflichtendes Gateway, Policy je Aufruf, Umgehungserkennung, Beleg | Geteiltes Credential und schwache Zurechenbarkeit |
RBAC, ABAC und Capabilities bewusst kombinieren
Rollenbasierte Zugriffskontrolle (RBAC) liefert verständliche Grundpflichten. Attributbasierte Zugriffskontrolle (ABAC) verengt eine Anfrage anhand von Subjekt-, Ressourcen-, Aktions- und Umgebungsattributen. Eine Capability gewährt einem bestimmten Inhaber eine enge, regelgebunden übertragbare Autorität auf eine Ressource oder Aktion. Die meisten produktiven Agentensysteme nutzen Rollen für die Grundzuweisung, Attribute für den aktuellen Kontext und kurzlebige Capabilities oder Token für den finalen Aufruf.
| Modell | Bester Einsatz | Beispiel | Kontrollanforderung |
|---|---|---|---|
| RBAC | Stabile Rollen- oder Dienstgrundlagen | claims_reader liest zugewiesene Schadenzusammenfassungen | Kleine Rollen, Funktionstrennung, periodische Prüfung |
| ABAC | Kontextabhängige Entscheidungen | Mandant, Zuweisung, Sensibilität, Zweck, Betrag, Ort und Zeit stimmen alle überein | Vertrauenswürdige Attribute, Aktualität, Begründungscodes |
| Capability | Enge Aufrufautorität | Eine kurzlebige Vergabe für claim:1842 und settlement.propose | Audience, Ablauf, Abschwächung, Replay-Schutz, Widerruf |
| Kombination | Folgenreiche Produktionsaktionen | Die Rolle begründet die Zulässigkeit, Attribute begrenzen den Kontext, die Capability bindet den Aufruf | Eine Vorrangregel und ein Nachweisdatensatz |
Alle sieben Least-Privilege-Grenzen verantworten
Eine Tool-Allowlist ist nur eine Grenze. Die Policy muss außerdem Datensätze, Felder, Operation, Betrag, fachlichen Zweck, Deployment und Zeitraum begrenzen. Weisen Sie jeder Grenze eine führende Quelle, einen Durchsetzungspunkt, eine Prüfverantwortung und ein Nachweisfeld zu.
| Grenze | Policy-Frage | Beispielkontrolle | Nachweis |
|---|---|---|---|
| Tool | Welcher Konnektor, welche API oder welcher MCP-Server darf einen Aufruf erhalten? | Tool-Identität und Ziel auf der Allowlist | Tool-ID, Endpunkt, Serverversion |
| Daten | Welcher Mandant, welcher Datensatz, welches Feld, welche Region, welche Sensibilität? | Zugewiesener Fall und freigegebene Felder | Ressourcen-IDs, Feldmenge, Klassifizierung |
| Aktion | Welche Operation: lesen, entwerfen, vorschlagen, freigeben oder ausführen? | Getrennte Berechtigungen für Vorschlag und Ausführung | Operation und Parameter |
| Betrag | Welche Wert- oder Risikoschwelle gilt? | Freigabe ab 25.000 EUR, Obergrenze 100.000 EUR | Währung, Betrag, Schwellenwerte |
| Zweck | Welche erklärte fachliche Nutzung rechtfertigt den Zugriff? | Zweck entspricht claim_settlement | Zweck, Rechts- oder Policy-Grundlage, Fall |
| Umgebung | Welcher Mandant, welches Konto, welche Region, welches Netz, welches Deployment? | Produktionsidentität wird nur in der Produktion akzeptiert | Mandant, Umgebung, Workload |
| Zeitraum | Wann und wie lange? | Token mit 15 Minuten Gültigkeit innerhalb der aktiven Zuweisung | Ausgestellt, wirksam, Ablauf, Entscheidungszeitpunkt |
Eines von vier Policy-Ergebnissen zurückgeben
Legen Sie Vorrang und Fehlerverhalten vor dem Rollout fest. Eine Blockbedingung setzt sich durch. Eine fehlende Pflichteingabe oder eine nicht verfügbare zwingende Policy-Abhängigkeit führt in den dokumentierten sicheren Zustand. Eine Freigabe gibt nur genau die Anfrage, die Parameter, den Nachweis, die Policy und den Kontext frei, die dem Prüfer vorlagen.
Die vier Ergebnisse bleiben technische Bezeichner: allow (erlaubt), warn (erlaubt mit aufgezeichnetem Hinweis), require_approval (bis zur menschlichen Freigabe zurückgehalten) und block (vor jedem Effekt abgelehnt).
| Ergebnis | Bedeutung | Ausführungsverhalten | Nachweis |
|---|---|---|---|
allow | Die Anfrage liegt innerhalb der aktuellen Autorität und der Policy | Die gebundene Anfrage ausführen | Entscheidung, Versionen, Begründungen, Beleg |
warn | Die Anfrage darf mit aufgezeichnetem Hinweis fortgesetzt werden | Hinweis anzeigen und nach definierter Policy ausführen | Hinweis, Bestätigungsregel, Beleg |
require_approval | Eine qualifizierte Person muss vor Ablauf entscheiden | Zurückhalten, dann freigeben, ablehnen, Änderungen anfordern oder eskalieren | Decision Request, Befugnis des Prüfers, Begründung |
block | Die Anfrage überschreitet die Autorität oder verletzt die Policy | Vor dem Effekt stoppen | Ablehnungsgrund, Anfrage-Digest, angesteuertes Ziel |
Menschliche Freigabe an folgenreichen Grenzen verankern
Verlangen Sie eine Freigabe bei rechtewirksamen Entscheidungen, unumkehrbaren Effekten, Policy-Ausnahmen, hohen Beträgen, sensibler externer Kommunikation, Zugriffserweiterungen und ungewöhnlicher Unsicherheit. Lösen Sie zum Entscheidungszeitpunkt die aktuelle Rolle des Prüfers, sein Betragslimit, seine Delegation, seine Schulung, seine Interessenkonflikte und sein Verhältnis zum Antragsteller auf.
In Europa berührt diese Grenze häufig Artikel 22 DSGVO: Bei einer ausschließlich automatisierten Entscheidung mit rechtlicher Wirkung oder ähnlich erheblicher Beeinträchtigung kann die betroffene Person das Eingreifen einer Person verlangen, ihren Standpunkt darlegen und die Entscheidung anfechten. Eine Freigabe, die den Vorschlag des Agenten nur bestätigt, ohne Zugriff auf die Ausgangsdaten, erfüllt dieses Eingreifen nicht.
- Die genaue vorgeschlagene Aktion, das Ziel, die Werte, die betroffene Person und den erwarteten Effekt anzeigen.
- Das Policy-Ergebnis, die getroffenen Regeln, die Begründungscodes, die Ausgangsdaten, die Unsicherheit und fehlende Fakten anzeigen.
- Die Freigabe an Anfrage-Digest, Policy-Version, Momentaufnahme des Nachweises, Prüfer und Ablauf binden.
- Autorität und Policy unmittelbar vor der Freigabe erneut bewerten.
- Ablehnung, Änderungsanforderung, Eskalation, Zeitablauf und Widerspruch offen halten.
Die Berechtigungsprüfung als Kontrolltest durchführen
Beginnen Sie mit der vollständigen Grundgesamtheit aller Agenten und Service-Accounts. Vergleichen Sie beantragte, genehmigte, konfigurierte und beobachtete Autorität. Prüfen Sie direkte Rechtevergaben, geerbte Rollen, Gruppenmitgliedschaften, delegierte Zugriffe, MCP-Server, Konnektor-Secrets, Notfallausnahmen, ruhende Identitäten, Token-Laufzeiten und Berechtigungen in den Zielsystemen. In vielen Häusern läuft dieser Schritt als Rezertifizierung der Zugriffsrechte.
Laden Sie die Prüfvorlage für Berechtigungen von KI-Agenten herunter: Nachweisanforderung, Erfassung von Service-Accounts, Stichprobentests, Ausnahmeprotokoll und Prüferfreigabe.
| Feld | Erforderlicher Inhalt | Test |
|---|---|---|
| Grundgesamtheit | Jeder produktive Agent, jede Workload, Dienstidentität, jedes Gateway und jeder delegierte Pfad | Register, Identity Provider, Secrets, Gateways, Tools und Laufzeitprotokolle abgleichen |
| Autorität | Effektive Werte für Tool, Daten, Aktion, Betrag, Zweck, Umgebung und Zeitraum | Genehmigte Policy mit konfiguriertem und beobachtetem Zugriff vergleichen |
| Eigentümer und Bedarf | Benannter verantwortlicher Eigentümer und aktueller fachlicher Zweck | Von einem unabhängigen Prüfer bestätigen lassen |
| Ausnahmen | Grund, kompensierende Kontrolle, Freigeber, Ablauf | Abgelaufene oder eigentümerlose Ausnahmen zurückweisen |
| Widerruf | Ausführende Systeme, Abhängigkeiten, letzter Test, verbleibende Zugriffe | Eine repräsentative Deaktivierung durchspielen |
| Fazit | Umfang, Kriterien, Zeitraum, Stichproben, Feststellungen, Einschränkungen, nächste Prüfung | Die Zertifizierungsgrenze festhalten |
Service-Accounts über alle Kontrollebenen hinweg erfassen
Service-Accounts stehen häufig außerhalb des Agent Registry. Gleichen Sie Cloud-IAM, Anwendungen des Identity Providers, Workload-Identitäten, Kubernetes-Service-Accounts, CI-Identitäten, Einträge in Vaults und Secret-Managern, API-Gateways, registrierte MCP-Server, installierte Konnektoren, Audit-Logs der Zielsysteme und Aufzeichnungen des ausgehenden Netzverkehrs ab.
- Credentials ohne Eigentümer, ohne Signal zur letzten Nutzung, ohne Ablauf, mit weiten Wildcard-Scopes oder mit Nutzung aus mehreren Umgebungen kennzeichnen.
- Jedes geteilte Credential über das Gateway bis zu Agent, Mandant, Anfrage und nachgelagertem Beleg zurückverfolgen.
- Beobachtete Ziele und Operationen mit den genehmigten Tool- und Aktionsgrenzen vergleichen.
- Ruhende Credentials nach dem Change- und Wiederherstellungsverfahren der Organisation rotieren oder stilllegen.
Den Notfallwiderruf ausführbar machen
Legen Sie vorab fest, wer den Vorfall ausrufen darf, welchen Umfang diese Person stoppen kann und wie die Beteiligten die Eindämmung überprüfen. Sichern Sie die Nachweise während der Reaktion. Gleichen Sie nachgelagerte Effekte ab, bevor Sie Autorität wiederherstellen.
| Schritt | Aktion | Nachweis |
|---|---|---|
| 1. Umfang | Mandant, Agent, Workload, Credentials, Sitzungen, Tools, Anfragen und nachgelagerte Jobs bestimmen | Vorfall- und Korrelations-IDs |
| 2. Stoppen | Laufende Ausführungen abbrechen, wartende und freigabepflichtige Arbeit zurückhalten | Abbruchergebnisse und abgelehnte Übergänge |
| 3. Widerrufen | Identität deaktivieren, Token, Secrets, Capabilities, Sitzungen und delegierte Rechte widerrufen | Antworten der ausführenden Systeme und spätere Ablehnungen |
| 4. Isolieren | Netzwerkpfade, Konnektoren oder Zielkonten sperren, solange der Widerruf der Credentials unvollständig ist | Entscheidungen in Netz und Zielsystemen |
| 5. Abgleichen | Vollständige und teilweise Effekte auffinden, wo zulässig kompensieren | Belege, Zustand vor und nach, Kompensation |
| 6. Wiederherstellen | Ursache beheben, frische Autorität ausstellen, sicheren Zustand testen, Neustart freigeben | Change, Test, Prüfer, Neustartzeit |
Nachweise am Entscheidungspunkt erfassen
Der Nachweisdatensatz sollte einem Prüfer erlauben, die Identitätskette, die effektive Autorität, den bewerteten Kontext, das Ergebnis, die menschliche Entscheidung, den erzeugten Effekt und den späteren Widerruf zu rekonstruieren. Nutzen Sie stabile Kennungen, um die maßgeblichen nativen Datensätze zu verknüpfen. Das öffentliche Audit-Event-Schema für KI-Agenten liefert dafür einen portablen Event-Umschlag.
| Grenze | Erforderliche Felder |
|---|---|
| Identität | Mandant, Principal, Agent, Workload, delegiertes Subjekt, Aussteller, Audience, Authentifizierungsereignis |
| Berechtigung | Effektive Rollen, Attribute, Capabilities, Tool, Ressource, Daten, Aktion, Betrag, Zweck, Umgebung, Zeitraum |
| Policy | Policy- und Regelversionen, bewertete Felder, Ergebnis, Begründungscodes, Ausnahme |
| Freigabe | Anfrage-ID und Digest, befugter Prüfer, Momentaufnahme der Rolle, Entscheidung, Begründung, Ablauf |
| Ausführung | Idempotenzschlüssel, Tool-Aufruf, Beleg, Zustand vor und nach, nachgelagerter Effekt |
| Lebenszyklus | Eigentümer, Prüfung, Änderung, Widerruf, Ablehnung, verbleibender Zugriff, Kompensation, Wiederherstellung |
Praxisbeispiel: Schadenregulierung in der regulierten Versicherung
Ein Versicherer weist einen Schadenagenten dem Schadenfall CL-1842 zu. Eine dedizierte Agenten-Identität läuft unter einer attestierten Produktions-Workload. Die Policy erlaubt den zugewiesenen Schadenfall, die freigegebenen Schadenfelder, das Lesen von Dokumenten, das Entwerfen der Regulierung und Regulierungsvorschläge bis 100.000 EUR für den Zweck claim_settlement während der aktiven Zuweisung.
Ein Vorschlag über 32.000 EUR liefert require_approval, weil er die Freigabeschwelle von 25.000 EUR überschreitet. Eine qualifizierte Schadenleitung, unabhängig vom Antragsteller, prüft die Ausgangsdaten, die Policy-Begründungen, den vorgeschlagenen Zahlungsempfänger, den Betrag und den erwarteten Effekt im Hauptbuch. Die Freigabe bindet diese Werte für zehn Minuten. Das System bewertet die Policy erneut, führt genau einmal aus und verknüpft den nachgelagerten Beleg mit Anfrage und Entscheidung.
Ein abweichender Zahlungsempfänger, ein gesperrtes medizinisches Feld, eine abgelaufene Zuweisung, ein neuer Zweck, geänderte Nachweise, ein Betrag über 100.000 EUR oder ein fehlendes zwingendes Policy-Ergebnis liefern block. Der Notfallwiderruf bricht laufende Arbeit ab, deaktiviert die Credentials von Agent und Workload, sperrt den Konnektor, gleicht Teileffekte ab und zeichnet die Freigabe zur Wiederaufnahme auf.
| Stufe | Ergebnis | Nachweis |
|---|---|---|
| Identität | Agent, Workload, Mandant, Fallzuweisung und Zweck gültig | Aussteller, Subjekte, Attestierung, Zuweisung, Ablauf |
| Berechtigung | Fall, Felder, Tools, Aktion, Wertgrenze, Umgebung und Zeitraum stimmen überein | Effektive Rechtevergaben und Attribute |
| Policy | require_approval bei 32.000 EUR | Policy-Version, Schwellenwert, Begründungen, Anfrage-Digest |
| Freigabe | Eine unabhängige Leitung gibt genau diese Anfrage für zehn Minuten frei | Zulässigkeit, Rolle, Begründung, Ablauf |
| Ausführung | Policy erneut geprüft, freigegebene Überweisungsanweisung genau einmal erteilt | Beleg, Idempotenzschlüssel, Effekt im Hauptbuch |
| Prüfung | Der Prüfer zieht Stichproben aus Anfrage, Entscheidung, Ausführung und Widerrufsbereitschaft | Arbeitspapier, Ausnahme, Fazit |
MCP-Autorisierung als eine Integrationsgrenze behandeln
Das Model Context Protocol (MCP) definiert Autorisierungsabläufe für HTTP-Transporte und verweist Implementierungen auf die Sicherheitspraktiken von OAuth. Die unternehmensweite Zugriffskontrolle verantwortet weiterhin Agenten-Identität, Mandantenbindung, Rechte in den Zielsystemen, Tool-Allowlists, Daten- und Aktionsgrenzen, Freigabe, Nachweis und den Widerruf im Vorfall.
Zeichnen Sie Serveridentität, angebotene Tools, Autorisierungsserver, Audiences, Scopes, Einwilligung oder Freigabe, Token-Laufzeit, Tool-Argumente, Ergebnis und nachgelagerten Effekt auf. Der Crosswalk OWASP Agentic AI Top 10 und EU AI Act ordnet diese Integrationsrisiken den regulatorischen Pflichten zu.
Das Modell exakt auf aktuelle KLA-Verträge abbilden
Die KLA Control Plane steuert instrumentierte Aktionen zur Laufzeit. Diese Abbildung entspricht dem Code im Commit 8fd582a6. Deployment und Produktionsverhalten sind nicht verifiziert. Identity Provider, Credential-Aussteller, Verzeichnisse, Tool-Autorisierer und Berechtigungsinventare der Quellsysteme bleiben externe Instanzen.
| Funktion | Aktuelle KLA-Abbildung | Quelle | Status |
|---|---|---|---|
| Authentifizierung und Mandantenbindung | Die Execution API prüft zugelassenen JWT-Aussteller und Audience und leitet daraus die Mandantenbindung ab. | Auth-Middleware und Ausführungsroute | Code vorhanden |
| Aktionskontext und vier Ergebnisse | Policy-Anfragen tragen Principal, Ressource, Aktion, Akteur, Umgebung, Tool, Ziel, Datensensibilität und fachlichen Kontext. Die Ergebnisse sind allow, warn, require_approval oder block. | Policy-Verträge | Code vorhanden, produzentenspezifische Felder |
| Autorisierung der Control Plane | permissionProcedure authentifiziert den Aufrufer und schlägt geschlossen fehl, wenn die benannte Berechtigung fehlt. protectedProcedure authentifiziert nur; integrations.list, llmProviders.list und usage.getQuotaStatus nutzen es ohne expliziten Berechtigungsprüfschritt. Die Autorisierungsabdeckung ist prozedurspezifisch. | Prozedurdefinitionen, Integrationen, Provider und Nutzung | Code vorhanden, jede Prozedur prüfen |
| Mandantentrennung der Daten | Der Mandantenkontext begrenzt Anfragen. Mandantengebundene API-Tabellen nutzen erzwungene Row-Level Security nach dem Migrationsvertrag; die Abdeckung bleibt tabellen- und dienstspezifisch. | Mandanten-Middleware und RLS-Migration | Code vorhanden, jeden Dienst und jede Tabelle prüfen |
| Standardmäßig geschlossenes Workflow-Gate | Das Transition Gate blockiert fehlenden Work-Item-Kontext, ungelöste Pack-Verträge, fehlgeschlagene Ausgabevalidierung, Bewertungsfehler und block-Ergebnisse vor dem nächsten Schritt. | Transition Gate | Code vorhanden |
| Menschliche Freigabe | Der Decision Desk prüft Entscheidungsberechtigung, erforderliche Rolle, Wartestatus, Identität des Antragstellers und Fälligkeit der Decision Requests. | Freigabe-Router | Code vorhanden, produzentenabhängige Felder |
| Abbruch zur Laufzeit | Eine mandantengebundene Route signalisiert aktive oder zurückgehaltene Workflows. Widerruf beim Identity Provider und bei nachgelagerten Token bleibt Sache externer Aktoren. | Ausführungsabbruch | Code vorhanden, teilweise Widerrufsverteilung |
| Audit und Nachweis | Worker-Datensätze tragen Identität, Policy, Freigabe, Ausführung, Hashes und Trace-Korrelation. Der Evidence Room bündelt ausgewählte Datensätze unter einem Manifest mit Integritätsnachweisen. | Audit-Events und Nachweisvertrag | Code vorhanden über die maßgeblichen Datensätze |
Die KLA-Systemgrenze explizit halten
KLA bewertet und zeichnet die gesteuerten Aktionspfade auf, die an die KLA Control Plane angebunden sind. Vollständige Sicht auf jede Identität, jede Anmeldung, jeden Service-Account, jeden Konnektor und jede Berechtigung im Zielsystem liegt außerhalb dieser Grenze.
- Identitätslebenszyklus. Identity Provider, HR-Verzeichnisse, Attestierungsinstanzen für Workloads und Inventare der Service-Accounts verantworten Anlage, Status und Erfassung von Identitäten.
- Credential-Lebenszyklus. Aussteller, Vaults, Konnektoren und Zielsysteme verantworten Ausstellung, Rotation, Vermittlung und Widerruf nachgelagerter Credentials.
- Normalisierung der Berechtigungen. KLA-Verträge akzeptieren flexiblen Aktions- und Fachkontext. Die Produzenten verantworten normalisierte Angaben zu Zweck, Betrag, Daten, Beziehung und Zeitraum.
- Autorisierungsmodell. RBAC, ABAC und Capability-Muster sind Architekturentscheidungen. Der KLA-Policy-Vertrag ist modellunabhängig.
- Zertifizierung. KLA zeichnet Kontrollen und Nachweise auf. Die Organisation definiert Prüfkriterien, vollständige Grundgesamtheit, Stichproben, Fazit und jede Zertifizierungsgrenze.
- Widerrufsverteilung. Der Abbruch zur Laufzeit existiert. Durchgängige Identitätsdeaktivierung, Token-Widerruf, Netzisolierung, nachgelagerter Abbruch, Kompensation und Wiederherstellung erfordern abgestimmte externe Maßnahmen.
Primärquellen und Aktualität
Dieser Leitfaden wurde am 28. Juli 2026 geprüft. Normen, Spezifikationen, Entwurfsleitlinien und lokale Umsetzungen ändern sich. Prüfen Sie Primärquelle und tatsächliches Systemverhalten erneut, bevor Sie eine Audit-, Beschaffungs-, Rechts- oder Sicherheitsentscheidung treffen. Die folgenden Quellen sind in englischer Sprache veröffentlicht.
- NIST SP 800-53 Rev. 5, AC-6 Least Privilege
- NIST SP 800-162, Guide to Attribute Based Access Control
- NIST Role Based Access Control, Projekt und Referenzstandard
- NIST NCCoE, Konzeptpapier zu Identität und Autorisierung von Software- und KI-Agenten (Entwurf, veröffentlicht am 5. Februar 2026)
- RFC 8693, OAuth 2.0 Token Exchange
- RFC 8707, Resource Indicators for OAuth 2.0
- RFC 9396, OAuth 2.0 Rich Authorization Requests
- Autorisierungsspezifikation des Model Context Protocol, 25. November 2025 (zum Prüfzeitpunkt letzte veröffentlichte Fassung)
- Model Context Protocol, Release Candidate 2026-07-28 (am 21. Mai 2026 eingefroren; die endgültige Veröffentlichung war für den 28. Juli vorgesehen und lag zum Prüfzeitpunkt noch nicht vor)
- Verordnung (EU) 2024/1689 zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz
- Verordnung (EU) 2016/679 (DSGVO), Artikel 22
Häufig gestellte Fragen
Was ist Zugriffskontrolle für KI-Agenten?
Zugriffskontrolle für KI-Agenten identifiziert Agent und Workload, löst die aktuellen Berechtigungen auf, bewertet die vorgeschlagene Aktion und ihren Kontext, leitet folgenreiche Anfragen an eine befugte Person weiter und zeichnet Entscheidung und Effekt auf.
Wie gilt Least Privilege für KI-Agenten?
Vergeben Sie nur Tool, Daten, Aktion, Betrag, Zweck, Umgebung und Zeitraum, die für die genehmigte Aufgabe nötig sind. Bewerten Sie diese Grenzen vor jeder folgenreichen Aktion erneut.
Sollte ein KI-Agent RBAC oder ABAC nutzen?
Nutzen Sie RBAC für verständliche Grundpflichten und ABAC für den anfragespezifischen Kontext. Eine kurzlebige Capability oder ein Token kann Ressource, Aktion, Audience und Ablauf beim finalen Aufruf binden.
Wann muss ein KI-Agent eine menschliche Freigabe verlangen?
Bei rechtewirksamen Entscheidungen, unumkehrbaren Effekten, Policy-Ausnahmen, hohen Beträgen, sensibler Kommunikation, Zugriffserweiterungen und ungewöhnlicher Unsicherheit. Binden Sie die Entscheidung an genau diese Anfrage und einen Ablaufzeitpunkt.
Genügt eine menschliche Freigabe für Artikel 22 DSGVO?
Nicht, wenn sie den Vorschlag des Agenten nur bestätigt. Artikel 22 setzt ein tatsächliches Eingreifen voraus: Der Prüfer braucht Zugriff auf die Ausgangsdaten, die Befugnis abzulehnen und die Möglichkeit, die Entscheidung zu ändern. Die betroffene Person muss ihren Standpunkt darlegen und anfechten können.
Wie oft sollten Berechtigungen von KI-Agenten geprüft werden?
Legen Sie einen risikobasierten Rhythmus fest und lösen Sie eine Prüfung aus, sobald sich Eigentümer, Zweck, Risiko, Tools, Daten, Policy, Umgebung oder Zielsystem ändern. Dauerhafte Produktionszugriffe mit hoher Wirkung brauchen kürzere Abstände.
Wie finde ich Service-Accounts von KI-Agenten?
Gleichen Sie das Agent Registry mit Cloud-IAM, Anwendungen des Identity Providers, Workload-Plattformen, CI, Vaults, Secrets, API-Gateways, MCP-Servern, Konnektoren, Zielsystemprotokollen und dem ausgehenden Netzverkehr ab.
Was muss ein Notfallwiderruf stoppen?
Laufende und wartende Arbeit stoppen, Identitäten, Token, Secrets, Sitzungen, delegierte Rechte und Capabilities widerrufen, verbleibende Pfade isolieren, erzeugte Effekte abgleichen, die Ursache beheben und die Wiederherstellung freigeben.
Welche Nachweise belegen eine wirksame Zugriffskontrolle?
Verknüpfen Sie unter stabilen Kennungen Identität und Authentifizierung, effektive Berechtigungen, Policy-Eingaben und Ergebnis, menschliche Entscheidung, Ausführungsbeleg, Lebenszyklusänderungen, Widerruf, Prüfungen auf verbleibende Zugriffe und Wiederherstellung.
Die wichtigsten Erkenntnisse
Wirksame Zugriffskontrolle für KI-Agenten setzt auf eine vollständige Identitäts-Grundgesamtheit, eng gefasste und prüfbare Berechtigungen, vier explizite Laufzeitergebnisse, eine befugte menschliche Freigabe, einen getesteten Notfallwiderruf und durchgängig verknüpfte Nachweise. Nutzen Sie die Prüfvorlage für Berechtigungen, prüfen Sie Rechte mit dem Berechtigungsleitfaden, vertiefen Sie die Nachweisebene mit den Audit-Trails und setzen Sie die portablen Felder des Audit-Event-Schemas für KI-Agenten um.