---
description: "A2A security guide: the threat model for agent-to-agent traffic, what the A2A spec requires, and how to authenticate and authorize agents at a gateway."
title: "A2A Security: Authenticating and Authorizing Agent Traffic"
image: https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w1200/2026/10/a2a-security-authenticating-and-authorizing-agent-traffic-bifrost-1920x1080.png
---

Try Bifrost Enterprise free for 14 days. [Request access](https://www.getmaxim.ai/#enterprise-trial)

**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](https://www.getmaxim.ai/), the [open-source AI gateway for models, tools, and agents](https://github.com/maximhq/bifrost) 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](https://www.getmaxim.ai/articles/a2a-protocol-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](https://www.getmaxim.ai/articles/agentic-ai-security/); 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.

![A2A request path from calling application through agent card discovery and the remote agent to its model, tool, and callback traffic, with the threat at each hop shown beneath it](https://articles-images-cdn.t3.tigrisfiles.io/diagrams/a2a-security/a2a-security-threat-surface.png)

*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](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/), 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](https://www.getmaxim.ai/resources/ai-security) 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](https://a2a-protocol.org/latest/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](https://csrc.nist.gov/pubs/sp/800/207/final) principle of authenticating and authorizing before any session to a resource, with no implicit trust from network location. The [Agent Gateway in Bifrost](https://docs.getbifrost.ai/features/agent-gateway/overview) 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.

![Four A2A authentication boundaries: the app authenticates to Bifrost, Bifrost authenticates separately to the card host and the agent, and the agent calls Bifrost for models](https://articles-images-cdn.t3.tigrisfiles.io/diagrams/a2a-security/a2a-security-authentication-boundaries.png)

*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.*

| Boundary | What authenticates the call | Where it is configured |
| --- | --- | --- |
| 1. Caller to Bifrost | Virtual key, or an identity-provider token in Bifrost Enterprise | Sent by the calling application |
| 2. Bifrost to card host | Headers or OAuth 2.0 client credentials, optional custom CA or mTLS | Card fetch options in the registration |
| 3. Bifrost to agent | Credentials selected from the card's requirements, or set manually | Request authentication in the registration |
| 4. Agent to Bifrost | The forwarded caller credential, or the agent's own key | The agent server's outbound LLM and MCP requests |

[Virtual keys](https://docs.getbifrost.ai/features/governance/virtual-keys) are the standard caller credential; with SSO configured, Bifrost Enterprise also accepts identity-provider tokens through [user provisioning with OIDC and SCIM](https://docs.getbifrost.ai/enterprise/user-provisioning). The [agent authentication settings](https://docs.getbifrost.ai/features/agent-gateway/authentication) 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](https://docs.getbifrost.ai/features/agent-gateway/access-control) 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](https://docs.getbifrost.ai/enterprise/access-profiles) lists agents and is assigned to users, roles, IdP groups, teams, business units, or customers. Expired profiles grant nothing.
- **Projects (Enterprise).** A [project](https://docs.getbifrost.ai/enterprise/projects) 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.

```json
{
  "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](https://www.getmaxim.ai/ai-governance) and the [governance resource hub](https://www.getmaxim.ai/resources/governance) 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.

![Credential forwarding flow: Bifrost validates the caller's key and agent grant, then strips the credential by default or forwards it to a trusted agent's model calls](https://articles-images-cdn.t3.tigrisfiles.io/diagrams/a2a-security/a2a-security-credential-forwarding.png)

*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](https://www.getmaxim.ai/articles/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](https://docs.getbifrost.ai/mcp/filtering), which are deny-by-default on a virtual key and enforced by the [MCP gateway](https://www.getmaxim.ai/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.

![A2A push notification path: the agent posts to Bifrost, which checks the token, queues the update durably, checks the callback destination, and delivers it to the app](https://articles-images-cdn.t3.tigrisfiles.io/diagrams/a2a-security/a2a-security-push-callback.png)

*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](https://docs.getbifrost.ai/features/agent-gateway/push-notifications) 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](https://docs.getbifrost.ai/features/agent-gateway/transports-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](https://docs.getbifrost.ai/enterprise/guardrails) 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](https://www.getmaxim.ai/ai-guardrails) covers rule design. Bifrost also rejects requests for A2A extensions the card did not declare.

**A correlated audit trail.** [Agent Logs](https://docs.getbifrost.ai/features/agent-gateway/observability) 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](https://docs.getbifrost.ai/features/agent-gateway/connectors) 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](https://docs.getbifrost.ai/enterprise/audit-logs), 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.

| Threat | A2A spec guidance | Bifrost control at the gateway |
| --- | --- | --- |
| Agent impersonation | Authenticate every request against declared `securitySchemes` | Virtual keys or IdP tokens; `enforce_auth_on_inference` rejects anonymous calls |
| Card spoofing | Optional JWS card signatures; TLS server verification | Card origin only by default; approved extra origins; Private Network Allowlist; no plaintext downgrade |
| Over-broad access | Authorization check on every operation | Per-key grants, `allow_by_default` off, access profiles and projects in Enterprise |
| Credential leakage | Bind in-task credentials to the requesting agent | Caller credential stripped unless forwarding is on; agent credentials held at the gateway |
| Callback abuse and SSRF | Reject private, localhost, and link-local webhook URLs | Gateway-owned callback and token; private and loopback callbacks blocked by default |
| Replayed tasks | Idempotent callback processing | No replay of ambiguous unary operations or streams; at-least-once callbacks with retry records |
| Injected content | Validate input; limit sizes and media types | Guardrails on the agent's LLM and MCP calls; undeclared extensions rejected |
| Missing audit trail | Log authentication failures and denials | Agent Logs with task correlation; telemetry export; HMAC-signable admin audit logs |

The [AI observability page](https://www.getmaxim.ai/ai-observability) 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](https://www.getmaxim.ai/enterprise).

## 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](https://www.getmaxim.ai/articles/mcp-server-authentication-how-to-secure-agent-tool-access/). 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](https://www.getmaxim.ai/bifrost/blog/introducing-agent-gateway-in-bifrost-one-gateway-for-models-tools-and-agents) shows these controls beside model and tool governance, and the [A2A protocol gateway walkthrough](https://www.getmaxim.ai/articles/a2a-protocol-gateway/) covers registration and transports. To see how Bifrost governs agent-to-agent traffic for your own agents, [book a demo](https://www.getmaxim.ai/book-a-demo) with the Bifrost team.

## Read next

[![AI Agent Registry: How Teams Discover and Govern Internal Agents](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/ai-agent-registry-how-teams-discover-and-govern-internal-age-bifrost-1920x1080.png) An AI agent registry is the system of record for the agents a company runs, from identity and skills to endpoints, auth and who may call them. This guide covers discovery models, a field checklist, how it differs from an MCP registry, and how Bifrost governs registered A2A agents.](https://www.getmaxim.ai/articles/ai-agent-registry/)

[![Agent Communication Protocols Compared: A2A, MCP and ACP](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/agent-communication-protocols-compared-a2a-mcp-and-acp-bifrost-1920x1080.png) An agent communication protocol defines how AI agents talk to tools, to other agents, and to users. This guide compares MCP, A2A and ACP, explains what happened to ACP, covers AG-UI and AP2, and shows how to govern them in production.](https://www.getmaxim.ai/articles/agent-communication-protocols/)

[![A2A vs MCP: Differences, When to Use Each, and How to Run Both](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/a2a-vs-mcp-differences-when-to-use-each-and-how-to-run-both-bifrost-1920x1080.png) A2A vs MCP is a question of direction: MCP connects an agent to its tools and data, while A2A connects independent agents to each other. This guide compares their message models, transports, auth, discovery and task handling, and shows how to govern both at one gateway.](https://www.getmaxim.ai/articles/a2a-vs-mcp-2/)

## More in Agent Gateway

[![OpenAI Agents SDK Through a Gateway: Models, Budgets, MCP](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/openai-agents-sdk-through-a-gateway-models-budgets-mcp-bifrost-1920x1080.png) The OpenAI Agents SDK sends every model call through an OpenAI client, so one base URL change routes an agent workflow through an AI gateway. This guide shows the working code for Bifrost, then adds non-OpenAI models, failover, per-agent budgets, MCP tools, and tracing.](https://www.getmaxim.ai/articles/openai-agents-sdk-ai-gateway/)

[![Agentic Mesh vs Agent Gateway: Multi-Agent Architecture](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/agentic-mesh-vs-agent-gateway-multi-agent-architecture-bifrost-1920x1080.png) An agentic mesh is a distributed architecture in which many AI agents discover and call each other under shared governance. This guide compares the mesh with the agent gateway pattern, covers hybrid designs, and gives a decision table for platform teams.](https://www.getmaxim.ai/articles/agentic-mesh-vs-agent-gateway/)

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "publisher": {
        "@type": "Organization",
        "name": "Maxim Articles",
        "url": "https://www.getmaxim.ai/articles/",
        "logo": {
            "@type": "ImageObject",
            "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w256h256/2025/08/thumbnail.png",
            "width": 60,
            "height": 60
        }
    },
    "author": {
        "@type": "Person",
        "name": "Kuldeep Paul",
        "image": {
            "@type": "ImageObject",
            "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2025/08/1727978381919.jpeg",
            "width": 800,
            "height": 800
        },
        "url": "https://www.getmaxim.ai/articles/author/kuldeep/",
        "sameAs": []
    },
    "headline": "A2A Security: Authenticating and Authorizing Agent Traffic",
    "url": "https://www.getmaxim.ai/articles/a2a-security/",
    "datePublished": "2026-10-27T19:10:00.000Z",
    "dateModified": "2026-10-29T19:11:08.000Z",
    "image": {
        "@type": "ImageObject",
        "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w1200/2026/10/a2a-security-authenticating-and-authorizing-agent-traffic-bifrost-1920x1080.png",
        "width": 1200,
        "height": 675
    },
    "keywords": "Agent Gateway",
    "description": "A2A security is the set of controls that authenticate agents, authorize which caller may reach which agent, and keep credentials, callbacks, and audit trails safe. This guide maps eight A2A threats to spec requirements and to the controls Bifrost applies at the gateway.\n",
    "mainEntityOfPage": "https://www.getmaxim.ai/articles/a2a-security/"
}
```