A2A Security: Authenticating and Authorizing Agent Traffic

TL;DR

• A2A security covers eight threats: agent impersonation, card spoofing, over-broad access, credential leakage, callback abuse and SSRF, replayed tasks, injected content, and a missing audit trail.
• The A2A specification declares authentication in the agent card's securitySchemes, requires TLS in production, and requires an authorization check on every protocol operation.
• One A2A request crosses four authentication boundaries: caller to gateway, gateway to card host, gateway to agent, and agent to its own model and tool calls.
• Bifrost strips the caller's Bifrost credential before forwarding to an agent unless the registration opts in, and it blocks push callbacks to private and loopback addresses by default.
• 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.

A2A security is the practice of authenticating every party in an agent-to-agent exchange, authorizing which caller may invoke which agent, and keeping credentials, callbacks, and records intact as work passes between agents. Bifrost, the open-source AI gateway for models, tools, and agents built by Maxim AI, applies those controls at one layer between callers and the A2A agents they reach. This guide covers the A2A threat model, what the protocol requires, and how to configure each control.

What Is A2A Security?

A2A security is the set of controls that verify who is calling an agent, decide whether that caller may use it, protect the credentials each hop carries, and record what happened. It applies familiar API identity and access rules to agents that delegate work over the Agent2Agent (A2A) protocol.

A2A lets agents discover each other through an agent card, exchange messages, run tasks, and return artifacts; the guide to running A2A traffic through a gateway covers those mechanics. Delegation is what makes A2A harder to secure than a single API call. Each hop can widen access, lose the original caller's identity, or carry untrusted content forward.

A2A security is a narrower slice of agentic AI security and its runtime controls; this post stays on the agent-to-agent path.

The A2A Threat Model: Eight Risks in Agent-to-Agent Traffic

The A2A threat model has eight recurring risks: impersonated callers, spoofed agent cards, over-broad access grants, credentials leaking to downstream agents, abused push callbacks, replayed or duplicated tasks, prompt injection carried in messages and artifacts, and missing audit records.

Figure 1: Each hop in an A2A exchange carries a different threat, so no single check at the agent covers the whole path.

• Agent impersonation: an anonymous or stolen credential calls an agent as a trusted application.
• Card spoofing: a tampered card points callers or the gateway at unapproved endpoints.
• Over-broad access: one credential reaches every registered agent because grants were never scoped.
• Credential leakage: the caller's gateway key travels to a remote agent that has no reason to hold it.
• Callback abuse and SSRF: a push notification URL targets an internal service, loopback address, or metadata endpoint.
• Replayed tasks: a retry after an ambiguous failure creates a second task with real side effects.
• Injected content: instructions hidden in a message, file, or artifact steer the receiving agent.
• Missing audit trail: nobody can say which caller started a task or which model and tool calls produced the result.

The OWASP Top 10 for Agentic Applications, published by the OWASP GenAI Security Project in December 2025, names two of these directly: ASI03 Identity and Privilege Abuse, and ASI07 Insecure Inter-Agent Communication. The AI security resource page maps the wider list to gateway controls.

What the A2A Protocol Security Model Requires

The A2A protocol security model treats agents as standard enterprise applications: it declares authentication requirements in the agent card, requires encrypted transport, and makes each server responsible for authenticating and authorizing every request.

The A2A specification sets these requirements:

• Security schemes in the agent card. securitySchemes lists accepted methods modeled on OpenAPI: API key, HTTP Basic or Bearer, OAuth 2.0, OpenID Connect, and mutual TLS.
• Transport security. HTTPS for HTTP bindings and TLS for gRPC in production, with TLS 1.3 recommended.
• Per-operation authorization. Every operation, including ListTasks, GetTask, cancellation, and push configuration, must be scoped to what the caller may see.
• Authenticated extended card. GetExtendedAgentCard must require authentication and should not expose internal URLs or credentials.
• Push notification security. Agents should reject private, localhost, and link-local webhook URLs, and receivers should process notifications idempotently.
• Agent card signing. Cards may carry JSON Web Signatures so a client can detect tampering.

These are obligations on each agent server. A gateway applies them once across a fleet, which matches the NIST zero trust architecture principle of authenticating and authorizing before any session to a resource, with no implicit trust from network location. The Agent Gateway in Bifrost is that layer for A2A traffic.

A2A Authentication: Four Boundaries in One Request

A2A authentication in a gatewayed deployment happens at four boundaries: the caller authenticates to the gateway, the gateway authenticates to the server hosting the agent card, the gateway authenticates to the agent's runtime endpoint, and the agent authenticates back to the gateway for its own model and tool calls.

