Authority Token Model#

An Authority Token is a cryptographically signed artifact that proves a specific action was verified against policy and authorized by the Intended runtime. This page covers the token's internal structure, how it is signed and verified, and how tokens behave through their lifecycle.

What an Authority Token Represents#

An Authority Token is not an identity credential and not an access token in the OAuth sense. It is an authorization proof — a signed record that a particular intent was submitted to the authority runtime, evaluated against the tenant's policy set, and resulted in an explicit allow decision.

The token encodes everything needed to independently verify that proof:

• The action and resource that were authorized
• The identity that requested authorization
• The tenant context
• The policies that were evaluated
• When the authorization was granted and when it expires
• A cryptographic signature that binds all of the above together

Token Structure#

Authority Tokens use a compact, signed format with three sections: header, payload, and signature.

Header#

The header identifies the signing algorithm and key:

{
  "alg": "ES256",
  "typ": "authority+jwt",
  "kid": "tenant_acme:key_2026Q1"
}

Payload#

The payload contains the authorization claims:

{
  "iss": "intended:runtime",
  "sub": "agent:support-bot-v3",
  "aud": "service:customer-api",
  "iat": 1741444200,
  "exp": 1741444500,
  "tid": "tenant_acme",
  "act": "read",
  "res": "customer:record:12345",
  "pol": ["pol_read_access:3", "pol_agent_scope:7"],
  "ctx": {
    "environment": "production",
    "workflow": "ticket-resolution"
  },
  "jti": "dtk_a1b2c3d4e5f6"
}

Signature#

The signature is produced by signing the encoded header and payload with the tenant's private signing key:

signature = ECDSA_SIGN(
  base64url(header) + "." + base64url(payload),
  tenant_private_key
)

The final token is the three sections concatenated with dots:

base64url(header).base64url(payload).base64url(signature)

Cryptographic Signing#

Key Management#

Each tenant has a dedicated signing key pair. The private key is used by the Intended runtime to sign tokens; the public key is distributed to downstream services for verification.

Key properties:

• Algorithm: RSA with SHA-256 (RS256)
• Key storage: Private keys are stored in the runtime's secure key store and are not exportable
• Key rotation: Keys can be rotated without invalidating in-flight tokens. The kid field in the token header allows verifiers to select the correct key during a rotation window
• Key distribution: Public keys are available via a JWKS endpoint scoped to each tenant

Signing Process#

Verification#

Verification is the process by which a downstream service confirms that a decision token is authentic, unexpired, and applicable to the request being made.

Verification Steps#

Offline Verification#

Token verification does not require a call back to the Intended runtime. The verifying service only needs the tenant's public key, which it obtains from the JWKS endpoint and caches locally. This design means:

• Verification latency is sub-millisecond (a local cryptographic operation)
• The Intended runtime is not a single point of failure in the enforcement path
• Services can verify tokens even during a temporary runtime outage, as long as they have cached keys

Token Lifecycle#

Issuance#

Tokens are issued only by the Intended runtime, only after a successful policy evaluation, and only within the evaluated tenant's context.

Validity Window#

Every token has a finite validity window defined by iat and exp. The default TTL is 5 minutes, configurable per tenant. Shorter windows are recommended for sensitive operations.

Single Use vs. Reuse#

Decision tokens are not explicitly single-use by default. A token remains valid until it expires. However, because tokens are bound to a specific action and resource, the practical scope for reuse is narrow — the same caller would need to perform the exact same operation on the exact same resource within the token's TTL.

For operations where strict single-use is required, the downstream service can record the jti and reject any token it has seen before.

Revocation#

In cases where a token must be invalidated before its natural expiry — for example, if the policy that authorized it is rolled back — the runtime supports explicit revocation:

• The operator or API client calls the revocation endpoint with the token's jti
• The runtime publishes the revocation to a revocation list
• Verifying services that check the revocation list will reject the token

Expiry#

Once a token's exp time passes, it is no longer valid. No explicit cleanup is needed — expired tokens are simply rejected on verification. The audit log retains the record of the token's issuance and any verification events.

Token vs. Identity Credentials#

It is important to distinguish decision tokens from identity credentials (e.g., OAuth access tokens, API keys):

A single request may carry both an identity credential (to authenticate the caller) and a decision token (to prove authorization). These are complementary, not redundant.

Related Resources#

• What Is Intended — platform overview
• Authority Runtime Pipeline — how tokens are issued within the pipeline
• Tenant Trust Boundary — how tenant key isolation works
• Verify a Token — practical guide to token verification using the API and CLI