A2A bridge
Configure an A2A bridge behind the P0 AI Gateway so P0-managed agents reach upstream agents under runtime authorization policy.
The A2A bridge component places an upstream agent host behind the P0 AI Gateway so that agent-to-agent (A2A) calls pass through the gateway. Where the MCP server component fronts the MCP servers your agents call, the A2A bridge extends the same governance to A2A traffic.
Prerequisites
An existing P0 account at p0.app.
A registered Gateway component, and the gateway deployed in your environment. See Deploying the P0 AI Gateway.
The base URL where your upstream agents are hosted.
An upstream agent host that accepts tokens minted by your gateway. The gateway calls each agent with a bearer token issued by the gateway's own Auth Server and addressed to that agent's URL, and the host verifies it against the keys published at
<Auth server endpoint>/.well-known/jwks.json. A host that trusts only its own identity provider rejects every call the bridge makes.
Add an A2A bridge
Navigate to Integrations on p0.app and select Agentic gateway, then choose the A2A bridge component.
Click Add A2A bridge.
Enter the bridge details, then finish the configuration:
A2A bridge identifier: a name for this bridge within P0. Use letters, digits, and hyphens only — the identifier becomes part of the gateway address that agents call.
Gateway: the registered gateway that fronts this bridge.
Agent host: the base URL at which your upstream agents are hosted. The gateway routes A2A calls to this URL.
The A2A bridge now appears in the component's list of configured bridges.
How it works
Once a bridge is configured, P0 reconciles it to the gateway alongside your MCP servers. When a P0-managed agent makes an A2A call through the gateway, the gateway verifies the caller's identity, authorizes the call against the policies you define in P0, and logs it before forwarding the call to the Agent host.
The gateway supplies its own credential to the upstream agent host: a natively minted gateway session token. Unlike an MCP server, an A2A bridge has no AWS, GCP, or OAuth credential source to configure.
The agent host must accept and validate this token itself: checking the signature against the Auth Server's published JWKS, and the audience against its own URL. A host that only trusts tokens from its own identity provider rejects every call the bridge makes. See Prerequisites above.
Delegation chain
Every call through the gateway carries a delegation chain. The chain starts with the person or agent who made the first request. It then lists each agent that passed the request along, ending with the agent making the current call.
The gateway stores the chain inside the token it issues at each hop, following the RFC 8693 token exchange standard. The token is signed, so no agent can change the chain. P0 writes each call and its chain to the Event log.
P0 checks policy at two points: at each A2A hop, and when the last agent in the chain calls an MCP tool.
A2A hops
Each call from one agent to another is its own access request. An A2A policy with service: agentic and accessType: agent controls which agent may call which other agent. See Resource and approval for how to write one. This lets you control the path one hop at a time.
An A2A policy can also check the subject, which is the person or agent who started the chain. That way you can treat the same hop differently depending on who started the request.
Actions over MCP
When the last agent in a chain calls an MCP tool, P0 checks the two ends of the chain. These are the person or agent who started the request (the subject) and the agent calling the tool (the actor). Write an agentic access policy for each subject and actor pair you want to control. Its resource and approval settings apply to that pair only. This means:
The last agent can get more or less access than the person or agent who started the chain. The path in between does not change the result.
A chain started by a person can get different access than a chain started by an agent. You can use this to give assistants that people use directly different access than agents that run on their own.
Subject delegation extension
The delegation chain above is enough for P0 to authorize and audit every hop, even when the upstream agent host has no awareness of P0. Some upstream agents need to prove which identity they act for when they make their own next call. Such an agent can declare the A2A subject-delegation extension on its agent card.
A card that declares the extension publishes its own actor_identity (an {iss, sub} pair): the identity the agent presents when it later exchanges a token at the gateway. When the gateway calls an agent that declares the extension, it attaches a signed subject token to the call, scoped with a may_act claim that names only that agent. The agent can redeem the subject token at the gateway's token endpoint, presenting its own federated credential as proof of identity. The gateway nests the agent's identity onto the existing chain and returns a new gateway-issued token the agent can use to call further MCP tools or agents, still carrying the full chain back to the originator.
Agent 2 must redeem the subject token to call tools or agents whose P0 policy requires a subject on the delegation chain. The new token carries the full chain forward, including the original subject. P0 then checks the subject on Agent 2's next call. The signed token proves that Agent 2 is acting on behalf of the original subject.
For agents built with Google's Agent Development Kit (ADK) for TypeScript, P0 provides @p0security/adk-subject-delegation-ts, an SDK that wires up both sides of the extension: extracting an inbound subject token without ever exposing it to the model, and exchanging it for a bearer token on outbound MCP and A2A calls. Contact P0 to access the package.
Next steps
Define the Agentic access policies that govern what agents can do through the bridge.
Learn how an agent requests access to an agent behind the bridge, and the address it calls once access is granted.
Configure the MCP servers you want to expose behind the same gateway.
Last updated