Identity limits scope of action

In 30 seconds

As soon as an agent does not merely answer but reads, decides or acts, it needs its own verifiable identity, the least possible rights, a traceable delegation of human authority and controlled paths for approval and escalation. Without this foundation, risks shift from “wrong answer” to “undesired action”.

Why it matters

Classical software acts within firmly programmed paths. An agent partly chooses its own path and calls tools in doing so. If this happens under a shared collective account with far-reaching rights, it is afterwards neither recognisable who initiated something nor can the damage be contained.

Identity is therefore the lever with which scope of action can be limited and attributed in the first place.

Editorial assessmentIn practice, the agent identity is often the step skipped first — because a pilot is “only supposed to read”. It is precisely this pilot that then grows unnoticed into writing actions. The identity question belongs at the beginning, not at the end.

The core architecture questions

• Under which identity does the agent act — its own account, delegated user identity or collective account?
• Which rights are really necessary, separated into read, propose and execute?
• How are accesses time-limited (short-lived tokens instead of permanent keys)?
• At which points is human approval mandatory?
• How can a running action be stopped immediately in an emergency?

Typical patterns

• Non-Human Identities: every agent receives its own machine identity.
• Least Privilege: minimal rights, separated into read · propose · execute.
• Short-lived Tokens: tightly time-limited accesses (cf. RFC 9700).
• Human Approval: risky actions go to a human for approval.
• Policy Enforcement: permitted actions are enforced centrally, not merely described in the prompt.
• Kill Switch: a defined path halts agent activity immediately.

Common misconceptions & anti-patterns

• Shared, long-lived API keys for multiple agents or purposes.
• Agents run under an administration account “so that it works”.
• No separation between read, propose and execute.
• Permissions explained only in the prompt, not enforced technically.
• Writing actions without approval and without rollback.

Practical review questions

1. Does every agent have its own identity assigned to a responsible party?
2. Can we say for an action who triggered it under which rights?
3. Do all tokens expire — and how soon?
4. Which actions are excluded without human approval?
5. Does the Kill Switch work — has it been tested?

Link to the end-to-end worked example

Under which identity does the agent act, which rights does it have — and where is an approval mandatory?

• The agent has its own machine identity (no shared collective account) with minimal rights.
• Access is short-lived (time-limited tokens) and separated into reading, proposing and executing.
• The triggering action requires explicit human approval (human-in-the-loop).
• A kill switch halts the agent's activity immediately in an emergency — tested, not just documented.

To the full worked example: service agent →

Link to the reference architecture

This mission operates in the Control Plane across all layers — above all Identity & Delegation, Policy & Approval as well as Observability & Audit.

Primary sources

Change history

• 25.06.2026 — Editorial Page restructured according to the mission template.
• 24.06.2026 — Editorial (subject matter) Initial publication with primary sources.