how-to
Implementing Cryptographically Signed Requests for AI Agents
Table of Contents
- Why Cryptographically Signed Requests Matter for AI Agents
- AI Agent Authentication and Authorization Fundamentals
- Setting Up Keys and Establishing Agent Identity
- HMAC Request Signing Example
- Replay Attack Prevention for API Requests
- Building a Cryptographic Audit Trail for AI Agents
- Server-Side Verification and Enforcement
- Common Implementation Mistakes to Avoid
- Frequently Asked Questions
Last Updated: October 10, 2026
Why Cryptographically Signed Requests Matter for AI Agents
Implementing cryptographically signed requests for AI agents is essential when autonomous systems need to execute consequential actions. Without cryptographic proof, there's no way to verify that an agent actually authorized a payment, modified critical data, or triggered a financial transaction. The signature proves three things: the agent's identity, that the request hasn't been tampered with, and that the agent approved it.
Consider a scenario where an AI agent manages enterprise spending. A malicious actor intercepts the request and changes the amount from $1,000 to $100,000. Without signed requests, the system has no way to detect the tampering. With cryptographic signatures, the modified request fails verification immediately.
Cryptographic signatures are the foundation of verifiable agent behavior. They enable organizations to deploy autonomous systems with confidence, knowing that every consequential action carries proof of authorization.
AI Agent Authentication and Authorization Fundamentals
Identity and Trust in Autonomous Systems
An AI agent needs a cryptographic identity before it can sign anything. That identity is built on a keypair: a public key (shared openly) and a private key (kept secret). The agent uses its private key to sign requests. External systems use the public key to verify those signatures came from the agent claiming to send them.
Without this identity layer, there's no way to distinguish between a legitimate agent request and a forged one. Authentication answers the question: Is this really Agent-X? Authorization answers the follow-up: Is Agent-X allowed to do this?
Traditional authentication methods like API tokens are vulnerable to interception. Cryptographic signatures are tamper-proof because they're mathematically bound to the request content. If even one character changes, the signature becomes invalid.
Public and Private Key Roles
The public key is safe to distribute. It's used only for verification. Think of it as a lock that anyone can inspect, they just can't open it. The private key must never leave the agent's secure storage. It's the only thing that can create a signature that the public key will verify.
This asymmetry is powerful. You can publish the public key in a registry or certificate without compromising security. The private key stays protected in a key management system or hardware security module.
When the agent signs a request, it uses its private key. The receiving system looks up the agent's public key and checks whether the signature is valid. If the signature doesn't match, the request is rejected, no exceptions.
Setting Up Keys and Establishing Agent Identity
Choosing Your Signing Algorithm
Ed25519 is a modern standard for agent signing. It's fast, secure, and widely supported across platforms. It produces 64-byte signatures and works well for HTTP request signing.
HMAC (Hash-based Message Authentication Code) is simpler but requires both parties to share a secret key. It's useful when you control both the agent and the verification system. For multi-party scenarios, asymmetric algorithms like Ed25519 are stronger.
RSA signatures are older and slower. They work, but Ed25519 is often preferred for new implementations.
| Algorithm | Key Size | Signature Size | Best For |
|---|---|---|---|
| Ed25519 | 32 bytes | 64 bytes | Modern distributed systems |
| HMAC-SHA256 | Shared secret | 32 bytes | Internal systems with shared secrets |
| RSA-2048 | 2048 bits | 256 bytes | Legacy enterprise systems |
Secure Key Storage and Rotation
Store private keys in a hardware security module or a secrets management service. Never embed them in code or configuration files. Never log them. Never transmit them over unencrypted channels.
Rotate keys periodically, at least annually for production systems. When you rotate, keep the old public key available long enough for in-flight requests to complete verification. Then retire it.
Document which key version signed which requests. This matters for audit trails and forensic analysis if something goes wrong.
HMAC Request Signing Example
Constructing the Canonical Request String
Cryptogrpahic signatures are only valid if both the signing agent and the verifying server construct the request in exactly the same way. A single difference in whitespace, field order, or encoding breaks the signature. This is why canonicalization is non-negotiable.
Define your canonicalization rules explicitly and document them. Here's a production-ready approach:
Step 1: Normalize the HTTP method and path
Replay Attack Prevention for API Requests
Nonce and Timestamp Mechanisms
A replay attack happens when an attacker captures a valid signed request and sends it again. The signature is still valid, it's the exact same request. But you don't want the same action executed twice.
Include a timestamp in the canonical request. The server checks that the timestamp is recent (within the last 60 seconds, for example). Requests older than that are rejected.
For extra protection, include a nonce, a unique, random value that the agent generates for each request. Store nonces you've already seen. Reject any request with a nonce you've processed before.
Request Window Validation
Set a narrow time window for request validity. Sixty seconds is typical. Requests with timestamps outside that window are rejected immediately, before signature verification even happens.
Explore Ecosystem Government Contracting →
This approach is fast and effective. Attackers can't replay old requests because the timestamp will be stale. They can't forge new timestamps because that would break the signature.
Building a Cryptographic Audit Trail for AI Agents
Logging Signed Requests and Verification Results
Log every signed request your agent sends. Include the timestamp, the canonical request string, the signature, and the agent's public key ID. Log the verification result on the server side too: whether the signature was valid, whether the timestamp was in range, whether the nonce was fresh.
This creates an immutable record of what the agent did and whether each action was authorized.
Store logs in a system that prevents tampering. A cryptographic log (one where each entry is signed and linked to previous entries) is ideal. At minimum, use write-once storage and restrict access to authorized auditors.
Proof of Authorization and Action Attribution
When a request succeeds, you have proof that the agent authorized it. The signature is that proof. If there's ever a dispute about whether an action happened or who authorized it, the signed request settles it.
This is especially important in financial contexts. A signed transfer request proves the agent approved the transfer. No one can claim the transfer happened without authorization.
Server-Side Verification and Enforcement
Signature Validation Workflow
When your server receives a signed request, follow this workflow:
- Extract the signature, algorithm, and public key ID from the request headers
- Look up the agent's public key using the key ID
- Reconstruct the canonical request string from the request body
- Verify the signature using the public key and the canonical string
- Check the timestamp is within the allowed window
- Check the nonce hasn't been seen before
- If all checks pass, process the request
- If any check fails, reject the request and log the failure
This workflow is straightforward but critical. Skip any step and you lose protection.
Handling Verification Failures
When a signature doesn't verify, reject the request with a 401 Unauthorized or 403 Forbidden response. Don't process the request. Don't give the attacker any information about why it failed.
Log the failure with full details: the agent ID, the timestamp, the signature, and the canonical request. Include the mismatch details if signature verification failed (though don't expose these to the client).
Alert your security team if verification failures spike. A sudden increase suggests an attack or a misconfiguration.
Common Implementation Mistakes to Avoid
Signing the wrong data. Sign the exact request body the agent intends to send. If you sign a modified version or a hash of the data, the receiver won't be able to verify it. Canonicalize consistently.
Ignoring timestamps. Requests without timestamps are vulnerable to replay attacks. Always include a timestamp and enforce a narrow validity window.
Storing private keys insecurely. Private keys in code repositories, configuration files, or logs are as good as compromised. Use a secrets management system.
Not rotating keys. Old keys accumulate. Rotate annually and retire old keys after a grace period.
Mixing algorithms. Don't use Ed25519 for some requests and HMAC for others. Pick one and stick with it across your system.
Forgetting to log. Signatures are only useful if you record them. Log every request and verification result.
Implementing cryptographically signed requests for AI agents requires discipline but delivers real security. Every signed request carries proof of authorization. Every verification failure gets logged. Every action is attributable to the agent that approved it.
AI Modularity's execution trust ecosystem integrates cryptographic signing into agent verification and authorization workflows. Our A2SPA™ and A2EA™ systems handle request signing and verification at scale. Explore how our ecosystem can secure your autonomous AI deployments.
Frequently Asked Questions
What is a cryptographically signed request for an AI agent?
A cryptographically signed request is an API call made by an AI agent that includes a digital signature proving the request originated from that specific agent and has not been tampered with. The agent signs the request using its private key; the receiving server verifies the signature using the agent's public key. This creates a cryptographic proof that the agent authorized the action, enabling secure autonomous execution without requiring the agent to share secrets with every API endpoint.
How do you prevent replay attacks against signed agent requests?
Replay attack prevention for API requests requires mechanisms such as a timestamp that the server validates against its current time (rejecting requests outside a narrow window), a nonce (one-time number) that the server tracks to reject duplicate requests, and a request ID that the server logs permanently. Together, these ensure that even if an attacker captures a valid signed request, replaying it will be rejected because the timestamp will be stale, the nonce already consumed, or the request ID already recorded in the audit trail.
Should AI agents use HMAC or digital signatures for request authentication?
HMAC (symmetric key) is faster and simpler for point-to-point agent-to-service communication when both parties share a secret. Digital signatures (asymmetric) are often chosen for enterprise deployments because the agent's public key can be distributed widely for verification without exposing the private key, enabling multi-party verification, audit trails, and governance at scale. For financial transactions or compliance-sensitive operations, digital signatures can provide stronger non-repudiation.
How should signing keys be stored and rotated for AI agents?
Store agent private keys in a secrets management system (not in code or configuration files), encrypted at rest, with access restricted to the agent's runtime environment. Implement key rotation by generating new key pairs on a regular schedule, updating the agent's configuration to use the new private key, and publishing the new public key to all verification endpoints. Maintain the previous key for a grace period to handle in-flight requests, then retire it. Log all key rotations in your cryptographic audit trail for compliance and forensics.
