credential
API key auth
A static API key. Whoever holds the string is 'authenticated' as whatever it was provisioned for.
a2a cloud
A short-lived Ed25519-signed token that proves identity and expires by TTL.
API keys aren't enough
AI agent authentication that proves who's calling.
A shared static key often loses caller context. a2a cloud provides account-bound Agent API authentication, short-lived signed grants for delegation, and conservative caller classifications on public ingress. Public routes do not pretend an anonymous or externally authenticated caller is a verified platform user.
signed tokens · verifiable identity · no ambient trust
0
signed execution entry points
0
OAuth to build
static keys required
the problem
A shared key authenticates a secret, not an agent.
Most agent deployments authenticate with a static API key: a bearer string that grants whatever it was provisioned for to whoever holds it. It has no identity, so the runtime can't distinguish the user from the agent from the agent acting on the user's behalf. It has no expiry, so it lingers in env vars and configs until someone rotates it. And building anything better usually means standing up an identity provider and implementing OAuth before your agent serves its first real request.
A static key has no identity — user, agent, and agent-for-user are indistinguishable to the runtime.
Bearer keys don't expire on their own; they linger in configs and logs until manually rotated.
Authentication and authorization collapse into one secret: holding it grants everything.
Doing it properly means integrating an IdP and building OAuth flows before v1 ships.
the a2a way
Managed auth on deploy. Identity, not secrets.
a2a cloud makes authentication a platform primitive: Agent API calls bind account identity, delegation uses signed scoped grants, and public ingress records only the caller classification it can verify.
Authenticated on deployShort-lived signed tokensIdentity, not just a keyAuthentication meets authorizationNo OAuth to buildEvery auth decision is on the receipt
Authenticated on deploy
The control-plane Agent API uses account or token authentication, and hosted MCP/A2A/HTTP surfaces apply the agent's configured visibility and auth model. Public agents intentionally allow direct ingress; private agents are not routed through the public gateway.
Short-lived signed tokens
Callers present Ed25519-signed tokens with a bounded lifetime, not a static secret. A token that leaks is worthless minutes later — authentication that expires instead of lingering in a config file.
Identity, not just a key
Agent API receipts bind `user:{id}`. Direct gateway receipts deliberately use conservative `anonymous`, `credential-present`, or verified grant-issuer classifications rather than asserting a human identity the gateway cannot prove.
Authentication meets authorization
Supported grant-backed operations can bind audience, TTL, and file or tool scope after authentication. Separately configured agent secrets and local process access remain outside that grant boundary.
No OAuth to build
Token issuance, verification, rotation, and revocation are platform primitives. You don't integrate an IdP, implement OAuth flows, or run a key-management scheme to authenticate callers.
Every auth decision is on the receipt
Agent API receipts bind `user:{id}` and verified grant IDs. Public `/invoke` and standard MCP gateway receipts use conservative `anonymous`, `credential-present`, or verified grant-issuer caller classifications rather than asserting a platform user.
side-by-side
Static API keys vs. signed-token auth.
identity
API key auth
A shared key has no notion of who is calling — user, agent, or agent-for-user are indistinguishable.
a2a cloud
Agent API binds a user; direct ingress records only the caller classification it can verify.
authorization
API key auth
Authentication and authorization collapse into one key: proving you hold it grants everything.
a2a cloud
Supported operations can combine authentication with an audience-, TTL-, file-, and tool-scoped grant.
building it
API key auth
Stand up an IdP, implement OAuth, and run token rotation and revocation yourself.
a2a cloud
Managed auth on deploy — issuance, verification, and rotation are platform primitives.
evidence
API key auth
Who authenticated and under what authority rarely makes it into a durable, provable record.
a2a cloud
Receipts record the Agent API user or conservative gateway classification and the grants that authorized it.
dimension
API key auth
a2a cloud
credential
A static API key. Whoever holds the string is 'authenticated' as whatever it was provisioned for.
A short-lived Ed25519-signed token that proves identity and expires by TTL.
identity
A shared key has no notion of who is calling — user, agent, or agent-for-user are indistinguishable.
Agent API binds a user; direct ingress records only the caller classification it can verify.
authorization
Authentication and authorization collapse into one key: proving you hold it grants everything.
Supported operations can combine authentication with an audience-, TTL-, file-, and tool-scoped grant.
building it
Stand up an IdP, implement OAuth, and run token rotation and revocation yourself.
Managed auth on deploy — issuance, verification, and rotation are platform primitives.
evidence
Who authenticated and under what authority rarely makes it into a durable, provable record.
Receipts record the Agent API user or conservative gateway classification and the grants that authorized it.
questions
Frequently asked.
How does AI agent authentication work on a2a cloud?
Callers can authenticate with short-lived signed tokens rather than static API keys. The Agent API binds receipts to `user:{id}`; direct public `/invoke` and standard MCP ingress use conservative `anonymous`, `credential-present`, or verified grant-issuer caller classifications. Scoped grants bind audience, TTL, tools, and files.
Why aren't API keys enough to authenticate an agent?
A static API key is a bearer secret with no identity and no expiry: whoever holds the string is treated as authenticated, with whatever access it was provisioned for, until it's rotated. It can't tell whether the user, the agent, or the agent acting for the user is calling. Short-lived signed tokens plus scoped grants give you verifiable identity, a bounded lifetime, and least-privilege authorization instead.
Do I have to build OAuth or run an identity provider?
No. Token issuance, verification, rotation, and revocation are platform primitives on a2a cloud. Your agent's endpoints are authenticated on deploy without you integrating an IdP, implementing OAuth flows, or maintaining a key-management scheme — managed auth is part of the deploy, not a separate project.
What's the difference between authentication and scoped grants here?
Authentication identifies a caller; a scoped grant defines authority for supported grant-backed operations. Agent API callers bind to platform users, while public gateway callers may remain anonymous or credential-present classifications. Grants do not replace separately configured database, provider, or upstream credentials inside the hosted agent process.
Can I prove which caller was authenticated for an action?
Yes. Agent API receipts bind `user:{id}`; public `/invoke` and standard MCP receipts use conservative caller classifications. Receipts record the grants that authorized the call. Formal A2A routes and connector MCP jobs are outside coverage.
keep reading
Related guides.
All guides live in the guides index.
prove the caller, scope the authority
Authenticate agents the right way.
a2a cloud deploys any agent with signed tokens and scoped grants. Agent API receipts bind `user:{id}`; public `/invoke` and standard MCP receipts use conservative caller classifications. Receipts include the grants that authorized the call.