The A2A Protocol Changes the Login Handshake: Governing Agents That Manage Agents

Most of the AI agent security conversation so far has been about tool calls: an agent reaches out to an API, reads some data, maybe writes a record. The Agent2Agent protocol (A2A) is quietly expanding the surface that conversation needs to cover. A2A doesn’t just let an agent use a system — it lets one agent discover and drive another agent’s management surface: create collections, wire environments, set policies, provision other agents. That’s not a tool call anymore. That’s an agent doing administration.

Administration by an unattended, instructable piece of software is a different risk than a tool call, and it needs a different handshake — one that authenticates the agent, scopes exactly what it’s allowed to configure, and, critically, draws a hard line around the one thing no agent should ever be allowed to do to its own leash: provision its own credentials.

What A2A actually adds on top of MCP

If you’ve read our earlier post on MCP and OAuth for AI agents, you know the shape of the problem MCP solves: an agent discovers a set of tools and calls them with a scoped bearer token instead of a standing secret. A2A solves an adjacent but different problem. Instead of (or alongside) calling tools inside a fixed collection, an A2A client:

• Fetches an Agent Card — a machine-readable description of what the server can do, served from a well-known URL — to discover the skills on offer.
• Authenticates with its own OAuth client credentials to get a token scoped to a specific account or workspace, not a specific tool call.
• Sends structured message/send requests naming a skill (collection.create, policy.set, principal.create, and so on) and gets back a task result.

In other words: MCP is how an agent uses your systems. A2A, used this way, is how an agent builds and reconfigures your systems — on behalf of a human who pointed it at the account and said “set this up.” That’s an enormous amount of leverage to hand to something that follows instructions exactly as written, including instructions an attacker planted.

The failure mode this actually creates

Picture the obvious “let an agent manage my agent platform” pitch taken literally: a customer points an AI agent at a management API, and the agent builds out collections, policies, environments — the whole configuration — faster than a human could click through a UI. Convenient. Now ask the question every “AI agentic gone wrong” story eventually turns on: what stops that same agent from provisioning its own credentials, granting itself a broader policy, or minting another agent principal with more reach than it was given?

If the answer is “nothing in particular — it has a valid, authenticated token, and provisioning is just another skill in the catalog,” you’ve built a privilege-escalation loop with an API around it. The agent isn’t unauthenticated. It’s authenticated for administration, and administration includes writing the very secrets that are supposed to bound it. A prompt injection, a subtly wrong instruction three hops upstream, or an agent simply doing what its task description said a little too literally is all it takes. This is the same lesson we covered from the tool-call side in when AI agents go wrong: authentication answers who, never what it should be allowed to touch — and for a management surface, “what it’s allowed to touch” has to explicitly exclude the credential layer itself.

What a governed A2A handshake actually requires

Authenticating an A2A client the way you’d authenticate any OAuth client_credentials caller is necessary but not close to sufficient. A management-grade A2A surface needs four properties working together:

• Workspace-scoped tokens, not account-wide ones. A management token should be pinned to one workspace at issuance, tied back to the human who created the client. An agent configuring workspace A should be structurally unable to touch workspace B, no matter what a skill call asks for.
• A skill catalog that is a fence, not a policy note. “The agent shouldn’t create vault secrets” is a governance sentence. It becomes a guarantee only when there is no skill id that maps to that operation at all — not a permission that’s usually denied, but a capability that doesn’t structurally exist for this token kind, checked at more than one layer so a natural-language path can’t talk its way around a structured one.
• Token surface confinement. If the management token is signed by the same issuer as every other token in the system, something has to stop it from being replayed against the general API — including the human-only endpoints — or the carve-out above is cosmetic. The token has to be confined to the one surface it was minted for.
• Per-skill traceability back to a human. Every configuration change an agent makes needs to be attributable to the human who authorized that agent to manage that workspace in the first place — the same chain-of-custody problem we’ve written about for multi-agent traceability, just applied to configuration instead of execution.

Get those four right and “let an agent manage the platform” stops being a blast-radius gamble and becomes a bounded, auditable surface — one where the worst a compromised or misdirected agent can do is scoped to one workspace, excludes the vault entirely, and shows up in a record with your name on it.

