What Is the A2A Agent2Agent Protocol?

The Agent2Agent (A2A) Protocol is an open standard for communication between independent AI agents. Instead of requiring two systems to use the same model, framework or internal tool stack, A2A defines how an agent can publish capabilities, accept work, exchange messages, return artifacts and expose task progress.

The core objects establish several important security boundaries:

A2A supports polling, streaming and push notifications. These delivery modes improve interoperability, but each creates different security considerations: long-lived streams need connection and resource controls, while push notifications introduce an outbound webhook surface that can create SSRF and replay risks if implemented carelessly.

The A2A Security Model: Seven Trust Decisions

A secure A2A architecture should make explicit trust decisions at every stage rather than assuming that protocol compliance equals trust.

This layered model is useful because a failure at one boundary should not automatically compromise the next. For example, a correctly authenticated peer should still be unable to read another tenant's task, and a correctly signed Agent Card should not cause its descriptive text to be treated as trusted LLM instructions.

Secure Agent Discovery and Agent Cards

The Agent Card is the starting point for most A2A relationships. It tells a client where an agent is reachable, which protocol interfaces it exposes, what skills it advertises, and which authentication schemes are required. A common discovery path is the well-known Agent Card endpoint on the agent's domain.

Verify origin and integrity

Use normal server identity verification first: resolve the expected domain securely, require encrypted transport, and validate the server certificate. A2A v1.0 also supports Agent Card signatures using JSON Web Signature. The v1.0 specification uses RFC 8785 JSON canonicalization so a verifier can reproduce the signed representation consistently. If your trust model relies on signed cards, restrict acceptable algorithms and validate the key source rather than blindly following an arbitrary key URL.

Do not publish secrets in a public card

Agent Cards can be publicly discoverable, so treat them as public metadata unless access controls say otherwise. Do not embed bearer tokens, API keys, private endpoints, internal topology or confidential instructions. A2A supports an authenticated extended Agent Card so organizations can expose additional skills or configuration only after the caller has authenticated.

Treat card text as untrusted data

An Agent Card's name, description, skill descriptions and examples are controlled by the remote service. They are useful for selection and UI, but they should never be concatenated into a privileged system prompt as if they were trusted instructions. The official A2A sample repository now explicitly warns implementers to treat Agent Cards, messages, artifacts and task statuses from external agents as untrusted input.

An abridged v1.0 Agent Card can express an interface and a security requirement like this; production cards also include the other required capability and skill fields:

{
  "name": "Partner Claims Agent",
  "supportedInterfaces": [{
    "url": "https://agent.partner.example/a2a",
    "protocolBinding": "HTTP+JSON",
    "protocolVersion": "1.0"
  }],
  "securitySchemes": {
    "partnerMtls": {
      "mtlsSecurityScheme": {
        "description": "Mutual TLS for trusted partners"
      }
    }
  },
  "securityRequirements": [{
    "schemes": { "partnerMtls": { "list": [] } }
  }]
}

The important security lesson is not the exact JSON shape; it is the separation of concerns. The card describes capabilities and security requirements, while policy decides whether your organization trusts the issuer, endpoint, requested scopes and advertised skills.

A2A Authentication and Authorization

A2A relies on established security mechanisms instead of inventing a new identity system. Authentication requirements are advertised in the Agent Card, while credentials are obtained outside the A2A message itself and transmitted using the applicable transport mechanism. The current v1.0 data model supports security scheme types including HTTP authentication, API keys, OAuth 2.0, OpenID Connect and mutual TLS.

Authentication answers who; authorization answers what

Do not stop after validating a token. Every operation needs server-side authorization based on the authenticated principal and the resource being accessed. The current A2A specification explicitly requires task-listing operations to return only tasks visible to the authenticated client and requires authorization errors when a client lacks permission.

For enterprise deployments, bind authorization to multiple dimensions where relevant:

• User and workload identity: know both the end-user context and the calling agent/service where delegation is involved.
• Tenant: ensure task IDs, contexts, artifacts and notification configurations cannot cross tenant boundaries.
• Skill/action: grant only the specific capabilities the caller needs; an agent allowed to query status should not automatically gain a write or payment action.
• Resource: authorize the exact object, account or dataset, not just a broad endpoint.
• Task state: sensitive actions such as cancel, approve, retrieve artifacts or register callbacks may require additional checks.

Avoid the confused-deputy problem

A client agent may have broad credentials to several systems. A malicious or compromised peer can try to persuade it to use those credentials on the peer's behalf. Use audience-restricted and purpose-limited tokens, do not forward upstream bearer tokens by default, and require the downstream action to remain attributable to the user or workload that actually authorized it.

Prompt Injection and Untrusted A2A Content

Network security cannot determine whether a sentence is a legitimate business instruction or a prompt-injection payload. This makes content trust one of the most important A2A-specific concerns.

In August 2026, an open issue in the official A2A samples repository documented a reference-client path that rendered remote Agent Card descriptions and skill text directly into an LLM prompt. The issue is about sample implementation behavior rather than a flaw in the A2A protocol, but it illustrates the trust boundary clearly: remote metadata must not silently become higher-priority model instructions.

Apply the same rule to every remote A2A object:

• Keep system/developer policy separate from Agent Card descriptions, user text and peer-agent messages.
• Mark remote content with provenance so the model and downstream policy layer can distinguish source and trust level.
• Validate URLs, file references and structured fields before fetching or executing anything.
• Do not render HTML, scripts, commands or generated configuration without context-appropriate encoding and validation.
• Require deterministic authorization outside the model before any sensitive action.
• Apply data-loss controls to outbound messages and artifacts so a prompt cannot simply instruct the agent to disclose secrets.

Protect Tasks, Context, Artifacts and Delegation

