Bifrost's Agent Gateway puts A2A agent calls behind virtual keys and logs

Maxim AI’s open-source gateway Bifrost now proxies agent-to-agent traffic. Version 2.3.0, released on 13 October 2026, adds what the release notes call an Agent Gateway: an operator registers an existing agent that speaks the Agent2Agent (A2A) protocol by its agent card URL, and callers then reach that agent through Bifrost at /agents/a2a/<name>/, over JSON-RPC, REST or gRPC. Each call is checked against a virtual key, written to a new Agent Logs view and exported to the same tracing connectors as model and tool traffic.

The point is not the proxying itself. Bifrost already sits in front of model providers and MCP servers, enforcing budgets, rate limits and access rules on those calls. Agent-to-agent calls were the piece left outside: an orchestrator handing work to a research agent, which then spends tokens and calls tools of its own. With 2.3.0, all three kinds of traffic can share one set of keys, one set of policies and one set of logs, and a task handed to an agent can be followed down to the model and tool calls it caused.

That matters most for platform teams that already run more than a couple of internal agents and are being asked who can call them, what they cost, and what happened when one of them failed. A follow-up release, v2.3.1 on 19 October, tightened the feature’s network boundaries. This piece reads both releases, the feature’s documentation and the pull requests behind it, and sets them against where the A2A standard itself stands.

The third kind of AI traffic to get a control point

Gateways for AI traffic have arrived in waves. The first, through 2023 and 2024, put a proxy between applications and model APIs to handle keys, failover, spend and logging. The second, through 2025, did the same for tool calls once the Model Context Protocol made tools a networked dependency; our explainer on what an MCP gateway does covers that layer. The third wave is agent-to-agent calls, where the thing on the other end of the wire is not a model or a tool but another agent with its own reasoning loop, budget appetite and failure modes.

A2A is the protocol most of that traffic now uses. Google announced it on 9 April 2025 with more than 50 technology partners, describing it as “an open protocol that complements Anthropic’s Model Context Protocol (MCP)”. On 23 June 2025 the Linux Foundation took the project in, saying it would keep A2A vendor neutral. At the protocol’s one-year mark the foundation reported more than 150 supporting organisations and the release of version 1.0, “its first stable specification”, with multi-protocol support, multi-tenancy and signed agent cards.

The division of labour between the two protocols is the one Google drew at launch and the Linux Foundation repeated a year later: MCP connects an agent to tools and data, A2A connects agents to each other. Our A2A vs MCP comparison goes through the difference in detail. For a gateway, the practical consequence is that the two kinds of call carry different objects. An MCP call is a tool invocation with arguments and a result. An A2A call carries messages, tasks with states, artifacts, streams of status updates and, for long jobs, push notifications to a callback URL. A proxy that only understood request and response would miss most of what happens.

The A2A project itself expects something to sit in that position. Its guide to enterprise implementation says that for A2A servers exposed across organisational boundaries, “or even within large enterprises”, integration with API management “is highly recommended”, for centralised policy enforcement, rate limits and quotas, routing, and analytics on agent usage. The same guide asks implementers to log task IDs, session IDs and correlation IDs and to propagate W3C trace context. Bifrost’s Agent Gateway is one vendor’s answer to that recommendation, built onto a gateway that already handles the model and tool calls those agents make.

How the Agent Gateway works

The overview documentation describes the feature in one sentence: Agent Gateway “manages agent registrations, access, credential forwarding, push callbacks, and observability in Bifrost.” A2A is the only agent protocol it supports at present.

Registration starts from the agent card

In A2A, an agent describes itself in an agent card, a JSON document that lists its skills, the endpoints it serves, its capabilities and the authentication it expects. The specification’s discovery section gives three ways a client can find one: a well-known URI at /.well-known/agent-card.json, a curated registry or catalogue, or direct configuration.

Bifrost uses the card as the unit of registration. In the dashboard an operator opens Agents, then Agent Catalog, names the registration (lowercase letters, digits and single hyphens, because the name becomes part of the URL) and enters the full card URL. Bifrost fetches the card and displays the agent’s skills, interfaces, capabilities and advertised authentication before anything is saved. The same registration can be made through POST /api/agents, inspected first with POST /api/agents/inspect, or declared in a top-level agents array in config.json, which the changelog says is “reconciled by name at startup”. The Helm chart passes bifrost.agents[] straight into that array. A declarative entry looks like this:

