Threat model

What it defends against

A leaked agent credential. An agent holds a task token that lives minutes and a task grant bound to one task, one audience and one agent. A refresh authenticates the agent exactly as the exchange did, so a grant presented by another agent is refused.

An agent exceeding the person it acts for. The token’s scope is the intersection of the user’s scopes, the agent’s registration and the request, and it never widens at refresh. See scope.

An agent reaching an audience it was not registered for. The audience must be in the agent’s allowed_audiences; anything else is invalid_target. A task is bound to its audience.

An off-boarded user’s agents carrying on. A human Subact ID will not act for fails every refresh and cannot start a new task. In poll mode, a person disabled at the identity provider is refused within one token lifetime. In signals mode, Subact ID acts on what it is told: an operator block, SCIM, Shared Signals or back-channel logout. See the sponsor check.

A replayed client assertion. Each assertion jti is accepted once, an assertion may live at most five minutes, and a replay is invalid_client.

Quiet edits to the audit record. The ledger refuses UPDATE, DELETE and TRUNCATE, and signed checkpoints seal every record. A changed, removed or inserted record no longer builds the signed root, and the signing key is not in the database. Records written since the last checkpoint (a minute by default) are not yet sealed. See the audit ledger.

An anonymous flood filling the ledger. Requests are rate-limited per source, and denials that name nobody are summarised per reason per window. Attributable denials are never summarised.

A stopped task doing one more thing, where the token is introspected. Tokens for an audience in high_risk_audiences carry introspect_required, and both server SDKs introspect them on every call, so revocation takes effect at once. A tool server that validates locally and ignores the claim is bounded by max_token_ttl. See revocation.

What it assumes

• Your identity provider is correct. Subact ID does not authenticate people. If your provider issues a token for the wrong person, Subact ID delegates that person’s authority.
• The database is not hostile. The seal detects edits, but someone with write access can cut the tail: the last checkpoint and the records it sealed. Keep the last checkpoint that audit-verify prints somewhere else, or copy GET /audit/checkpoints elsewhere.
• Agent private keys are kept safe. Whoever holds an agent’s key is that agent, within that agent’s registration.
• The signing key is kept safe. Whoever holds it can mint tokens your tool servers accept, for any scope and audience.
• TLS is terminated by something you trust, and the control plane is reachable only from where it needs to be.

Out of scope for v0.1

• Admin identities and roles. One admin API key grants every admin operation. To rotate it, change the setting and restart.
• Multi-tenancy. One instance serves one organisation.
• Sub-agent delegation. v0.1 issues depth 1 only. See delegation depth.
• Agents without a human. Every exchange needs a human subject token, and a registration with sponsor_required: false is refused.
• mTLS client authentication. Agents authenticate with private_key_jwt only.
• Denial of service. A per-source rate limiter and an overload limit are on by default (429 slow_down, 503 temporarily_unavailable). They do not stop unbounded volume; put a load-shedding layer in front.
• Misuse of authority the user really has. If a person may delete a project and their agent is registered for that scope, Subact ID issues a token that can delete it. It records who did it and for whom.
• Confidentiality of tool data. Subact ID sees scopes, audiences and identifiers, not what tool servers return.
• Hardening of example configuration. The quickstart is a demonstration.

Sharp edges

1. Local validation makes revocation eventual, bounded by max_token_ttl. A kill switch does not reach a token in flight unless the tool server introspects.
2. audit-verify cannot detect a cut tail on its own. Keep its last checkpoint elsewhere. The newest records are not sealed until the next checkpoint.
3. In signals mode, Subact ID enforces only what it is told. A person disabled at a provider that sends nothing keeps their tasks until they expire, bounded by max_task_ttl. Block them through the admin API, configure SCIM or Shared Signals, or use poll mode.