Keep task identifiers inside an authorization boundary

Task IDs and context IDs organize work; they are not authorization credentials. Treat them as opaque identifiers and still verify that the authenticated principal may access the corresponding task. Avoid predictable IDs where possible and never expose whether another tenant's resource exists through differential error behavior.

Validate artifacts by destination

An artifact can be a harmless text summary in one workflow and an executable input in another. Validation should therefore depend on how the artifact will be consumed. A generated spreadsheet, shell script, SQL statement, URL, file or structured transaction should pass the controls appropriate to that destination before use.

Constrain delegated actions

Agent-to-agent delegation can create long action chains. Define explicit limits for depth, cost, time, data volume, number of downstream calls and irreversible operations. Apply timeouts and circuit breakers so a failed agent does not trigger unbounded retries across the graph.

Use protocol version controls deliberately

A2A 1.0 added explicit version negotiation. Clients should send the intended A2A version and avoid silent downgrade when security or functionality depends on v1.0 behavior. Inventory older v0.3 peers during migration and treat compatibility mode as a managed exception rather than an invisible fallback.

Secure Streaming and A2A Push Notifications

A2A supports real-time streams and HTTP push notifications for long-running tasks. Push notifications deserve special attention because the A2A server becomes an HTTP client that sends requests to a URL supplied by another party.

The official A2A guidance specifically recommends webhook URL validation to prevent SSRF, source authentication, expected-task validation, idempotent processing and rate limiting. These controls should be enforced at the network/application boundary rather than delegated to an LLM.

What to Monitor at Runtime

A2A produces useful security context that should be correlated with normal API telemetry. At minimum, capture the calling identity, agent/interface, protocol version, requested skill or operation, task/context identifiers, destination, response state and policy outcome. Do not log raw secrets or unrestricted sensitive prompt/artifact contents.

For related runtime patterns, see Ammune's guides to AI agent API security risks, API visibility for AI agents, and API runtime security protection.

A2A vs MCP vs Runtime Agent Controls

A2A and MCP solve different interoperability problems and can be used together. The A2A project describes the relationship as horizontal versus vertical: A2A connects one agent to another agent, while MCP connects an agent/model to tools, resources and data.

These layers are complementary. A client agent can call a remote specialist over A2A; that specialist can use MCP to reach tools; both may ultimately call HTTP APIs. Security architecture should preserve identity, policy and traceability across the whole chain rather than securing only one protocol hop.

A2A Security Implementation Checklist

1. Inventory every A2A client, server, supported interface, protocol version, owner and trust domain.
2. Require encrypted transport and normal server identity verification for production communication.
3. Use trusted discovery sources; verify Agent Card signatures when your trust model depends on them.
4. Keep public Agent Cards free of credentials and sensitive internal details; use authenticated extended cards where needed.
5. Treat Agent Card fields, messages, task statuses and artifacts from external agents as untrusted content.
6. Use strong authentication and short-lived credentials; prefer identity-aware mechanisms over shared static secrets.
7. Authorize every task/skill/resource server-side and bind access to tenant, user/workload identity and purpose.
8. Do not forward bearer tokens or elevated credentials to peer agents unless delegation is explicitly designed and constrained.
9. Apply deterministic policy before sensitive downstream actions; do not rely on model instructions as an authorization boundary.
10. Validate file references, URLs, structured data and artifacts according to their destination and execution context.
11. Constrain fan-out, retries, time, cost, task depth and irreversible actions; add human approval for high-impact operations.
12. Protect webhook registration against SSRF and authenticate both outbound notifications and inbound webhook calls.
13. Process asynchronous events idempotently and validate that task IDs belong to the expected caller and tenant.
14. Pin or deliberately negotiate protocol versions; monitor compatibility fallbacks and unexpected downgrade.
15. Collect security telemetry that correlates agent, identity, task, peer, API activity, policy decision and outcome.
16. Red-team prompt injection, cross-tenant access, confused-deputy flows, malicious Agent Cards and webhook abuse before production.

How Ammune Can Support A2A Security

A2A security still requires agent-native controls for identity, Agent Card trust, prompt/data separation, task authorization and delegation. Ammune can complement those controls where A2A interactions and downstream agent actions traverse supported HTTP/API paths.

In those paths, Ammune can be evaluated for API discovery, request and response inspection, sensitive-data visibility, behavioral analysis, runtime policy enforcement and security telemetry. This is useful for connecting the agent-level story to the application-level evidence: which agent-facing API was called, what parameters and data moved, whether traffic deviated from normal behavior, and how the event should be surfaced to security operations.

The strongest architecture uses both layers: enforce agent-specific authority close to the agent, and observe/enforce API behavior at the runtime boundary where agent intent becomes real application traffic.

Primary References

• A2A Protocol Specification — protocol model, operations, interfaces, security requirements and Agent Card definitions.
• A2A Streaming & Asynchronous Operations — push-notification security, SSRF prevention and webhook guidance.
• What's New in A2A v1.0 — v1.0 architecture and Agent Card signing dependencies.
• Official A2A Samples — implementation examples and explicit warning to treat external agent data as untrusted input.
• Linux Foundation A2A Project Announcement — governance and project background.

A2A Agent2Agent Protocol Security FAQ

Build A2A Trust as a Chain, Not a Single Check

A2A makes cross-agent interoperability much easier, but every new peer also creates a new trust boundary. A secure design verifies the discovered agent, authenticates callers, authorizes each task and resource, treats peer content as untrusted, constrains delegation, protects asynchronous callbacks and observes what the agents actually do at runtime.

The practical goal is not to make agents trust one another automatically. It is to make every delegation explainable, least-privileged and revocable before an AI-generated decision becomes a real action.