Figure 2: Card fetch, agent requests, and the agent's own model calls each use a separate credential, so one leaked secret does not open every hop.

Virtual keys are the standard caller credential; with SSO configured, Bifrost Enterprise also accepts identity-provider tokens through user provisioning with OIDC and SCIM. The agent authentication settings keep card and request credentials apart, and accept env. or vault. references so secrets stay out of configuration files.

Card spoofing is handled at registration. Bifrost sends runtime requests only to the card's own origin; any other advertised endpoint must be approved under Additional agent endpoints. Private destinations also need a Private Network Allowlist entry, link-local and cloud metadata addresses stay blocked, and an HTTPS card cannot downgrade agent traffic to plaintext outside loopback development. Because the gateway rewrites endpoints in the card it serves, it removes the upstream signatures; operators can inspect them in the registration preview before approving an agent.

AI Agent Access Control: Who Can Call Which Agent

AI agent access control in Bifrost is grant-based: a registered agent is reachable only by callers whose virtual key, access profile, or project grants it, unless the operator enables default access.

Agent access grants come in three scopes:

• Per virtual key. A key granted library-research can call that agent and no other registered agent.
• Access profiles (Enterprise). An access profile lists agents and is assigned to users, roles, IdP groups, teams, business units, or customers. Expired profiles grant nothing.
• Projects (Enterprise). A project scopes one request via x-bf-project-name. An unknown project or non-member currently falls back to the caller's own agent grants, so restrict those too.

Allow any virtual key (allow_by_default) opens an agent to every valid key without an explicit grant; it does not authenticate anyone. The setting that closes the gateway is enforce_auth_on_inference: without it, requests that present no identity pass anonymously, and explicit grants do not make anonymous traffic private.

{
  "client": { "enforce_auth_on_inference": true },
  "agents": [
    {
      "name": "library-research",
      "agent_card_url": "<https://research.example.com/.well-known/agent-card.json>",
      "allow_by_default": false,
      "virtual_key_ids": ["support-bot-key-id"]
    }
  ]
}

A denied JSON-RPC call returns a protocol error such as -31403, so clients should check the error field, not only the HTTP status. The AI governance page and the governance resource hub show how agent grants sit beside model permissions, budgets, and rate limits.

Keeping Agent Credentials From Leaking Downstream

Credential leakage is prevented by two defaults: Bifrost strips the caller's Bifrost credential before forwarding a request to an agent, and the credentials Bifrost uses to call the agent stay at the gateway.

Figure 3: The caller's credential leaves the gateway only when a registration opts in, and then it carries the caller's own access rules downstream.

This is where AI agent identity gets decided. An agent calling models and tools through Bifrost has two options, both covered in the guide to non-human identity for AI agents:

• Reuse the caller's credential. With Forward Bifrost authentication on, the agent's model and MCP calls follow the original caller's access rules and budgets. This suits trusted agents acting on a user's behalf.
• Use the agent's own key. The agent's virtual key applies its own fixed, narrow scope regardless of who called.

The agent server keeps a forwarded credential scoped to the current task, including asynchronous work, and sends it only to the Bifrost endpoint; a shared header map across concurrent tasks can attribute one caller's work to another. Access does not leak sideways either: a caller who may invoke an agent still needs separate model and MCP tool permissions, which are deny-by-default on a virtual key and enforced by the MCP gateway.

Securing A2A Push Notification Callbacks

A2A push notifications let an agent post task updates to a callback URL, which makes the callback a target for credential theft and server-side request forgery. Bifrost secures this path by giving the agent its own callback URL and a separate notification token, keeping the caller's real callback and credentials at the gateway, and refusing private and loopback destinations by default.

Figure 4: The agent never holds the caller's callback URL or credentials, and private or loopback destinations are refused before delivery.

The push notification flow runs in four steps:

1. The caller registers a callback through the agent's Bifrost endpoint, with Basic or Bearer callback authentication.
2. Bifrost substitutes its own callback route and token before calling the agent. Callback credentials are write-only.
3. Bifrost rejects updates with invalid tokens, malformed events, or another task's ID.
4. Accepted updates go to a durable outbox: up to six delivery attempts, a 30-second timeout each, no redirects followed.

Delivery is at least once, so callbacks should be idempotent. Keep a2a_allow_private_push_callbacks disabled outside development.

Replays, Prompt Injection, and the A2A Audit Trail

