KI-Agenten sicher autorisieren:
Fünf Kontrollpunkte vor dem Tool-Aufruf

KI-Agenten sicher autorisieren heißt, ihre Identität, delegierte Rechte und jede konkrete Aktion getrennt zu prüfen. Ein Agent sollte nicht mit dem Konto seines Nutzers auftreten und auch nicht aus einem erlaubten Ziel selbst ableiten, welche Tools, Datensätze oder Seiteneffekte zulässig sind. Die letzte Entscheidung gehört an die technische Grenze unmittelbar vor dem Tool-Aufruf.

Für mittelständische Produkt- und Engineering-Teams ist das inzwischen eine praktische Architekturfrage. Ein Assistent, der nur Text formuliert, hat ein anderes Schadenspotenzial als ein Agent, der E-Mails sendet, Tickets ändert, Code ausführt oder Bestellungen auslöst. Je mehr Systeme verbunden werden, desto weniger genügt ein einmaliges Login als Beleg für eine spätere Aktion.

Warum Agenten-Identität jetzt zur Produktionsfrage wird

Das NIST beschreibt am 27. August 2026 vier wiederkehrende Schwächen: geteilte Anmeldedaten, statische oder langlebige Tokens, zu breite Rechte und eine Überlastung manueller Freigaben. NIST empfiehlt, Agenten als eigenständige Entitäten mit eindeutiger Identität, eigenen Zugangsdaten und zugeordneten Berechtigungen zu behandeln, die an den handelnden Nutzer oder das betreibende System gebunden bleiben.

Das ist kein fertiger Agentenstandard. Auch das zugrunde liegende NCCoE-Konzeptpapier vom 5. Februar 2026 ist ein Entwurf. Die aktuelle Richtung ist dennoch belastbar: Bekannte Identity-and-Access-Management-Grundsätze gelten weiter, müssen aber an Geschwindigkeit, Delegationsketten und probabilistische Planung angepasst werden.

Die entscheidende Trennung lautet: Authentifizierung beantwortet, welcher Agent und welcher Auftraggeber anfragen. Autorisierung entscheidet, ob genau diese Aktion an genau dieser Ressource unter den aktuellen Bedingungen erlaubt ist. Ein gültiges Token beweist deshalb nicht, dass ein vom Modell erzeugter Parameter fachlich richtig, noch erforderlich oder sicher ist.

Fünf Kontrollpunkte für sichere Agenten-Autorisierung

Die Tabelle ist ATMAN-Analyse auf Basis der genannten Quellen. Sie übersetzt Standards in testbare Systemgrenzen; sie behauptet weder, dass ein einzelnes Produkt alle Kontrollen liefert, noch dass ein erfolgreicher Test jedes Modellverhalten absichert.

1. Eigene Identität statt Nutzer-Imitation

Ein produktiver Agent braucht mindestens eine stabile Agentenkennung, eine kurzlebige Lauf- oder Sitzungskennung und einen Verweis auf den delegierenden Nutzer oder Systemauftrag. Der Downstream-Dienst muss erkennen können, ob eine Person direkt handelt, ein Agent im Namen einer Person handelt oder ein Systemauftrag ohne aktuellen Nutzerkontext läuft.

Gemeinsam genutzte API-Schlüssel zerstören diese Zuordnung. Wenn zehn Agenten dasselbe Secret verwenden, kann ein Audit nur den Schlüssel, nicht den tatsächlichen Akteur unterscheiden. Speichern Sie langlebige Schlüssel deshalb nicht in Prompts, Markdown-Dateien oder Logs. Nutzen Sie einen Secret- oder Token-Dienst, der Identität und Umgebung prüft und erst zur Laufzeit einen begrenzten Nachweis ausstellt.

2. Rechte als Auftrag beschreiben, nicht als grobe Rolle

„CRM-Zugriff“ oder „E-Mail verwenden“ ist für einen Agenten zu ungenau. Eine Delegation sollte mindestens Aktion, Zielressource, Zielsystem, Datenklasse, Gültigkeitsfenster und zulässige Menge enthalten. Für einen Supportfall könnte das heißen: Ticket 4711 lesen, einen Antwortentwurf erzeugen, aber weder senden noch Kontaktdaten exportieren.

