Identität begrenzt Handlungsmacht

In 30 Sekunden

Sobald ein Agent nicht nur antwortet, sondern liest, entscheidet oder handelt, braucht er eine eigene, überprüfbare Identität, möglichst geringe Rechte, eine nachvollziehbare Delegation menschlicher Befugnisse und kontrollierte Wege für Freigabe und Eskalation. Ohne diese Grundlage verschieben sich Risiken von „falscher Antwort“ zu „unerwünschter Handlung“.

Warum das wichtig ist

Klassische Software handelt im Rahmen fest programmierter Pfade. Ein Agent wählt seinen Weg teilweise selbst und ruft dabei Werkzeuge auf. Geschieht das unter einem geteilten Sammelkonto mit weitreichenden Rechten, ist im Nachhinein weder erkennbar, wer etwas veranlasst hat, noch lässt sich der Schaden eingrenzen.

Identität ist deshalb der Hebel, mit dem sich Handlungsmacht überhaupt erst begrenzen und zuordnen lässt.

Redaktionelle EinordnungIn der Praxis ist die Agentenidentität oft der zuerst übersprungene Schritt — weil ein Pilot „nur lesen“ soll. Genau dieser Pilot wächst dann unbemerkt in schreibende Aktionen hinein. Die Identitätsfrage gehört an den Anfang, nicht ans Ende.

Die zentralen Architekturfragen

• Unter welcher Identität handelt der Agent — eigener Account, delegierte Nutzeridentität oder Sammelkonto?
• Welche Rechte sind wirklich nötig, getrennt nach Lesen, Vorschlagen und Ausführen?
• Wie werden Zugriffe zeitlich begrenzt (kurzlebige Tokens statt Dauer-Keys)?
• An welchen Stellen ist eine menschliche Freigabe verpflichtend?
• Wie lässt sich eine laufende Handlung im Ernstfall sofort stoppen?

Typische Muster

• Non-Human Identities: jeder Agent erhält eine eigene Maschinenidentität.
• Least Privilege: minimale Rechte, getrennt nach Lesen · Vorschlagen · Ausführen.
• Kurzlebige Tokens: eng befristete Zugriffe (vgl. RFC 9700).
• Human Approval: riskante Aktionen gehen an einen Menschen zur Freigabe.
• Policy Enforcement: erlaubte Aktionen werden zentral erzwungen, nicht nur im Prompt beschrieben.
• Kill Switch: ein definierter Weg hält Agentenaktivität sofort an.

Häufige Fehlannahmen & Anti-Patterns

• Geteilte, langlebige API-Keys für mehrere Agenten oder Zwecke.
• Agenten laufen unter einem Administrationskonto „damit es funktioniert“.
• Keine Trennung zwischen Lesen, Vorschlagen und Ausführen.
• Berechtigungen nur im Prompt erklärt, technisch nicht erzwungen.
• Schreibende Aktionen ohne Freigabe und ohne Rollback.

Praktische Prüffragen

1. Hat jeder Agent eine eigene, einem Verantwortlichen zugeordnete Identität?
2. Können wir für eine Aktion sagen, wer sie unter welchen Rechten ausgelöst hat?
3. Laufen alle Tokens ab — und wie kurz?
4. Welche Aktionen sind ohne menschliche Freigabe ausgeschlossen?
5. Funktioniert der Kill Switch — wurde er getestet?

Bezug zum durchgehenden Praxisbeispiel

Unter welcher Identität handelt der Agent, welche Rechte hat er — und wo ist eine Freigabe Pflicht?

• Der Agent hat eine eigene Maschinenidentität (kein geteiltes Sammelkonto) mit minimalen Rechten.
• Zugriffe sind kurzlebig (befristete Tokens) und getrennt nach Lesen, Vorschlagen und Ausführen.
• Die auslösende Aktion erfordert eine ausdrückliche menschliche Freigabe (Human-in-the-Loop).
• Ein Kill Switch hält die Agentenaktivität im Ernstfall sofort an — getestet, nicht nur dokumentiert.

Zum vollständigen Praxisbeispiel: Service-Agent →

Bezug zur Referenzarchitektur

Diese Mission wirkt im Control Plane quer über alle Ebenen — vor allem Identity & Delegation, Policy & Approval sowie Observability & Audit.

Primärquellen

Änderungshistorie

• 25.06.2026 — Redaktionell Seite nach dem Mission-Template neu strukturiert.
• 24.06.2026 — Fachlich Erstveröffentlichung mit Primärquellen.