The last three threats are handled by gateway behavior rather than a single setting. Bifrost does not replay operations with an ambiguous outcome, applies guardrails to the model and tool calls an agent makes through the gateway, and records every agent operation in Agent Logs with the caller, task, and correlated LLM and MCP calls.

No replay of ambiguous work. Bifrost retries a unary operation on another advertised interface only when the endpoint clearly was not reached, such as a refused connection or a 404. An HTTP 5xx or broken response is returned without replay, because the agent may have started work, and streams are never replayed automatically. The caller should check the task with GetTask before resubmitting, as transport selection and recovery describes.

Guardrails on the agent's calls. Prompt injection in A2A arrives as text in a message, file, or artifact that the receiving agent passes to a model or acts on with a tool. When those calls route through Bifrost Enterprise, guardrails on LLM and MCP traffic inspect model inputs and outputs and tool arguments and results, using Bifrost-managed Prompt Guardrails, Secrets Detection, and Custom Regex or external providers with prompt-injection detection. The AI guardrails page covers rule design. Bifrost also rejects requests for A2A extensions the card did not declare.

A correlated audit trail. Agent Logs record each operation's caller, agent, transports, task state, and timing. When the agent sends x-bf-session-id and x-bf-agent-correlation-id on its outbound calls, the same view shows the model and tool calls behind a task. A successful A2A response can still carry a failed task, so read the task state.

Agent telemetry export sends operation spans and metrics to OpenTelemetry, Prometheus, Datadog, BigQuery, Pub/Sub, Kafka, or Splunk, with each push delivery retry exported separately. Administrative changes go to audit logs in Bifrost Enterprise, which can be signed with an HMAC key for verification.

A2A Security Threats Mapped to Controls

The table below maps each A2A security threat to the relevant spec guidance and the control Bifrost applies at the gateway. Use it as a review checklist when registering or auditing an agent, since every row is a setting or default an operator can verify.

The AI observability page shows how these records reach existing monitoring. For regulated environments, Bifrost runs self-hosted inside the customer's own infrastructure, as described on the Bifrost Enterprise page.

Frequently Asked Questions

How does A2A authentication work?

A2A authentication starts with the agent card, which lists accepted schemes in securitySchemes: API key, HTTP Basic or Bearer, OAuth 2.0, OpenID Connect, or mutual TLS. The client obtains credentials out of band and sends them on every request, and the server must authenticate each one. Behind a gateway, the caller authenticates to the gateway, and the gateway authenticates separately to the card host and the agent.

Is the A2A protocol secure by default?

The A2A protocol defines security requirements but does not enforce them for you. The specification requires TLS in production, authentication on every request, and authorization on every operation, yet each agent server implements those checks itself. A gateway applies them consistently across agents built by different teams, including anonymous-call rejection, scoped grants, and SSRF checks on callbacks.

What is the difference between A2A security and MCP security?

A2A security governs calls between applications and agents: who may invoke an agent, how its card is trusted, and how callbacks and delegated credentials are handled. MCP security governs an agent's calls to tools, as covered in MCP server authentication patterns. In Bifrost the two are separate grants on the same virtual key.

How do you give an AI agent its own identity?

Give each agent its own virtual key with the narrowest model, tool, and agent grants it needs, plus its own budget and rate limits. When an agent acts for a user, forward the caller's Bifrost credential instead, so downstream calls carry the user's permissions and attribution. Either way, every call is attributable to a named identity rather than a shared provider key.

How do you prevent SSRF through A2A push notifications?

Validate callback URLs before delivery and refuse private, loopback, link-local, and metadata addresses. Bifrost does this by default: the agent only receives a gateway-owned callback URL and a separate token, and Bifrost delivers to the caller's real endpoint after checking it. The setting that permits private callbacks is meant for development environments and should stay off in production.

Does an agent access grant let the agent call models and tools?

No. An agent access grant only lets a caller reach that agent through the gateway. The agent's own LLM and MCP calls are checked against the provider and tool permissions of whichever credential the agent sends, either the forwarded caller key or the agent's own key. An agent can pass the gateway check and still have a model or tool call denied.

Secure A2A Traffic with Bifrost

A2A security comes down to decisions made once at the gateway: authenticate every call, scope grants per caller, keep credentials and callback secrets away from agents, and keep a correlated record of each task. The Agent Gateway launch post shows these controls beside model and tool governance, and the A2A protocol gateway walkthrough covers registration and transports. To see how Bifrost governs agent-to-agent traffic for your own agents, book a demo with the Bifrost team.