Der IETF-Standard OAuth 2.0 Rich Authorization Requests (RFC 9396, Mai 2023) stellt dafür strukturierte authorization_details bereit. Felder wie Aktionen, Orte, Datentypen und Identifikatoren können präzisere Rechte als ein grober Scope ausdrücken. Ob das im konkreten Stack verfügbar ist, muss geprüft werden; die Architekturidee lässt sich auch in einem Policy-Dokument oder Capability-Token abbilden.

Tokens sollten kurzlebig, zielgruppengebunden und widerrufbar sein. NIST IR 8587 vom 22. Dezember 2025 ist zwar auf Behörden und Cloudanbieter ausgerichtet und weiterhin ein Initial Public Draft. Seine Empfehlungen zu Schlüsselisolation, Tokenprüfung, Lebenszyklus und kontinuierlicher Überwachung sind aber ein nützlicher technischer Mindestcheck.

3. Den Tool-Aufruf außerhalb des Modells entscheiden

Die zentrale Sicherheitsgrenze liegt zwischen Planung und Wirkung. Das Modell darf ein Tool und Argumente vorschlagen; eine deterministische Komponente muss sie gegen ein Schema und eine Policy prüfen. Diese Komponente sollte weder durch Prompt-Inhalt noch durch Agenten-Speicher veränderbar sein.

1. Normalisieren. Lösen Sie Aliase, Objektpfade, Einheiten und Standardwerte vor der Entscheidung eindeutig auf.
2. Validieren. Verwerfen Sie unbekannte Felder, falsche Typen, unzulässige Werte und mehrdeutige Ziele.
3. Autorisieren. Prüfen Sie Nutzer, Agent, Aktion, Ressource, Zweck, Zeit, Umgebung und aktuelles Risiko gemeinsam.
4. Budgetieren. Begrenzen Sie Aufrufe, Datensätze, Kosten, Parallelität und Wiederholungen pro Lauf.
5. Ausführen. Übergeben Sie nur die bereits geprüfte, unveränderliche Aktion an einen minimal berechtigten Adapter.
6. Verifizieren. Erfassen Sie Ergebnis und tatsächlichen Seiteneffekt; ein HTTP-200 allein beweist keinen fachlichen Erfolg.

Ein aktuelles, anbieterspezifisches Beispiel liefert der AWS Security Blog vom 27. August 2026: Prüfungen vor dem Modell, unmittelbar vor dem Tool-Aufruf und nach der Tool-Antwort. AWS kombiniert deterministische Schema-, Regex- und Allowlist-Prüfungen mit modellbasierten Guardrails. Der übertragbare Punkt ist die Lage der Kontrollstellen, nicht die Bindung an einen bestimmten Cloud-Dienst.

4. Freigaben nach Schadenspotenzial staffeln

Eine Freigabe vor jedem Lesezugriff macht den Agenten unbrauchbar; eine pauschale Zustimmung für eine ganze Sitzung macht sie bedeutungslos. Ordnen Sie Aktionen deshalb nach Wirkung. Eng begrenzte, lesende und reversible Aktionen können automatisch laufen. Externe Kommunikation, personenbezogene Exporte, Zahlungen, Löschungen, Produktionsänderungen oder Rechteerweiterungen brauchen eine ausdrückliche Freigabe oder bleiben vollständig gesperrt.

Die Freigabe muss zeigen, was passieren wird: Ziel, Empfänger, Datenumfang, Betrag, Umgebung und relevante Parameter. Sie sollte einen Hash oder eine unveränderliche Aktions-ID binden, damit nachträgliche Parameteränderungen eine neue Entscheidung erfordern. Fragen Sie dabei niemals Passwörter oder Secrets im Agentendialog ab. Die MCP-Spezifikation vom 18. Juni 2025 untersagt Servern ausdrücklich, über Elicitation sensible Informationen anzufordern.

5. Tokens binden und Entscheidungen prüfbar machen

