# Mission 004: Identität begrenzt Handlungsmacht

> Unter wessen Identität handelt ein Agent — und welche Aktionen darf er wirklich ausführen?

**Ergebnis:** Least Privilege, Delegationsgrenzen, Freigaben und nachvollziehbare Verantwortlichkeit.

Veröffentlicht 24.06.2026 · zuletzt geändert 25.06.2026 · fachlich geprüft von Markus Berg (25.06.2026) · für Einsteiger, Architektur, Security.

## 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 Einordnung:_ In 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.

## Zentrale 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.

## 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
- Hat jeder Agent eine eigene, einem Verantwortlichen zugeordnete Identität?
- Können wir für eine Aktion sagen, wer sie unter welchen Rechten ausgelöst hat?
- Laufen alle Tokens ab — und wie kurz?
- Welche Aktionen sind ohne menschliche Freigabe ausgeschlossen?
- Funktioniert der Kill Switch — wurde er getestet?

## Bezug zum Praxisbeispiel (Service-Agent)
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 durchgehenden Praxisbeispiel](https://agent-007.ai/praxis/service-agent.md)

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

## Primärquellen
- [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) — OWASP (Primärquelle), geprüft 24.06.2026. Tool Misuse, Identitäts- und Berechtigungsprobleme, Memory-/Context-Risiken und kaskadierende Fehler.
- [OAuth 2.0 Security Best Current Practice (RFC 9700)](https://datatracker.ietf.org/doc/rfc9700/) — IETF (Standard / RFC), geprüft 24.06.2026. Aktuelle Sicherheitsleitlinien für delegierte, kurzlebige OAuth-Zugriffe.
- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) — NIST (Offizielles Framework), geprüft 24.06.2026. Übergreifende Struktur für Verantwortlichkeiten und Kontrollen.



---
Quelle (kanonisch): https://agent-007.ai/missionen/004-identitaet-security-governance/