Nonce

The fundamental property of a nonce is that it must be globally unique within its context. A secure implementation uses a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) to produce a value with sufficient entropy, typically 128 bits or more, making the probability of collision statistically negligible.

• Prevents an attacker from reusing a captured nonce.
• Uniqueness must hold for the lifetime of the associated key or session.
• A simple incrementing counter is predictable and often insufficient for distributed agent systems.

A nonce must be strictly single-use. The server or verifying agent must maintain a cache of recently used nonces and reject any request containing a duplicate. This is the active defense against a replay attack.

• The cache window must exceed the request's valid time-to-live (TTL).
• In distributed systems, this requires a shared, low-latency cache like Redis.
• Once a nonce is consumed, it must be immediately invalidated.

A nonce should be cryptographically bound to a timestamp to limit its validity window. This prevents an attacker from storing a valid request and replaying it days later. The combination of a unique random value and a timestamp creates a time-constrained, unique token.

• The server rejects requests where the timestamp deviates beyond an acceptable skew (e.g., ± 30 seconds).
• This reduces the size of the required nonce cache.
• The timestamp must be included in the signed payload to prevent tampering.

A nonce must be scoped to a specific context to prevent cross-context replay. A nonce valid for one agent, tool, or API endpoint must not be valid for another.

• Bind the nonce to the agent_id or session_id.
• Bind the nonce to the specific Tool Access Control List operation being requested.
• This ensures a captured nonce for a read operation cannot be replayed for a destructive write operation.

The nonce alone is not a security guarantee; it must be part of a cryptographic signature or Message Authentication Code (MAC). The nonce, timestamp, and request body are signed with a secret key, creating a request signature.

• This prevents an attacker from modifying the payload while keeping a valid nonce.
• Uses algorithms like HMAC-SHA256 for symmetric integrity.
• The signature is verified by the Policy Enforcement Point before the nonce is checked.

The security of a nonce is entirely dependent on the quality of its entropy source. A weak or predictable pseudo-random number generator (PRNG) undermines uniqueness.

• Use a kernel-level entropy source like /dev/urandom on Linux.
• Avoid seeding a PRNG with predictable values like system time or process ID.
• In a Trusted Execution Environment (TEE), leverage the hardware random number generator (HRNG) for true randomness.