Authority

Authority binds externally issued identity, capacity, mandate, or consent evidence to one agent key, receiver, purpose, scope, validity period, and optional Mission. The core model is provider-neutral. Issuer and receiver integrations live in immutable versioned profiles.

external issuer -> principal and capacity proof -> mandate
  -> authority binding -> agent key -> Mission and action
  -> receiver presentation -> receiver receipt

The primitives stay separate

• Identity says what a provider verified about a subject. It does not, by itself, authorize an action.
• A Mission bounds one operational job. It is not a mandate.
• An authority binding joins the represented principal, required authorizers and proofs, exact agent key, receiver, purpose, allowed actions, limits, disclosure policy, delegation policy, and expiry.
• A Passport carries short-lived opaque authority references. It does not copy proof material or mandate text into the JWT.
• An authority use records the exact binding, Passport, Mission, action, receiver, hashes, proof strength, and outcome for one transaction.

Who approved, and in what capacity

An owner or admin reviews the agent, connected system, job, limits and expiry once. STACK then applies those terms automatically to matching actions. The approval records the verified person separately from the company role under which they approved.

With company sign-in, STACK verifies both the person and the configured company-role claim. With Stripe Identity, Stripe verifies the person and the customer account supplies the company role recorded with the approval. In both cases the approval is signed over the exact Authority terms and cannot outlast the fresh identity evidence or one hour.

Passport reference

Passport issue accepts up to eight authority_binding_ids. STACK resolves each active binding against the exact agent and current agent key. The JWT receives only the immutable reference below.

{
  "authority_refs": [{
    "binding_id": "abn_...",
    "binding_version": 1,
    "binding_claim_id": "pc_...",
    "binding_digest": "sha256:...",
    "receiver_id": "rcv_...",
    "receiver_profile_version_id": "apv_...",
    "expires_at": 0
  }]
}

Activation and delegation

Activation fails closed when a required principal, proof, approval, profile, receiver key, agent key, live-status result, or validity rule is missing or invalid. Delegation creates a child binding. It keeps the principal, receiver, purpose, and proof lineage fixed while every action, resource, limit, disclosure, approval, expiry, and further-delegation dimension stays equal or narrower. Delegation depth cannot exceed four.

Human governance

• Owners and admins configure principals, proofs, profiles, receivers, and bindings. Trust expansion and erasure can require a governance step-up.
• A named human authorizer can decide only their exact approval slot and request digest.
• An agent can use assigned authority, narrow an allowed delegation, or revoke its own chain.
• An agent cannot create a principal, import or select proof, configure receiver trust, approve or activate authority, widen a binding, resolve a fact, or receive presentation data.
• Partner grants and platform staff receive no ambient authority-management access.

Native verification and proxy mediation

A native receiver authenticates its request, receives a signed-then-encrypted presentation, verifies it independently, checks live authority state, and returns a signed receipt. STACK delivers the encrypted result directly to the pinned receiver. The agent receives neither plaintext nor ciphertext.

A legacy receiver cannot perform that protocol. In proxy mediation, STACK evaluates the same binding, injects only permitted values inside the proxy path, and records a STACK-signed mediated result. This proves STACK enforcement, not independent receiver verification.

Evidence, revocation, and erasure

Authority uses and ordinary evidence responses store opaque references, hashes, lifecycle codes, disclosure manifests, proof strength, and outcomes. They do not store disclosed values. Revocation cascades through dependent proofs, bindings, descendants, linked Passports, approvals, and pending presentations. Erasure revokes first, destroys sensitive ciphertext, and retains only non-PII tombstone material needed to prove what was erased.

See Authority in the Console, Authority API, Passports, and Identity.