{
  "agents": [
    {
      "name": "library-research",
      "agent_card_url": "https://research.example.com/.well-known/agent-card.json",
      "enabled": true,
      "allow_by_default": false,
      "virtual_key_ids": ["YOUR_VIRTUAL_KEY_ID"],
      "forward_accepted_credential": true,
      "runtime_auth": {
        "type": "headers",
        "headers": {"Authorization": "env.RESEARCH_AGENT_AUTHORIZATION"}
      }
    }
  ]
}

One setting gates the whole feature. Until an operator sets the public base URL, a2a_external_client_url, the documentation says the agent card, JSON-RPC, REST and push-callback endpoints return 503 and gRPC operations return UNAVAILABLE, although registration and management still work. Bifrost uses that URL when it advertises endpoints in the cards it serves and when it builds push-callback addresses. Since v2.3.1 it no longer falls back to the request’s Host header, which a caller controls; the v2.3.1 notes tell operators who relied on the host header to set the URL before upgrading.

What callers see

Once an agent is registered, Bifrost serves four kinds of endpoint for it. Using the documentation’s example agent:

The card a caller fetches from Bifrost is not the original. According to the registration guide, each request to the gateway’s card URL fetches the current card from the agent’s server and rewrites its endpoints and authentication requirements for gateway access; there is no cached registration-time copy, so if the upstream server cannot supply its card, the request fails. Because the rewrite changes the document, Bifrost strips the original signatures, since they would no longer verify. That is worth knowing for teams that plan to rely on A2A v1.0’s signed cards: a client talking through the gateway is trusting the gateway’s rewritten card, not the agent’s signature.

A first call is ordinary A2A v1 with a Bifrost virtual key attached. The documentation’s example sends a SendMessage request to the JSON-RPC route with an x-bf-vk header and an A2A-Version: 1.0 header. The gateway accepts A2A v1 and rejects an explicitly incompatible version.

Transports are bridged, not mirrored

The client’s transport and the agent’s transport do not have to match. The transport guide says Bifrost reads the card’s supportedInterfaces, keeps the ones that declare a supported v1 binding (JSONRPC, HTTP+JSON or GRPC), and uses card order as its initial preference. A REST client can reach a JSON-RPC-only agent, and a JSON-RPC client can reach a gRPC agent.

gRPC needed a design decision. HTTP routes name the agent in the path, but every A2A gRPC client calls the same service methods, so the method path cannot say which agent is meant. Bifrost’s answer, set out in the gRPC section, is to give each agent its own hostname on one shared listener: with a2a_grpc_base_domain set to a2a.example.com and wildcard DNS in place, library-research.a2a.example.com:443 reaches the library-research registration because Bifrost reads the HTTP/2 authority the client dialled. The listener is plaintext and expects TLS to terminate at an ingress or load balancer, and agent names used over gRPC are capped at 63 characters because they become DNS labels.

Recovery is conservative by design. The runtime caches cards and protocol clients, and the pull request that built it explains that a 404, 405, 410 or 426 from a cached endpoint is treated as a hint that the interface is stale, which triggers a card refresh. For a unary operation, Bifrost tries the next eligible interface only when the failure shows the endpoint was never reached or cannot serve that operation. A 5xx or an ambiguous network error is returned, not replayed, because the agent may already have started work and a replay could create a second task. Streams are never replayed automatically. A client that disconnects stops the upstream stream but does not cancel the task; CancelTask does that.

Figure 1: An A2A call through Bifrost passes the same kind of checkpoints as a model call, plus two that are specific to agents: the card rewrite and the destination check.

Who may call which agent

Registration gives an agent an address. Grants decide who may use it. The access documentation keys everything to Bifrost’s existing virtual keys, the same credential that carries model budgets and rate limits.

There are two ways to grant. From the agent side, a registration lists the IDs of the virtual keys allowed to call it (virtual_key_ids). From the key side, a virtual key carries agent_grants. The dashboard shows both views of the same grant. The changelog spells out the update semantics for agent_grants: omit the field to keep the current grants, send [] to clear them, and any unknown agent name rejects the whole update atomically. A per-agent allow_by_default switch opens an agent to every valid virtual key without explicit grants, while preserving the explicit selections so that switching it off restores them. A key granted one agent gains nothing else; ungranted or disabled agents return 403, and a JSON-RPC client sees a protocol error such as -31403 naming the agent that refused access.

