> For the complete documentation index, see [llms.txt](https://docs.p0.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.p0.dev/agentic-access/agentic-gateway/a2a-bridge.md).

# 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 [AI gateway](/agentic-access/agentic-gateway.md) so that agent-to-agent (A2A) calls pass through the gateway. Where the [MCP server](/agentic-access/agentic-gateway/mcp-server.md) 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](https://p0.app/).
* A registered [Gateway](/agentic-access/agentic-gateway/gateway.md) component, and the gateway deployed in your environment. See [Deploying the gateway](/agentic-access/agentic-gateway/gateway/deploy.md).
* 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

1. Navigate to **Integrations** on [p0.app](https://p0.app) and select **Agentic gateway**, then choose the **A2A bridge** component.
2. Click **Add A2A bridge**.
3. 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 [Gateway](/agentic-access/agentic-gateway/gateway.md) that fronts this bridge.
   * **Agent host**: the base URL at which your upstream agents are hosted. The gateway routes A2A calls to this URL.
4. 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 [Agentic access policies](/policy-studio/policy-studio/agentic-access-policies.md) 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.

{% hint style="warning" %}
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](#prerequisites "mention") above.
{% endhint %}

## 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](https://datatracker.ietf.org/doc/html/rfc8693) standard. The token is signed, so no agent can change the chain. P0 writes each call and its chain to the [Event log](/agentic-access/using-the-gateway/event-log.md).

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 [Agentic access policies](/policy-studio/policy-studio/agentic-access-policies.md#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 a policy from [Agentic access policies](/policy-studio/policy-studio/agentic-access-policies.md) 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](https://api.p0.app/agentic/a2a/extensions/subject-delegation/v1) 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.

```mermaid
sequenceDiagram
    autonumber
    participant O as Agent 1 (subject)
    participant GW as P0 AI Gateway
    participant PC as P0 Controller
    participant A1 as Agent 2 (actor)

    O->>GW: A2A request: POST a2a/smart-service/agents/agent-2<br/>(Bearer: gateway-issued JWT)
    GW->>GW: Is Agent 1 allowed to call Agent 2? (entitlement check)
    GW->>GW: Mint a session JWT (sub = agent host session, aud = Agent 2)
    GW->>GW: Exchange the gateway-issued JWT for a subject token,<br/>may_act names Agent 2 as the only party that can redeem it
    GW->>A1: POST .../agent-2 (Bearer: session JWT,<br/>message.metadata.subject_token: subject token)
    Note over A1: Validates the session JWT against the gateway's JWKS.<br/>The subject_token is a delegation credential.<br/>Agent 2 must redeem it to act as Agent 1
    A1->>GW: POST /token (subject_token,<br/>client_assertion: Agent 2's own federated JWT)
    GW->>GW: Verify the subject token and the client assertion
    GW->>PC: Is Agent 2's issuer a trusted identity provider?
    PC-->>GW: Yes
    GW->>GW: Actor's (iss, sub) must match the subject token's<br/>may_act, or the exchange is rejected
    GW->>GW: Mint a new token: sub is still Agent 1,<br/>act nests Agent 2's identity onto the existing chain
    GW-->>A1: New gateway-issued JWT, chain updated, acting as Agent 1
```

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](https://google.github.io/adk-docs/get-started/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](/policy-studio/policy-studio/agentic-access-policies.md) that govern what agents can do through the bridge.
* [Requesting access](/agentic-access/using-the-gateway/requesting-access.md#requesting-access-to-an-agent): how an agent requests access to an agent behind the bridge, and the address it calls once access is granted.
* Configure the [MCP server](/agentic-access/agentic-gateway/mcp-server.md) you want to expose behind the same gateway.