Delegation, not impersonation

An agent never uses the human’s token. It sends that token to Subact ID with proof of its own identity, and gets back a task token that says it acts for the human.

Impersonation

With impersonation, the agent holds a token that says it is the person. sub is the user, and nothing in the token names the agent. Every downstream system records the action as the user’s own, so afterwards nobody can tell what the person did from what software did for them.

Delegation

A task token keeps the human in sub and names the agent in act, the actor claim from RFC 8693:

{
  "sub": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "act": {
    "sub": "agent:jira-triage",
    "depth": 1
  }
}

Authorization downstream is about the human’s authority. The action is attributed to both the human and the agent that took it.

What this gives you

• A tool server can tell the two apart. A token with no act claim was presented by a human directly; a token with one was presented by an agent. @subactid/server and @subactid/mcp accept only tokens with an act claim by default (requireActor, default true); set it to false on a route a human may also call directly.
• The audit answers “what did any agent do for this person”. Because sub is always the human, that is one filter on the audit ledger.
• Authority cannot exceed the person. The task token is derived from the user’s own token, so it cannot carry scopes the user does not have. See scope.

The rule

sub is always the human. The agent appears in act, never in sub.

It is the first of the five invariants and the first conformance test: a subject token whose subject is an agent is invalid_grant. There is no setting that turns this off.

v0.1 issues depth 1 only: the subject token is always a user’s token, and sub-agent delegation is not in v0.1. See delegation depth.

How an agent authenticates

Agents authenticate with private_key_jwt only: the agent signs a short-lived assertion with a key Subact ID never holds. The discovery document advertises no other method. Client secrets (client_secret_post) are not supported, and mTLS is not in v0.1.