Two cautions in the documentation are worth repeating, because both are easy to get wrong.

First, grants restrict authenticated callers; they do not make anonymous traffic private. The access page carries a warning that “requests that present no identity can pass through anonymously” unless client.enforce_auth_on_inference is set to true. A team that registers an internal agent and grants it to one key, without turning on enforcement, has not locked it down.

Second, an agent grant is not a model grant. The documentation states that agent access “is separate from permission to use LLM providers or MCP tools, so an agent grant alone does not authorize the agent’s later LLM or MCP calls.” That separation is the right default for AI governance: a team that may ask the research agent a question has not thereby been given the right to spend on the most expensive model the research agent happens to use.

Forwarding the caller’s identity

The separation raises an obvious question: whose identity does the agent use when it calls a model? By default, Bifrost strips the caller’s Bifrost credential before forwarding a request to an agent, so the gateway key does not leak to an external server. When a registration turns on Forward Bifrost authentication, Bifrost passes the credential it accepted, in the same header, to the agent. The agent can then reuse it on its own model and MCP calls through Bifrost, so those calls are checked against the original caller’s permissions and counted against the original caller’s budget.

This is opt-in and only half automatic. The documentation is explicit that the gateway toggle covers the hop from Bifrost to the agent, and the agent server must handle the hop back. It also warns against a specific bug: an agent that keeps forwarded credentials in a global, mutable header map can attribute one caller’s work to another when tasks run concurrently. The guidance is to keep the credential in each task’s own execution state.

What the enterprise tier adds

Some of the access model is reserved for Bifrost Enterprise. The overview states that Enterprise “also supports agent grants through access profiles and projects, user attribution, and scoped log access.” In practice that means a group of users can receive agents through a shared access profile instead of key-by-key grants, a request can be scoped to a project with an x-bf-project-name header, and the enterprise v2.3.0 notes add that bearer calls resolve the user through the identity provider, with the agent log recording that user’s team, customer and business unit. The open-source build covers registration, virtual-key grants and Agent Logs; teams that need identity-provider-driven grants and per-user log scoping will be looking at the paid tier.

Credentials and destinations

An A2A call through a gateway crosses several authentication boundaries, and the authentication guide separates them cleanly:

Card and request authentication are configured separately even when they use the same secret, because Bifrost has to fetch the card before it can read what the agent wants. Request authentication supports custom headers, OAuth 2.0 client credentials and no authentication, with per-connection TLS settings for a private certificate authority or mutual TLS. Interactive OAuth sign-in and per-user consent are not part of agent registration. When the card’s advertised requirements are wrong, a “Configure manually” option overrides them.

The less visible part of this design is where Bifrost is allowed to connect. An agent card is a document the agent’s owner controls, and it can advertise any runtime URL. If a gateway trusted every advertised URL, a card could point it at an internal service or a cloud metadata endpoint, and the gateway would carry credentials there. Pull request #8552, merged for v2.3.1, describes the fix in its first line: “Protect Agent Gateway outbound requests from SSRF and credential forwarding to unapproved destinations.”

Two permissions came out of it. A global private network allowlist (client.a2a_private_allowlist) names the private hosts, IPs or CIDR ranges Bifrost may reach for card discovery, OAuth and runtime calls; link-local and cloud metadata addresses stay blocked even if an entry covers them. A per-agent list of additional agent endpoints (credential_origins, up to 32) approves runtime origins other than the card’s own. The pull request adds that addresses are resolved and checked at connection time, and that proxied connections tunnel to the already validated IP so a proxy cannot resolve the name somewhere else. The A2A specification asks agents to guard against the same class of attack when they call webhooks; its push notification security section tells them to reject private IP ranges and localhost and to use allowlists where appropriate.

What gets logged, and how a task is followed

Observability is where the gateway does most of its work. The changelog says every A2A operation and every stream event gets its own log row, stored in a relational database, ClickHouse, or a hybrid with payloads in object storage, and surfaced in a new Agent Logs workspace.

The Agent Logs guide builds the view around the A2A context ID, which the protocol uses to tie related tasks into one conversation. Opening a session shows its operations with stream events beneath them, plus two more tabs: LLM Logs for model calls whose session ID matches the context ID, and MCP Logs for tool calls with the same session ID. An individual operation shows its gateway status, transports, IDs, task state and timing, with tabs for the conversation, typed payload, events, and the LLM and MCP calls that carry its task ID.