The business case: this is what Fullmakt’s own A2A surface enforces

We didn’t write the four requirements above as an abstract wishlist — they’re how Fullmakt’s own Agent2Agent server is built, because we hit the exact question above while building the surface that lets a customer’s agent configure their Fullmakt workspace directly.

• A management OAuth client, created by a human, mirrors exactly how we require a human to provision credentials in the first place: the client is scoped to one workspace and one agent principal, and the plaintext secret is shown once, in the same governance UI where vault clients are created.
• A workspace-scoped management token (kind=mgmt-agent) carries the owning human’s identity and a pinned workspace id, so every skill call reuses the exact same ownership and workspace-access checks the REST API already enforces — an agent can only ever reach what its owner could.
• Vault credential writes have no skill id. vault.createEntry, vault.rotateEntry, vault.deleteEntry, and principal credential bindings are absent from the Agent Card’s skill catalog, absent from the capability enum a skill would need to declare, and denied directly by the authorization gate as a third, independent backstop if a conversational path ever tries to reach them anyway. Setting up a secret stays a human, in the UI, every time — an agent can reference an existing vault entry by name to wire it into a collection, but it can never create, rotate, read, or delete one.
• Token surface confinement middleware rejects a management token outright anywhere but the /a2a endpoint, so the token that lets an agent build out a workspace can’t be replayed against the human-only vault endpoints even if something upstream leaked it.
• Every skill call is audited under the principal, allowed or denied, in the same tamper-evident trail we described in auditing every agent API call — so “what did the management agent configure, and who let it” is a query, not a reconstruction project.

The commercial logic mirrors every other governance investment we’ve made the case for: letting an agent administer your platform is a genuine productivity win, but only if the one operation that would turn a misdirected agent into an unbounded one is structurally off the table, not merely discouraged. That’s the difference between an A2A integration you can hand to an auditor and one you’re hoping nobody stress-tests. See Fullmakt vs. Auth0 for where this sits relative to your identity provider — Fullmakt doesn’t replace your login system; it’s what enforces and evidences what an agent does with the access it’s given, whether that access is a single tool call or an entire workspace.

FAQ

What is the A2A (Agent2Agent) protocol? A2A is a protocol that lets one AI agent discover another system’s capabilities via a machine-readable Agent Card and invoke them as structured “skills” over JSON-RPC, authenticated with OAuth. Unlike MCP, which is typically scoped to calling tools inside one integration, A2A is often used for broader, account- or workspace-level operations — including configuration and administration.

How is A2A different from MCP? MCP standardizes how an agent discovers and calls tools against a specific service. A2A standardizes how one agent (or agentic system) discovers and drives another’s capabilities, which in practice often means management operations — creating resources, setting policy, provisioning other agents — not just data calls. They’re complementary: an A2A skill can itself trigger MCP tool calls underneath.

Why does an A2A management surface need a credential carve-out? Because if provisioning credentials is just another skill in the catalog, an agent with a valid management token can grant itself broader access than it was given — turning a single compromised or misdirected agent into an unbounded one. The fix is making that operation structurally unreachable, not just policy-denied.

Does Fullmakt let an AI agent create or rotate its own credentials? No. Fullmakt’s A2A surface lets an authorized management agent configure collections, policies, environments, and other resources in its owner’s workspace, but vault credential creation, rotation, and deletion have no corresponding skill and are denied at the authorization gate even if requested through a natural-language path. That stays a human action in the UI, always.

Can a management token be used outside the A2A endpoint? No. Fullmakt confines each token kind to its own surface — a management token is rejected everywhere except /a2a, so it can’t be replayed against the general REST API or the human-only vault endpoints even if it leaked.

Agentic AI doesn’t stop at calling tools — it’s already moving into configuring the systems those tools run on. The handshake for that has to be stricter than the one for a data call, not looser, because the blast radius of “misconfigured” is bigger than the blast radius of “one bad request.” Build the credential carve-out into the protocol layer itself, and letting an agent manage an agent platform stops being a leap of faith.