Agent-to-Agent Communication: Routing, Authenticating and Tracing A2A Calls
Agent-to-agent communication over the A2A protocol leaves identity, routing policy, and tracing to the infrastructure around it. This guide follows one A2A call through Bifrost: transport routing and failover, four credential boundaries, agent access grants, and correlated logs.
TL;DR
- Agent-to-agent communication over A2A carries no caller identity in its payloads; authentication and authorization happen at the HTTP or gRPC layer, which makes a gateway the natural place to enforce them.
- Bifrost routes each A2A call by the agent card's interface order, bridges JSON-RPC, REST, and gRPC, and moves a unary call to another interface only when the agent could not have started the work.
- One A2A call through Bifrost crosses four credential boundaries: the caller's key, the card fetch credential, the agent's runtime credential, and the forwarded caller key.
- Agent access is a separate grant from model and tool access, so permission to call an agent never authorizes that agent's own LLM or MCP calls.
- Two headers,
x-bf-session-id(A2A context ID) andx-bf-agent-correlation-id(A2A task ID), join Agent Logs with LLM logs, MCP logs, and exported traces.
Agent-to-agent communication is the exchange of messages, tasks, and results between independent AI agents, and the Agent2Agent (A2A) protocol standardizes it over JSON-RPC, HTTP+JSON, and gRPC. The protocol deliberately leaves identity, routing policy, and tracing to the infrastructure around it. Bifrost, the open-source AI gateway built by Maxim AI, fills that gap: it registers agents by their agent card, checks who may call each one, bridges transports, and logs every operation next to the model and tool calls the agent makes. This post follows one A2A call through those three jobs.
Agent-to-Agent Communication and What the A2A Protocol Leaves Open
The A2A protocol defines the data model (agent cards, messages, tasks, artifacts), the operations, and three protocol bindings. It does not define who may call an agent, how traffic fails over, or where the logs go. The A2A specification states that identity is handled at the protocol layer, not within A2A semantics.
The A2A project's enterprise implementation guidance says payloads such as JSON-RPC messages do not carry user or client identity, and recommends API management for centralized policy enforcement, traffic management, and analytics. The A2A protocol primer covers the basics; this post covers the operational layer:
| Concern | What the A2A project defines or recommends | What the deployment must decide |
|---|---|---|
| Routing | Interfaces listed in the agent card | Which interface to use, what to do on failure, which networks are reachable |
| Authentication | Security schemes declared in the card | Who holds which credential on each hop |
| Authorization | Left to the agent's own policy | Which callers may reach which agent |
| Tracing | Recommends W3C trace context and logging task IDs | How agent, model, and tool activity are joined |
The Agent Gateway Between Callers and Agents
An agent gateway is a control point that sits between A2A callers and remote agents, authenticating each call, checking access, choosing the upstream transport, and recording the operation. Bifrost, the enterprise AI gateway, governs agent-to-agent traffic with the same identities and logs it uses for model and tool traffic, so one call can be followed end to end.
The Agent Gateway in Bifrost currently supports A2A v1. An agent is registered once, and clients receive a gateway address per agent, such as /agents/a2a/library-research/json-rpc. Protocol endpoints stay disabled until the External Client URL is set in gateway settings, because Bifrost uses that URL in served cards and push callbacks.
The Agent Gateway launch post explains why models, tools, and agents share one gateway, and the Agent Gateway product page shows the full architecture.
Routing A2A Calls: Agent Cards, Transports, and Failover
The Bifrost AI gateway routes an A2A call by reading the agent card's supportedInterfaces, keeping those with a supported v1 binding and a valid endpoint, and using card order as the initial preference. The client's transport and the agent's transport can differ: a JSON-RPC client can reach a gRPC-only agent.
Registration takes the full card URL. Each request to the gateway's card fetches the current upstream card, rewrites its endpoints and authentication to point at Bifrost, and removes the original signatures, since the rewrite invalidates them. The A2A agent card guide covers the card schema itself.
Network reach is explicit. Public destinations are allowed; internal agents need an entry in the Private Network Allowlist, and link-local and cloud metadata addresses stay blocked even when an entry matches. For gRPC, each agent gets its own hostname on a shared listener, such as library-research.a2a.example.com:443, because the gRPC method path cannot identify the agent.
Failover follows the rule in Figure 2: Bifrost moves to the next interface only when the failure shows the agent did not start work.
| Failure | Current unary operation | Later operations |
|---|---|---|
| Dial failure before delivery | Next candidate | Start with the advanced candidate |
| HTTP 404, 405, 410, 426 | Next candidate | Advance and refresh the card |
| HTTP 5xx or broken response | Error returned, no replay | May advance |
| Authentication or validation error | Error returned | Not treated as failover |
Streaming operations are never replayed. After a dropped stream, the client uses GetTask and SubscribeToTask with the task ID it received, as described in transport selection and recovery.
A2A Authentication Across Four Boundaries
A2A authentication through a gateway involves four separate credentials, each scoped to one hop: the caller's Bifrost credential, the credential Bifrost uses to fetch the agent card, the credential Bifrost presents to the agent, and the caller credential the agent reuses for its own model and tool calls.
| Hop | Credential | Options |
|---|---|---|
| Caller to Bifrost | Virtual key or enterprise identity | x-bf-vk, IdP token, Edge or CLI session, auth proxy |
| Bifrost to card host | Card fetch credential | None, headers, OAuth 2.0 client credentials |
| Bifrost to agent | Request credential | Headers, OAuth 2.0 client credentials, none; CA and mTLS settings |
| Agent to Bifrost | Forwarded caller credential | Opt-in, per registration |
The card's security schemes pre-select the request fields, and Configure manually overrides an inaccurate card. Every runtime endpoint must also pass an origin check: the card's origin is allowed automatically, and other origins are added as additional agent endpoints. The authentication guide covers each setting, and the A2A security guide maps these controls to the A2A threat model.
AI Agent Governance: Who Can Call Which Agent
Bifrost controls who can call an agent through explicit grants. A virtual key granted library-research can call that agent; the grant does not extend to other registered agents, and an ungranted or disabled agent is refused with a protocol error such as -31403 on JSON-RPC.
Agent access has three scopes:
- Virtual key grants for an application's own key, managed from the agent or the key.
- Access profiles in Bifrost Enterprise, which grant agents to users, roles, teams, business units, and customers.
- Projects in Bifrost Enterprise, which scope one request with an
x-bf-project-nameheader.
Allow any virtual key lets every valid key reach the agent without a grant. client.enforce_auth_on_inference must be true, or requests with no identity pass anonymously. The governance resource page shows how these grants fit with budgets and rate limits, and the AI Governance page covers identity-based access across the gateway.
Forwarding Caller Identity to Model and Tool Calls
By default, the Bifrost gateway strips the caller's Bifrost credential before forwarding a request to an agent, so a gateway credential never reaches an external server unless a registration opts in. Enabling Forward Bifrost authentication passes the accepted credential to the agent, which reuses it on its model and tool calls.
This matters because agent access is a separate grant. An agent can pass its gateway access check and still have an LLM or MCP call denied, since those calls use the caller's provider and MCP tool permissions. Forwarding preserves attribution: the agent's model spend and tool calls land on the original caller's key, not on a shared service key. The MCP Gateway page covers how those tool permissions are set.
If both credentials use the same header, a per-registration policy decides which wins. The agent server must keep each task's credential in that task's own state; a shared header map can attribute one caller's work to another.
Agent Tracing: Joining A2A, LLM, and MCP Logs
Agent tracing in the open-source Bifrost gateway joins three log streams with two headers. The agent sends x-bf-session-id set to the A2A context ID and x-bf-agent-correlation-id set to the A2A task ID on every LLM and MCP request it makes for a task, and Agent Logs links the conversation and task to those calls.
curl <http://localhost:8080/v1/chat/completions> \
-H "x-bf-vk: $CALLER_BIFROST_VK" \
-H "x-bf-session-id: $A2A_CONTEXT_ID" \
-H "x-bf-agent-correlation-id: $A2A_TASK_ID" \
-d '{"model": "openai/gpt-4o-mini", "messages": [...]}'
Use the IDs from the A2A server's execution context, not the JSON-RPC request ID; the steps are in connecting model and tool calls. In Agent Logs, the session view groups operations, stream events, LLM logs, and MCP logs by context ID. Read the task state, not only the operation status: a successful A2A response can carry a task in failed state. Each operation also reports duration, upstream latency, and a breakdown of gateway overhead.
Agent Observability in OpenTelemetry and Other Backends
A2A operations use the same observability connectors as LLM and MCP traffic, so agent observability lands in the backends a team already runs. Bifrost exports A2A protocol operations, push notifications, and push deliveries, with each delivery retry as its own operation.
The OpenTelemetry connector emits operation spans with attributes such as gen_ai.agent.name, a2a.task.id, gen_ai.conversation.id, and bifrost.a2a.upstream.transport, plus the a2a.client.operation.duration metric. Prometheus receives the duration histogram without message bodies, and Datadog, BigQuery, Pub/Sub, Kafka, and Splunk have their own representations. An incoming W3C traceparent header is kept, so A2A spans join the caller's existing distributed trace.
Content suppression on a virtual key or project applies to exports, and raw HTTP capture is off by default and limited to 1 MiB per direction. The AI Observability page covers gateway-layer logging across all three traffic types.
Push Notifications and Long-Running A2A Tasks
For long-running tasks, a client registers a callback through Bifrost instead of holding a stream open. Bifrost gives the agent its own callback URL and a separate notification token, stores the client's original callback, and relays each update to it.
Delivery is at least once, with up to six attempts and a 30-second timeout per attempt, so callback handlers must be idempotent. Callback authentication supports Basic and Bearer, and delivery to private or loopback callback addresses is blocked unless a server setting allows it for development. Agent Logs records the agent's update and each delivery attempt separately, which shows which hop failed. The push notifications guide covers cleanup of finished configurations.
Frequently Asked Questions
What is the A2A protocol?
The A2A (Agent2Agent) protocol is an open standard for communication between independent AI agents, originally developed by Google and donated to the Linux Foundation. It defines agent cards for discovery, messages and tasks for work, artifacts for results, and JSON-RPC, gRPC, and HTTP+JSON bindings. Version 1.0 is the current release, and Bifrost accepts A2A v1 traffic. The A2A protocol gateway guide walks through setup.
What is the difference between A2A and MCP?
MCP connects an agent to tools and data sources; A2A connects an agent to other agents. A2A treats the remote agent as opaque: the caller sends a message and receives a task, without seeing the agent's tools or memory. Bifrost governs both through the same keys and logs. The A2A vs MCP comparison covers the differences in detail.
What is an agent card in A2A?
An agent card is a JSON document, usually served at /.well-known/agent-card.json, that describes an agent's skills, capabilities, endpoints, and authentication requirements. When an agent is registered in Bifrost, clients fetch the gateway's rewritten card, which points every interface at Bifrost and advertises the authentication callers use with the gateway.
How does A2A authentication work?
A2A delegates authentication to standard web mechanisms. The agent card declares security schemes such as API keys, HTTP bearer, OAuth 2.0, OpenID Connect, or mutual TLS, and the client sends credentials in headers on every request. Through Bifrost, the caller authenticates to the gateway, and Bifrost presents a separately configured credential to the agent, so the two never need to share secrets.
Does an agent grant let the agent call models and tools?
No. Agent access is a separate grant from model and tool access in Bifrost. A virtual key that may call an agent does not authorize the agent's later LLM or MCP requests; those are checked against the caller's provider and tool permissions when the agent forwards the caller's credential. The agent gateway comparison explains identity across the three layers.
Why does a successful A2A response show a failed task?
The operation status and the task state describe different things. An HTTP 200 with a JSON-RPC result means the request reached the agent and the agent answered; the task inside that result can still be failed, rejected, or input-required. In Bifrost's Agent Logs, read the returned task state in the conversation view, then open the task's LLM and MCP logs to find the cause.
Run Agent-to-Agent Communication Through Bifrost
Agent-to-agent communication needs the same controls as model and tool traffic: explicit access, scoped credentials, predictable failover, and logs that join every hop. Bifrost provides them for A2A traffic, deployable in-VPC, on-prem, or air-gapped, as covered on the Bifrost Enterprise page. Teams evaluating an agent gateway for A2A traffic can book a demo with the Bifrost team.