Those links do not appear by magic. The gateway sees the traffic between client and agent; it cannot tell which model call an agent made on behalf of which task unless the agent says so. The integration guide asks the agent to send two headers on every model and tool request it makes through Bifrost: x-bf-session-id set to the A2A context ID and x-bf-agent-correlation-id set to the A2A task ID. It is specific that the JSON-RPC request ID, the message ID or a tracing UUID are the wrong values. Bifrost already used x-bf-session-id for session grouping on model traffic, and since v2.0.0 it has filled the session ID automatically from Claude Code, Codex CLI and OpenCode session headers when the explicit header is absent; the A2A work extends the same idea to agents, with the context ID as the session.

Some details in the logging design show care for how agents actually fail:

• A successful request can carry a failed task. The documentation’s travel-agent example returns HTTP 200 with a JSON-RPC result whose task state is failed because no flights were available. The operation is logged as Success, since the protocol exchange worked; the task state tells you the work did not.
• Timing is split. Each operation records total duration, upstream latency to the agent and gateway overhead, with the overhead broken into protocol library, middleware, plugins, serialisation, processing and client delivery.
• Cost stays with the model calls. The guide notes that tokens and model cost “belong to the correlated LLM logs”; there is no separate token charge on the A2A operation.
• Raw capture is opt-in. Storing raw HTTP request and response bytes is off by default, capped at 1 MiB in each direction, unavailable for gRPC, and not guaranteed to be secret-redacted.

The same data leaves Bifrost through the connectors already configured for model and MCP traffic. The guide lists eight destinations: OpenTelemetry, Prometheus, Maxim, Datadog, BigQuery, Pub/Sub, Kafka and Splunk. In OpenTelemetry each A2A operation becomes a client span with stream updates as span events, and a histogram named a2a.client.operation.duration records operation latency; the v2.3.1 notes add that A2A operations export bodies and stream updates to OTel, Maxim and telemetry. Content suppression set on a virtual key applies to these exports as well.

Figure 2: The gateway can only join an agent’s task to its model and tool calls if the agent sends the context ID and task ID back on those calls.

Push notifications and long-running work

A2A was designed for tasks that run for minutes or longer; the specification lists asynchronous, long-running work among its key goals. For those, a client can register a callback URL and close its connection, and the agent posts updates to the callback when it has them.

A gateway in the middle has to decide whether callbacks go around it or through it. Bifrost routes them through. When a client registers a push configuration via the gateway, Bifrost replaces the callback with its own address, <base-url>/agents/a2a/<name>/push/callback, and a separate notification token, keeps the client’s original configuration, and delivers each update onwards. Updates go into a durable outbox in the configuration database, not an in-memory queue, so an accepted update survives a restart.

The delivery rules are explicit: any 2xx from the callback counts as success, other statuses and timeouts trigger retries up to six attempts, each attempt has a 30-second timeout, and redirects are not followed. Delivery is at least once, so the callback must be idempotent. A 202 to the agent means Bifrost has queued the update, not that the application has received it. Agent Logs separates the two events, recording a push notification when the agent’s update arrives and a push delivery for each attempt to reach the application. Delivery to private or loopback callback addresses is blocked unless server.a2a_allow_private_push_callbacks is switched on, which the documentation says belongs only in development and test.

Where it sits against the big platforms

The large platforms have approached agent traffic from the identity and hosting side rather than from the network path.

Microsoft has gone furthest in public documentation. Microsoft Entra Agent ID gives agents their own directory identities, built from templates called agent identity blueprints, and says the platform supports “OAuth 2.0, Model Context Protocol (MCP), and agent-to-agent (A2A)” for authentication and agent communication, with agent authentication and activity logged for audit. Copilot Studio can connect to an external A2A agent by its endpoint URL, recommended for agents “built on external frameworks” or “hosted outside Copilot Studio”. The Linux Foundation’s anniversary release adds that Microsoft integrated A2A into Azure AI Foundry and Copilot Studio.

The same release says AWS added A2A support through Amazon Bedrock AgentCore Runtime, and lists Google, IBM, Salesforce, SAP and ServiceNow among more than 150 supporting organisations. Google, which created the protocol, is named alongside Microsoft and AWS as one of the three platforms with deep A2A integration. Each of these approaches tends to make the vendor’s own platform the place where agents are identified, hosted and found.

