Token Replay Protection: How It Works

The Replay Attack Problem

When Intended's Authority Engine authorizes an AI agent action, it issues a cryptographic authority token. This token is signed proof that the action was evaluated against policies, scored for risk, and approved. The agent presents this token when executing the authorized action.

But tokens create a new attack vector: replay attacks. If an agent (or a malicious actor who intercepts a token) can reuse an authority token, they can re-execute an authorized action without going through governance again. Imagine an agent authorized to transfer $10,000. If the authority token can be replayed, that single authorization becomes unlimited transfers.

Token replay protection is not optional. It is a fundamental security requirement for any token-based authorization system. Here is how Intended implements it.

Three Layers of Protection

Intended uses three independent mechanisms to prevent token replay. Each mechanism is sufficient on its own. Together, they create defense in depth that prevents replay even if one mechanism fails.

Layer 1: Cryptographic Nonces

Every authority token includes a cryptographic nonce: a random value generated at token issuance time. The nonce is 256 bits of cryptographically secure randomness, generated using the platform's CSPRNG (Cryptographically Secure Pseudo-Random Number Generator).

When a token is issued, the nonce is recorded in Intended's token ledger. When a token is presented for execution, the system checks the nonce against the ledger. If the nonce has already been consumed, the token is rejected. After successful verification, the nonce is marked as consumed.

The nonce check is an atomic operation. The lookup and the mark-as-consumed happen in a single transaction. This prevents race conditions where two concurrent requests attempt to use the same token simultaneously. Both requests read the ledger, both see the nonce as unconsumed, and both attempt to proceed. The atomic transaction ensures that only one succeeds.

The nonce ledger is implemented as a key-value store with the nonce as the key and the consumption timestamp as the value. For performance, consumed nonces are retained for the TTL period (see Layer 2) and then pruned. This prevents the nonce ledger from growing unbounded.

Layer 2: Time-to-Live (TTL)

Every authority token has a TTL: a maximum validity period after which the token expires regardless of whether it has been used. The default TTL is 300 seconds (5 minutes), but it is configurable per policy and per domain.

The TTL serves two purposes. First, it limits the window of opportunity for replay attacks. Even if an attacker somehow bypasses the nonce check, they have at most 5 minutes to use the token. Second, it enables nonce ledger pruning. Once a token's TTL has expired, its nonce can be removed from the ledger because the token would be rejected on TTL grounds anyway.

TTL validation uses server-side timestamps, not client-provided timestamps. The token's issuance time is recorded by Intended at the moment of issuance, and the expiration is calculated server-side at verification time. Clock skew between Intended nodes is handled through NTP synchronization with a maximum acceptable skew of 1 second.

For high-risk actions, the TTL can be reduced to as low as 30 seconds. For low-risk, routine actions, it can be extended to 15 minutes. The TTL is included in the signed token payload, so it cannot be modified without invalidating the signature.

Layer 3: Single-Use Enforcement

The third layer is structural: authority tokens are single-use by design. A token authorizes one specific action on one specific resource at one specific time. The token payload includes the intent ID, the resource identifier, the action type, and the issuance timestamp. All of these are included in the signed payload.

When a token is presented for execution, the enforcement layer verifies that the action being taken matches the action described in the token. If an agent presents a token authorizing "network.firewall.rule.update" but attempts to execute "network.firewall.rule.delete," the token is rejected even though the signature is valid.

Single-use enforcement also prevents scope expansion. A token authorizing an update to firewall rule set "fw-prod-east-01" cannot be used to update firewall rule set "fw-prod-west-01." The resource identifier is part of the signed payload.

After successful execution, the token is marked as consumed in the token ledger. Any subsequent attempt to use the same token is rejected, regardless of whether the nonce has been pruned.

The Token Lifecycle

Understanding replay protection requires understanding the full token lifecycle.

Step 1: An AI agent submits an intent to Intended. The intent is classified by the compiler and evaluated by the Authority Engine. The engine decides to approve the action.

Step 2: Intended generates an authority token. The token payload includes the intent ID, action type, resource identifier, agent ID, issuance timestamp, TTL, nonce, and risk score. The payload is serialized deterministically and signed with Intended's authority signing key.

Step 3: The token is returned to the agent. The agent stores the token temporarily in memory.

Step 4: The agent presents the token to the execution layer (the connector or the target system's Intended integration). The execution layer sends the token to Intended for verification.

Step 5: Intended verifies the token. It checks the signature (is the token authentic and unmodified?), the TTL (has the token expired?), the nonce (has the token been used before?), and the action match (does the requested action match the token's authorized action?). If all checks pass, Intended marks the nonce as consumed and returns a verification success.

Step 6: The execution layer proceeds with the action. The token is now consumed and cannot be used again.

Step 7: The decision, the token, and the execution result are recorded in the hash-chained audit ledger.

Edge Cases and Failure Modes

What happens when things go wrong?

**Token verification service is temporarily unavailable.** The execution layer cannot verify the token. In fail-closed mode (the default), the action is blocked. The agent must request a new authority token when the service recovers. In fail-open mode (configurable for non-critical actions), the action may proceed but is flagged for post-hoc audit.

**Token is valid but execution fails.** The token is consumed even though the action failed. The agent must request a new authority token to retry. This is by design: the governance decision was made, and the audit record should reflect both the authorization and the failed execution.

**Clock skew between Intended nodes.** If node A issues a token at time T and node B checks the TTL at time T + delta, where delta is caused by clock skew rather than real elapsed time, the token might be prematurely expired or improperly extended. NTP synchronization with a 1-second maximum skew tolerance prevents this. Tokens include a 5-second grace period on TTL checks to absorb minor clock variations.

**High-throughput scenarios.** At scale, the nonce ledger becomes a potential bottleneck. Intended partitions the nonce ledger by token prefix, distributing the load across multiple storage nodes. Each partition handles lookups independently, and the atomic consume operation is scoped to a single partition.

Why Three Layers

Any single replay protection mechanism has potential failure modes. Nonces can be bypassed if the nonce ledger experiences data loss. TTLs can be bypassed if the system clock is manipulated. Single-use enforcement can be bypassed if the execution layer fails to report consumption.

Three independent layers mean an attacker must defeat all three mechanisms simultaneously to replay a token. The nonce must not be in the ledger (data loss), the TTL must not have expired (clock manipulation), and the execution layer must not have reported consumption (communication failure). The probability of all three failing simultaneously is vanishingly small.

This is defense in depth applied to token security. Each layer is independently sufficient. Together, they make token replay effectively impossible under any realistic threat model.