A replay attack is one of the oldest and most reliable techniques in adversarial security: capture a valid, authenticated token from one context and reuse it in another context where it should not apply. The token is genuine. The authentication check passes. The authorization is granted for an action that was not intended.
In AI governance systems, the equivalent attack is straightforward: capture a valid signed governance decision that authorized an action in one session, and resubmit that decision in a later session to authorize a similar action that the current policy would deny.
The signed decision is cryptographically valid. The signature check passes. If the governance layer does not detect replay, the action is authorized under a decision that was made in a different context, under different policy conditions, for a different principal.
Why AI Governance Decisions Are Replay Targets
Governance decisions in modern AI systems are cryptographically signed for verifiability: auditors must be able to confirm that a decision record is authentic and unmodified. This signing creates a usable artifact. A signed governance decision that authorized a specific action type is a bearer token for that action.
The replay threat is highest in three scenarios:
- Policy rollover. An organization tightens its governance policy. Previously issued decisions authorized those action types under the old policy. A replay of a pre-rollover decision grants access under the new policy's terms — the signature is valid, and the action type was previously authorized.
- Cross-session reuse. A user's session is terminated after they are downgraded to a lower-privilege tier. Previously issued decisions that authorized higher-privilege actions remain valid by signature. A replay of a pre-downgrade decision grants elevated access in the new session.
- Cross-tenant injection. In a multi-tenant deployment, a governance decision signed for Tenant A is replayed against Tenant B's audit chain. The decision is genuine. The signature is valid. The policy it was authorized under belongs to a different tenant.
The Defense: Session and Context Binding
The defense against replay attacks is binding the governance decision not just to the action it authorized but to the full context in which it was authorized. A decision that is valid only within its original context cannot be replayed into a different context.
The minimal binding context for replay-resistance includes four components:
- Session identifier. The decision is bound to the session ID in which it was made. A decision from Session A cannot authorize actions in Session B, even for the same principal and action type.
- Policy version hash. The decision embeds the hash of the policy version that authorized it. If the policy has changed since the decision was made, the embedded version hash does not match the current policy, and the decision is expired.
- Monotonic sequence number. Each session maintains a monotonically increasing sequence counter. Governance decisions embed the expected next sequence number. A replayed decision will have a sequence number that does not match the current session's next-expected counter, making it detectable as out-of-sequence.
- Principal binding. The decision embeds the principal identifier it was issued for. Replaying a decision against a different principal fails the binding check.
With all four binding parameters embedded in the signed payload, a replayed decision fails at least one binding check — and the failure is logged in the audit chain as a replay detection event.
Replays in the Audit Chain
A replay detection event is itself valuable audit evidence. It shows that a replay was attempted, the original decision's session, principal, and policy version, the context in which replay was attempted, and the binding check that failed.
An audit chain that never contains replay detection events is not evidence that replay was never attempted. It is evidence that either replay was never attempted or the governance layer is not detecting it. These are very different compliance postures.
Best practice: Enterprise governance deployments should periodically verify replay detection by intentionally replaying known-expired decisions against the governance layer and confirming that replay detection events appear in the audit chain.
Chain-Level Replay Resistance
Beyond individual decision binding, the audit chain itself must be replay-resistant. A well-formed attack does not replay individual decisions — it replays entire chain segments: submitting a valid historical chain segment as if it represents the current state, hiding the records produced since the segment was captured.
Chain-level replay resistance requires three properties:
- External anchoring. The chain head hash is published to an external, immutable source at regular intervals. A replayed chain segment that does not match the most recent published anchor is detectable as substituted historical state.
- Monotonic chain sequence. Each chain record embeds a monotonically increasing global sequence number. A replayed segment that jumps sequence numbers is immediately detectable.
- Temporal binding. Chain records embed wall-clock timestamps that must fall within plausible ranges. A replayed segment with timestamps that predate the expected current range is detectable as historical state.
The Compliance Case
Replay attack detection is not just a security property — it is a compliance property. A governance audit that cannot distinguish between genuine decisions and replayed historical decisions cannot produce reliable findings. An audit chain that is replay-resistant provides auditors with the guarantee that every record reflects a decision made in its claimed context, under its claimed policy, for its claimed principal.
The difference between a governance system that is replay-resistant and one that is not is the difference between an audit trail that is admissible evidence and one that is not.
Replay resistance is not achievable through policy. A policy document stating "governance decisions must not be reused across sessions" has no enforcement mechanism. The enforcement mechanism is session binding, policy-version hashing, monotonic sequence counters, and principal binding — infrastructure that makes replay detectable at verification time, without depending on the integrity of any individual actor.
A vendor that cannot describe the replay-resistance properties of their governance decisions in these terms has not built infrastructure. They have built documentation. The distinction matters because documentation can be circumvented. Infrastructure produces the evidence that it was not.