The A2A project has not standardised that layer. Its discovery guide describes curated registries as the enterprise approach, with centralised management and capability search, and then states that “the current A2A specification does not prescribe a standard API for curated registries.” The foundation’s anniversary release lists “consolidation of efforts for registry” on the roadmap.

These layers overlap less than vendor marketing suggests. An identity directory can say an agent exists and what it may access; it does not sit on every A2A request deciding whether a particular virtual key may reach it, nor join the resulting task to the tokens it burned. A gateway does those things but does not issue identities. Bifrost’s registration list is a small catalogue in its own right, but it is a list of what the gateway will proxy, not a directory other systems query. For teams spread across clouds, a neutral gateway is the piece that can treat a Copilot Studio agent, an AgentCore-hosted agent and an in-house LangGraph service the same way, provided each speaks A2A. The same release also added a Bedrock passthrough route that forwards AWS’s InvokeAgent operation, for agents that only expose AWS’s own API.

A worked example: one research request

The documentation’s own scenario shows how the pieces fit. A team runs library-research, an A2A agent that answers questions about software libraries, using a model and a documentation lookup tool over MCP.

1. The operator registers the agent by its card URL, sets the External Client URL, grants the application’s virtual key, turns on enforce_auth_on_inference, and enables credential forwarding.
2. The application fetches /agents/a2a/library-research/.well-known/agent-card.json from Bifrost and gets a card whose endpoints point at the gateway.
3. It sends SendMessage to the JSON-RPC route with its virtual key. Bifrost checks the grant, runs its A2A plugin hooks, picks the agent’s first eligible interface and forwards the message along with the caller’s key.
4. The agent creates a task and, while working on it, calls a model and two MCP tools through Bifrost with the forwarded key plus x-bf-session-id and x-bf-agent-correlation-id. Those calls are checked against the caller’s model and tool grants and budgets.
5. In Agent Logs the operator opens the session and sees the A2A operation, the model calls with their tokens and cost, and the two tool calls. In the documentation’s walkthrough, two questions in one conversation produced eight model calls and two Context7 tool calls.

If step 4 is skipped, steps 1 to 3 still work: the agent is reachable, governed and logged at the A2A layer. What is lost is the attribution of its model and tool spend to the caller and to the task. That gap is the most likely source of disappointment for teams that adopt the gateway without changing their agent code.

For teams choosing the frameworks those agents are built on, our ranking of agent orchestration frameworks covers which ones speak A2A.

What the release does not settle

The limits worth weighing are mostly about the state of the protocol and the category, not about this release.

The standard is young. A2A reached its first stable version in 2026, and the gateway accepts only A2A v1. Agents still serving an earlier version of the protocol will need upgrading before they can sit behind it, and the extension mechanism is still settling; Bifrost relays declared extensions with limits of 32 per card and 64 KiB per negotiated payload, and rejects requests for undeclared ones.

There is no standard registry. Until the A2A project defines a registry API, each platform’s catalogue is its own, and discovery across them remains direct configuration. A gateway registration list helps inside one organisation, not across several.

Correlation depends on the agent. Every cross-layer view in Agent Logs relies on agents sending the context and task IDs back. Agent frameworks will need to make that a default before it is reliable at scale.

Protocol success is not task success. The A2A model separates a working exchange from a finished job. Dashboards and alerts that count HTTP 200s will overstate how well agents are doing; teams need alerting on task state, which the logs record where the operation exposes it.

Card signatures and intermediaries do not yet fit together. Signed agent cards are one of v1.0’s headline features, and any gateway that rewrites endpoints breaks the original signature. How clients should trust a card served by an intermediary is a question for the standard, not for any one gateway.

What to watch next

Three things will decide whether agent gateways become as ordinary as model gateways. The first is whether the A2A project ships the registry consolidation on its roadmap, which would give gateways and identity directories a shared catalogue to read from. The second is whether agent frameworks start propagating session and task identifiers on outbound model and tool calls by default, as they already propagate trace context, so that cost and failure can be followed from an agent request to the tokens it caused without custom code. The third is how the big platforms’ identity products and neutral gateways divide the work in practice.

Bifrost has moved quickly on its side: the feature arrived with transport bridging, a durable push outbox and connector exports, and the first point release added explicit public URLs and destination permissions. For teams that already route model and MCP traffic through one place, putting agent calls behind the same keys and logs is the logical next step, and the agents themselves are now the part that has to catch up.