Identity

An agent shows up with an API key. The key tells you which program is calling. It does not tell you which person the program is acting for, what it's allowed to do right now, or when its permission ends.

User accounts assume a human at a keyboard. Service accounts assume a fixed program with a fixed job. Agents are neither: they change task by the minute and act for different people in the same session.

Identity for a non-human caller is a triple: who the workload is, on whose behalf it is acting, and what it is currently scoped to do. All three travel with the request, or the request should not be honoured.

Aarmos treats the caller, the authority, and the scope as distinct fields on every decision. Delegation attenuates — it never escalates.

A support agent is triaging a ticket. Its identity says workload=triage-agent, on-behalf-of=alice, scope=read:ticket,write:reply, expires=90s. A refund call under this identity is denied — not because the agent is untrusted, but because Alice's delegation never granted refunds.

Isn't this what OAuth tokens do?

Tokens can carry it, but most deployments collapse to a service account with a static scope. The point is treating the three fields as first-class, not stuffing them into a claim.

How does this differ from an API key?

An API key is one field: who. Identity as we mean it also encodes the human authority and the current scope.

Where does this show up in a receipt?

As explicit fields — see Authorities for the chain.

• Authorities
• Delegation
• Receipts
• Glossary