You authorise an AI agent to book a service on your behalf. The agent makes an API call to the service provider. The provider receives the request. Who—or what—is knocking at its digital door? The request carries your user token, but you did not make it. A piece of software, acting under your broad authorisation, did. The provider must decide: is this a legitimate, authorised agent acting within its remit, or a malicious imposter spoofing an agent’s identity to commit fraud? This is the core problem of verifying an entity you cannot see, one that moves and decides autonomously.
The common assumption is that a user token is enough; the real risk is that without a distinct, verifiable identity for the agent itself, you cannot trace malfeasance, enforce policy, or stop spoofing. You lose the chain of accountability. This moves beyond the basic concept of non-human identities explained. An AI agent is not a simple service account. It is an adaptive, context-aware executor that can make a series of decisions across different domains.
Its actions can have the scale and impact of a new kind of insider, but one whose provenance is murky. When that agent interacts with another service, you face a fundamental authentication gap. How do you prove an agent is who it claims to be, and that it is authorised to do what it is attempting?
The authentication gap for autonomous actors
Traditional API authentication answers the question "is this request allowed for this user?". It does not answer "what is the nature of the entity making this request?". A user access token, OAuth flow, or API key grants a bearer certain privileges. When the bearer is a human at a keyboard, the model works. When the bearer is an autonomous AI agent, the model breaks.
Picture a scenario where your agent is authorised to negotiate and sign contracts up to a certain value. It contacts a vendor's system. The vendor sees a valid token from your organisation and approves the contract. Later, a dispute arises. You claim the agent exceeded its mandate. The vendor claims it dealt with your authorised representative. Who is liable?
Without a cryptographically verifiable signature from a specific, known agent instance, tied to a clear policy, you have only your word against the vendor's logs. Those logs show a valid token was used. The agent's actions are invisible; its identity is subsumed into your user account. This gap creates two primary risks.
First, agent spoofing: a malicious actor could forge API calls that perfectly mimic an authorised agent's traffic, using a stolen or leaked user token. The target system cannot distinguish between your legitimate agent and a forger. Second, agent repudiation: you cannot reliably prove which specific agent instance performed an action, making it impossible to audit behaviour, isolate compromised agents, or hold specific deployments accountable.
The principle of cryptographic provenance
The solution lies in shifting from authenticating only the user's privileges to also verifying the agent's provenance. Every API call from an agent should carry a cryptographic proof of its source identity. This is not about the user's identity, but the agent's own identity as a delegated actor.
Think of it as a digital seal. The agent, when instantiated, is issued a unique credential—a form of certificate or signed attestation. This credential binds a public key to a set of agent metadata: its creator, its owner, its purpose, its version, and the policy scope of its authority. For every outbound request, the agent signs a portion of the request data (or a hash thereof) with its private key.
The receiving service can then verify this signature against the agent's public credential. It answers: "This request was cryptographically signed by an agent with this specific identity, which is authorised by this user/organisation." This moves the trust anchor. You no longer trust only the bearer token; you also trust the verifiable chain from the agent's signature back to its issued credential.
A spoofed request without the correct private key will fail verification, even if the user token is valid. This principle of cryptographic provenance turns the invisible agent into a accountable entity.
Designing credentials for non-human agents
What form should these agent credentials take? They must be machine-readable, verifiable without constant online checks to the issuing authority, and capable of encoding rich metadata. X.509 certificates are one candidate, extended with custom fields for agent-specific attributes. Another is the use of Verifiable Credentials, a W3C standard designed for portable, cryptographic claims.
A third, simpler model is a signed JSON Web Token (JWT) issued by an identity provider that both the agent's owner and the relying party trust. The credential must include, at minimum: Issuer: Who created and attests to this agent's identity. Subject: A unique identifier for this agent instance. Public Key: For verifying the agent's signatures.
Policy Scope: A machine-readable definition of what this agent is authorised to do (e.g., "can book meetings, cannot transfer funds"). Validity Period: A short lifespan to limit the impact of credential compromise. The issuing process is critical. It should be a distinct step from user authentication.
When you deploy an agent, you request a credential for it from your identity provider. This provider validates the agent's code or deployment against your organisational policies before minting the credential. This creates an audit trail: the birth of an agent identity is logged.
Integrating verification into API handshakes
For this to work, the verification must be a standard part of the API transaction. The agent includes its credential and a signature in a standard HTTP header, like X-Agent-Authorization. The receiving service's first action is to validate the user token and the agent signature.
The verification flow is: Extract the agent credential and signature from the request. Validate the credential's signature chain, ensuring it was issued by a trusted authority and is not revoked. Verify the request signature matches the public key in the credential.
Parse the policy scope from the credential and evaluate if the current request falls within those bounds. Proceed with the user token authorisation for the final access decision. This adds a layer of defence-in-depth. A revoked agent credential will fail at step two, even if the user account is still active.
An agent attempting an action outside its policy scope (e.g., transferring money when it is only authorised for data lookup) is blocked at step four. This architecture is essential for scenarios where AI agents operate in a chain of delegation, as each link in the chain can verify the one before it.
The new accountability stack
Adopting verifiable agent identities changes your security and operational model. You gain a new layer in your accountability stack. Forensics become precise. Instead of logs showing "user X performed action Y," you see "agent instance A, owned by user X, performing action Y."
You can trace anomalous behaviour to a specific agent deployment, isolate it, and investigate whether it was compromised, buggy, or operating on malicious instructions. Policy enforcement becomes granular. You can define policies at the agent level ("trading agents cannot operate after hours") and know they are cryptographically enforced at the point of action, not just hoped for at the point of deployment.
Trust becomes transitive. A third party can choose to trust requests from your verifiable agents without needing full access to your internal systems. They can audit the agent credentials and their policies, accepting them as a form of certified delegate. This enables new business models and automations where trust in the autonomous actor is explicit.
This approach complements, rather than replaces, methods for proving identity online without biometrics. It applies those principles of cryptographic proof to the non-human domain. The agent's credential is its passport, its signature its visa stamp for each border crossing.
Questions people ask
How is this different from just using API keys?
An API key is a shared secret that authenticates the client, not the actor. If an AI agent uses an API key, any piece of software with that key can impersonate it. An agent credential uses asymmetric cryptography (public/private keys). The private key signs requests and never leaves the agent's secure environment.
The public key, in the credential, is used for verification. This means you can prove a specific agent made a request, not just any holder of a secret.
Doesn't this just move the problem to securing the agent's private key?
Yes, and that is the correct place for the problem. The private key should be secured in a hardware-backed enclave or a managed secrets service where the agent runs. The compromise surface is reduced to the specific agent instance, not the entire user account.
If a key is compromised, you revoke that single agent credential, not all of the user's access. It enables precise containment.
Can't attackers just steal the credential and sign their own requests?
They can steal the public credential, but it is useless without the corresponding private key to sign requests. The credential is meant to be public, like a passport. Its value is in being verifiably signed by a trusted issuer.
An attacker cannot forge a valid credential without compromising the issuer's signing key. That is a far higher-tier attack and would be catastrophic for all issued agents, triggering a mass revocation.
Is this practical for all types of AI agents?
For simple, single-function scripts, it may be overkill. For any agent that makes consequential decisions, interacts with external parties, or handles sensitive data, it is a necessary control.
The infrastructure to issue and verify these credentials needs to be built into agent platforms and API gateways. The trend is toward this model for any autonomous software that acts with delegated authority.
Close
The invisibility of AI agents is their greatest operational risk. As they act, they leave a shadow that traditional authentication cannot illuminate. By insisting on cryptographic verification of agent identity, you force that shadow into the light. You transform the agent from an anonymous bearer of your token into a named, accountable entity with a verifiable seal.
This is not a speculative future requirement. It is the foundational missing piece for safe, large-scale agent deployment. The design work starts now: defining the credential formats, building the issuance authorities, and updating API gateways to demand proof of provenance. When you cannot see who is acting, you must be able to verify who they claim to be. That verification, bound in cryptography, becomes the new basis for trust in automated transactions.