Ein gestohlenes Bearer-Token kann grundsätzlich von jedem präsentiert werden, der es besitzt. DPoP nach RFC 9449 (September 2023) kann OAuth-Tokens an einen Schlüssel binden und Replay-Angriffe erkennbar machen. Der Standard grenzt seine Wirkung selbst klar ein: DPoP ist allein weder Client-Authentifizierung noch Zugriffskontrolle. Es schützt also den Präsentationsweg, nicht die fachliche Zulässigkeit einer Aktion.

Der Audit-Trail sollte Nutzer- und Agentenidentität, Run-ID, Tool, normalisierte Aktion, Zielressource, Policy-Version, Entscheidung, Freigabe-ID, Ergebnis, Zeit und Korrelations-ID verbinden. Protokollieren Sie keine Secrets und nur die fachlich notwendigen personenbezogenen Daten. Getrennte Zugriffsrechte, manipulationserschwerende Speicherung und definierte Aufbewahrung machen den Nachweis belastbarer.

Für die Umsetzung passen Agenten- und Datenflussdesign in einen klar abgegrenzten KI- und Daten-Scope. Identitätsmodell, Policy-Grenze, Secrets, Protokollierung und Missbrauchstests gehören parallel in das Cybersicherheitsdesign. Die technische Umsetzung der AI-Act-Transparenzpflichten behandelt ergänzend Hinweise, Markierungen und Human Review am Ausgabekanal.

Produktionscheck: Sechs Tests vor dem Rollout

1. Identitätswechsel testen. Wiederholen Sie denselben Auftrag mit einem anderen Nutzer und einem anderen Agenten; Daten und Rechte dürfen nicht mitwandern.
2. Parameter manipulieren. Tauschen Sie Objekt-ID, Empfänger, Betrag, Umgebung und Tool bei ansonsten gültigem Token aus.
3. Delegation abschwächen. Prüfen Sie, ob ein Unterauftrag niemals mehr Rechte als sein Elternauftrag erhält.
4. Freigabe veralten lassen. Ändern Sie nach Zustimmung einen Parameter oder lassen Sie das Zeitfenster ablaufen; die Ausführung muss stoppen.
5. Token entwenden. Versuchen Sie Replay aus einem anderen Prozess oder mit anderem Schlüssel und prüfen Sie Alarm sowie Widerruf.
6. Ende zu Ende korrelieren. Rekonstruieren Sie vom Nutzerauftrag über Policy-Entscheidung und Tool-Aufruf bis zum tatsächlichen Ergebnis.

Ein Rollout ist erst dann belastbar, wenn erlaubte Aktionen funktionieren und verbotene Varianten nachweisbar scheitern. Beginnen Sie mit einem einzigen, reversiblen Workflow. Erweitern Sie Tools, Rechte und Automatisierungsgrad erst, wenn Negativtests und Widerruf im Betrieb sichtbar sind.

Häufige Fragen zur Autorisierung von KI-Agenten

Warum reicht ein eigenes Konto für einen KI-Agenten nicht aus?

Ein eigenes Konto macht den Agenten identifizierbar, begrenzt aber noch nicht jede Aktion. Zusätzlich braucht es delegierte, kurzlebige Rechte und eine deterministische Prüfung von Tool, Ressource, Parametern und Kontext unmittelbar vor der Ausführung.

Soll jeder Tool-Aufruf manuell freigegeben werden?

Nein. Lesende, reversible und eng begrenzte Aktionen können nach festgelegten Regeln automatisch laufen. Eine explizite Freigabe ist vor allem für irreversible, externe, finanzielle, privilegierte oder ungewöhnliche Aktionen sinnvoll.

Verhindert DPoP den Missbrauch von Agenten-Tokens vollständig?

Nein. DPoP bindet ein OAuth-Token an einen kryptografischen Schlüssel und erschwert Replay durch Dritte. Der Standard sagt ausdrücklich, dass DPoP allein weder Authentifizierung noch Zugriffskontrolle ersetzt.

Welche Daten gehören in einen Audit-Trail?

Mindestens Nutzer- und Agentenidentität, Run-ID, Tool und Aktion, Zielressource, normalisierte Parameter, Policy-Version, Entscheidung, Freigabe, Ergebnis, Zeitstempel und Korrelations-ID. Geheimnisse und unnötige personenbezogene Daten gehören nicht in Klartextprotokolle.