Authorizing Time: Order, Staleness & Replay

Most discussions of agent authority stop at what an agent may do and who it may do it for. But every permission also lives in time, and time is where a surprising number of attacks live too. A request that was legitimate a minute ago can be captured and replayed. A grant that was valid before you revoked it can still be sitting in a queue. Two actions that are each authorized can do damage if they arrive in the wrong order. Authorizing time means treating when a request is valid as seriously as what it is allowed to do — because an agent that ignores order, staleness, and replay can be steered entirely with permissions that were, at some point, perfectly real.

Why time is part of authority

A permission is usually written as a static fact: this actor may perform this action on this resource. That framing quietly assumes the request happens once, now, in the order intended. Agents break all three assumptions. They operate through queues and retries, across networks that reorder and duplicate messages, and against systems whose state changes between the moment a grant is issued and the moment it is used.

So authority has a fourth dimension beyond actor, action, and resource: time. A grant needs to say not just what is allowed but when it is valid, in what order relative to other actions, and how to tell a genuine first use from a replayed copy. Ignore that dimension and you have built a system that can be driven by yesterday's valid requests.

Three ways time betrays you

It helps to separate the failures, because they need different defenses. Replay is the reuse of a genuine request: an attacker captures a valid, signed action and sends it again. Staleness is the use of authority after its moment has passed: a grant that was valid is exercised too late, after conditions changed. Ordering is the execution of authorized actions in a sequence that was never intended, where each step is fine but their arrangement is not.

None of these require forging anything. That is what makes them dangerous — the requests are real, the signatures check out, the permissions existed. The defense is not stronger authentication; it is teaching the system to care about when.

Replay — a genuine request captured and sent again.
Staleness — valid authority exercised after its moment has passed.
Ordering — authorized actions executed in an unintended sequence.

Replay: the same proof, used twice

A replayed request is indistinguishable from the original by content alone — same payload, same valid signature. The only thing that separates a first use from a copy is a shared memory that this exact request has been seen before. The classic defense is a nonce — a number used once — that the server issues as a fresh challenge and refuses to accept twice.

The loop is simple and worth internalizing. The server hands out a one-time challenge; the agent binds its request to that challenge and signs it; the server verifies the signature and checks the challenge has not been spent; then it burns the challenge so the same request can never be replayed. Idempotency keys achieve a related effect for retries — the same operation submitted twice is executed once.

A one-time challenge, bound into the request and then spent, makes a captured copy worthless.

Staleness: authority that outlived its moment

Even without an attacker, authority decays. A grant minted for a decision made at noon should not still be acting at midnight. Between issue and use, the account balance changed, the user revoked consent, the risk score climbed — and a request carrying old authority arrives as if none of that happened. Staleness is authority that is technically valid but no longer appropriate.

The defense is to treat freshness as a spectrum with an explicit cutoff. A request carries a timestamp or a short time-to-live; the resource measures how old it is and rejects anything past the line. The tighter the window, the smaller the gap in which stale authority can act — at the cost of more frequent re-authorization. Where you draw the cutoff is a real design decision, not a default.

A request's authority ages along a track; past the cutoff, it must be rejected.

Order: actions that must not commute

Some sequences of authorized actions are safe in one order and harmful in another. Consider a grant that is issued, used, and then revoked because something looked wrong — and a replayed or delayed copy of the action that arrives after the revocation. Each event is individually legitimate; the danger is entirely in the arrangement. A system that does not reason about order will happily apply the late action as though the revocation never happened.

Defending order means giving the system a sense of sequence: monotonic counters or sequence numbers that only ever increase, causal references that say this action assumes that prior state, and a rule that a revocation is final against anything issued before it. The point is to make when relative to other events a thing the resource checks, not a thing it hopes about.

A grant's life in time — a replay that arrives after revocation must be rejected on order alone.

A freshness budget per action

Not every action deserves the same tolerance for age. Reading a public document can accept a generous window; moving money or changing permissions should demand near-immediate freshness. Thinking of it as a freshness budget makes the trade-off explicit: high-risk actions spend their budget fast and must be re-authorized often, while low-risk ones can coast.

This connects time back to the rest of authority. An intent-bound grant already names the action and its risk; the freshness budget attaches a matching clock. The riskier the action, the smaller the window in which a captured or delayed request can still be honored — and the less any single stale credential is worth.

Riskier actions get a tighter freshness window, so stale authority is honored for less time.

Where time defenses fail

Time defenses have their own failure modes, and they are easy to get subtly wrong. Clock skew between systems can make a fresh request look stale or a stale one look fresh, so windows must tolerate realistic drift without becoming meaningless. Nonce checks fail silently if the store of spent nonces is not shared across every server that might accept a request. And a freshness window set generously for convenience quietly re-opens the staleness gap it was meant to close.

The tie to agent risk is direct. Prompt injection and tool-result poisoning often try to get an agent to re-submit a captured action, act on a grant that should have expired, or apply steps out of order. Replay defenses, freshness cutoffs, and ordering rules are what make those attempts fail even though the underlying request is genuine. Treat a missing nonce store or an unbounded window as a vulnerability, not a tuning detail.

⚠️

Skew and shared state. A nonce check is only as good as the shared store behind it, and a freshness window is only as good as the clock agreement beneath it.

What builders and leaders decide

For engineers, authorizing time turns into concrete mechanisms: one-time challenges or idempotency keys against replay, short time-to-live and timestamp checks against staleness, and sequence numbers or causal rules against reordering — with a revocation that is final. These are not exotic; they are the same primitives distributed systems have long used, applied deliberately to authority.

For leaders, the value is that authority cannot be quietly reused. A stolen or delayed request has a short shelf life, a revoked grant is genuinely dead, and the order of consequential actions is enforced rather than assumed. In a world where agents act through queues and retries at machine speed, that is the difference between a bounded incident and one that replays itself indefinitely.

Use one-time challenges or idempotency keys so a captured request cannot be replayed.
Attach short time-to-live and timestamp checks; size the window to the action's risk.
Enforce order with sequence numbers or causal references, and make revocation final.
Share nonce state across servers and tolerate realistic clock skew without widening the window.

Key takeaways

Authority has a time dimension: when a request is valid matters as much as what it permits.
Replay, staleness, and ordering are attacks that use genuine requests — stronger authentication does not stop them.
Defeat replay with one-time nonces or idempotency keys that are checked against shared state.
Treat freshness as a spectrum with an explicit cutoff, and size the window to the action's risk.
Enforce ordering with sequence numbers and causal rules, and make revocation final against anything issued earlier.
Clock skew and unshared nonce stores are the quiet failure modes that re-open the gaps these defenses close.

Glossary

Replay attack: Capturing a genuine, valid request and sending it again to trigger the action a second time.
Nonce: A number used once — a fresh challenge that a server accepts a single time to bind a request to this moment.
Idempotency key: A token that lets the same operation be submitted more than once but executed only once.
Staleness: The use of authority after its moment has passed, when it is technically valid but no longer appropriate.
Time-to-live (TTL): A short lifetime after which a request or grant is considered expired and must be rejected.
Ordering: The requirement that authorized actions execute in an intended sequence, since arrangement alone can cause harm.
Sequence number: A monotonic counter that only increases, used to detect and reject out-of-order or duplicated actions.
Clock skew: The difference between clocks on separate systems, which time-based checks must tolerate without becoming meaningless.