Skip to main content

Replay and Tampering Resistance

The attacks​

Replay attack: An attacker captures a valid authorization artifact (an approval, a dispatch request) and reuses it to authorize a different or duplicate action.

Tampering attack: An attacker intercepts an authorization artifact and modifies its parameters (change the URL, change the node ID, change the expiry) before it reaches the verifier.

These attacks are particularly relevant to AI systems because authorization artifacts pass through multiple services and may traverse untrusted networks.

Defense: execution intents​

Every authorized action is represented as a signed execution intent containing:

  • A cryptographic signature over all intent fields. HMAC-SHA256 is the current compatibility path; ECDSA P-256 support exists in the executor SDK for asymmetric rollout.
  • A payload hash — a SHA-256 fingerprint of the action parameters
  • An expiration time
  • An idempotency key

Against tampering: Changing any field in the intent — including the parameters — changes the payload hash. The execution manager recomputes the expected hash and rejects any request where they don't match. Changing the signature field directly is impossible without the signing key.

Against replay: The idempotency key is recorded on first successful execution. A duplicate intent with the same idempotency key is recognized and rejected. Track A added durable consumed-set storage so replay protection can survive service restarts when the relevant replay store directory is configured.

Against stale reuse: The expiration time is part of the signed payload. An expired intent cannot be used to authorize execution.

Defense: approval artifacts​

Approval artifacts include:

  • A cryptographic signature
  • The specific intent ID and payload hash they approve
  • An expiration time
  • A nonce — a unique one-time value

Against transfer: The approval artifact names the specific intent ID and payload hash. An approval for "fetch URL A" cannot authorize "fetch URL B" — the payload hashes differ.

Against replay: The nonce is consumed on first use. The same approval artifact cannot authorize two executions.

Against stale reuse: Approval artifacts expire independently of the intent (default: 15 minutes).

Against forgery: The signature covers the nonce as a committed field. Swapping the nonce in a captured artifact without recalculating the signature produces an invalid artifact.

Defense: dispatch artifacts​

Remote dispatch requests (node-to-node) include:

  • A dispatch nonce — a unique one-time value generated per dispatch
  • A dispatch payload hash — covering the intent payload hash, artifact ID, node ID, dispatch ID, and expiry

Against replay: The node agent records all consumed dispatch nonces. A repeated dispatch nonce is rejected with DISPATCH_NONCE_REPLAYED.

Against redirection: The node ID is covered by the payload hash. A dispatch intended for node A cannot be redirected to node B — the hash would be invalid.

Against parameter modification: Any change to the dispatch parameters invalidates the payload hash.

The verification chain​

Orchestrator issues execution intent
         │  (signature + payload hash + expiry + idempotency)
         ▼
Execution Manager verifies intent
         │  (checks signature, hash, expiry, idempotency)
         ▼
[if approval required] Verifies approval artifact
         │  (checks signature, intentId match, hash match, expiry, nonce)
         ▼
[if remote dispatch] Node Manager creates dispatch artifact
         │  (dispatch nonce + dispatch payload hash)
         ▼
Node Agent verifies dispatch artifact
         │  (checks nonce not seen, hash matches)
         ▼
Execution proceeds

Each step verifies independently. Compromise of one step does not compromise the others.

Current signing status​

HMAC signing is still the default service path. ECDSA P-256 helpers are implemented in the executor SDK so deployments can move toward a stronger model where orchestrator and approval-service hold private keys while execution-manager and node-agent hold only public keys. That service-wide key wiring remains a production-hardening follow-up.