the credential
shared API key
A shared API key: a long-lived secret that grants standing access to everything behind it.
scoped grant
A scoped grant: a signed token carrying its own bounded authority, not a secret to protect.
eliminate keys, don't rotate them
Scoped grants for AI agents, not shared keys.
An agent with a shared API key holds standing, all-or-nothing access to everything behind it, long after the task that needed it is done. a2a cloud replaces the key with a scoped grant: an Ed25519 token that binds an audience, a TTL, and the exact files and tools it unlocks. The fix isn't rotating keys faster. It's removing the key.
audience · TTL · file + tool scope · no ambient trust
0%
agents over-privileged
0
secrets leaked 2025 (M)
standing access granted
the problem
The shared API key is the vulnerability, not the leak.
Give an agent an API key and you've given it standing, all-or-nothing access that outlives every task it was minted for. Keys sprawl into env vars, config files, and repos. Rotation is a treadmill — you're always one forgotten key behind. The problem isn't that keys leak. It's that a leaked key grants everything.
A shared key is all-or-nothing: the agent inherits every permission the key was ever given.
Keys are long-lived and sprawl into logs, env vars, and repos where they quietly leak.
An agent with a shared key holds far more access than its work ever needs.
Rotation is reactive and perpetual; you find out a key leaked after it's already been used.
the a2a way
Mint authority per task. Bind it. Expire it.
On a2a cloud, authority is a scoped grant — a cheap-to-mint Ed25519 token issued at the moment of need, carrying exactly the scope the task requires and nothing more. Scoped authority, no standing access.
A grant is not a keyAudience-boundTime-boxed by TTLFile and tool scopedBound into the receiptMinted per task, not per app
A grant is not a key
A scoped grant is an Ed25519-signed permission token, not a secret to guard. It carries its own authority — audience, TTL, and the exact tools and files it unlocks — so there's nothing to leak that grants standing access.
Audience-bound
A grant names the agent it was minted for. Present it to a different audience and it's rejected. A stolen grant can't be replayed against a service it was never issued to.
Time-boxed by TTL
Every grant expires. Authority is a bounded window measured in minutes, not a key that lives in an env var until someone remembers to rotate it — which is usually never.
File and tool scoped
A grant enumerates exactly which tools it may call and which files it may touch. An agent that needs to read one file and call one tool gets precisely that — least privilege by construction, not by policy doc.
Bound into the receipt
Receipts from Agent API, public `/invoke`, and standard MCP `tools/call` executions record the grants that authorized it. The referenced grant carries audience, TTL, and scope; formal A2A message/task routes remain protocol state.
Minted per task, not per app
Grants are cheap to mint, so authority is issued per task at the moment of need. The agent holds narrow, short-lived authority for the job in front of it — never the broad, permanent access a shared key hands out.
side-by-side
Shared keys vs. scoped grants.
scope
shared API key
One key, all-or-nothing. The agent gets every permission the key was ever provisioned with.
scoped grant
Audience, TTL, and an explicit file and tool allowlist — exactly the authority the task needs.
lifetime
shared API key
Keys live until someone rotates them. In practice they outlive the project and leak into logs and repos.
scoped grant
Grants expire by TTL. Leaked authority is dead within minutes, not indefinitely valid.
if it leaks
shared API key
A leaked key is full standing access until detected and rotated — the basis of most breaches.
scoped grant
A leaked grant is scoped, audience-bound, and expiring — its blast radius is a sliver.
provability
shared API key
Logs rarely record which key authorized an action, so you can't prove the authority behind it.
scoped grant
The signed receipt binds the grant to the action — provable scoped authority per run.
dimension
shared API key
scoped grant
the credential
A shared API key: a long-lived secret that grants standing access to everything behind it.
A scoped grant: a signed token carrying its own bounded authority, not a secret to protect.
scope
One key, all-or-nothing. The agent gets every permission the key was ever provisioned with.
Audience, TTL, and an explicit file and tool allowlist — exactly the authority the task needs.
lifetime
Keys live until someone rotates them. In practice they outlive the project and leak into logs and repos.
Grants expire by TTL. Leaked authority is dead within minutes, not indefinitely valid.
if it leaks
A leaked key is full standing access until detected and rotated — the basis of most breaches.
A leaked grant is scoped, audience-bound, and expiring — its blast radius is a sliver.
provability
Logs rarely record which key authorized an action, so you can't prove the authority behind it.
The signed receipt binds the grant to the action — provable scoped authority per run.
questions
Frequently asked.
What are scoped grants for AI agents?
A scoped grant is an Ed25519-signed permission token that binds an audience, a TTL, and an explicit file and tool scope. Instead of handing an agent a shared API key with standing access, you mint a grant that permits exactly the tools and files the task requires, for a bounded window. It's least privilege enforced cryptographically, with no ambient trust.
Why stop giving agents API keys?
A shared API key is a long-lived secret with all-or-nothing, standing access. Rotation is a treadmill you always fall behind on. Scoped grants remove the key entirely: a leaked grant is audience-bound, tool-scoped, and expiring, so there's little to steal and less to lose.
How is a scoped grant different from a short-lived API key?
A short-lived key is still a secret with whatever scope it was provisioned with — it just expires sooner. A scoped grant carries its authority explicitly: it names its audience, enumerates the exact tools and files it unlocks, and expires by TTL. The reframe is eliminating keys, not rotating them faster.
How do scoped grants enforce least privilege?
Each grant enumerates the specific tools it may invoke and the specific files it may touch, bound to one audience for one bounded window. An agent that needs one read tool receives authority for that tool only — not the write tools beside it. Least privilege is a property of the token, not a policy someone hopes is being followed.
Can I prove which authority an agent acted under?
For Agent API, public `/invoke`, and standard MCP `tools/call` executions, the receipt includes verified grant IDs alongside caller, skill, input hash and result preview, outcome/result preview, and timing. Optional tool, file, artifact, handoff, and evaluation fields are not populated by default.
keep reading
Related guides.
All guides live in the guides index.
no ambient trust
Give agents scope, not keys.
a2a cloud governs agents with scoped grants instead of shared keys. Agent API, public `/invoke`, and standard MCP `tools/call` receipts record the grants that authorized it; the referenced grants hold audience, TTL, file, and tool scope. Managed Postgres, MCP, API, and auth ship with the deploy.