Agent-to-Agent (A2A) communication lets one AI agent invoke another as part of a larger workflow — passing tasks, context, and results across a network of specialized agents. Done well, it multiplies what each agent can accomplish. Done carelessly, it becomes an unaudited call graph where a single compromised agent can reach everything else. Governing A2A means every hop is authenticated, scoped, and logged, regardless of how deep the chain runs. For a comparison of A2A and MCP and where each protocol fits, see A2A vs MCP: what's the difference.
Why Uncontrolled Agent-to-Agent Calls Are a Risk
When agents call each other without a governance layer, several problems compound quickly. There is no natural boundary between what one agent is allowed to ask of another. There is no record of which agent initiated a chain, which intermediate agents forwarded it, or what data moved between them. And there is no enforcement point where a budget, a content rule, or an organizational policy can intervene.
The risk is not hypothetical. An agent with legitimate access to a document store can forward retrieved content to a second agent that sends email. If neither agent has scoped permissions, and there is no guardrail on outbound content, a single misconfigured workflow can silently exfiltrate data through a chain of individually trusted agents. This is one of the core scenarios covered in data exfiltration risks in agentic AI.
Governed A2A treats every inter-agent call as a first-class security event — subject to the same identity checks, scope constraints, and audit logging as any external API call.
Agent Cards: A Structured Identity for Discovery
Before one agent can call another, it needs to know the target agent exists, what it can do, and whether it is permitted to call it. Agent cards provide this structured identity.
An agent card is a versioned descriptor that captures the agent's capabilities, its endpoint URL, and the scopes it exposes to callers. When A2A communication is enabled for an agent, the platform generates the agent's private endpoint and, for publicly visible agents, a public endpoint — then stamps an initial card version. Any caller that wants to invoke the agent fetches or references that card to understand what the agent offers and how to reach it.
Card versioning matters because agents evolve. When an agent's capabilities change, its card version advances. Callers can detect the mismatch and decide whether to re-validate the connection before proceeding. This prevents silent drift, where a caller assumes a capability that the target agent no longer supports.
Scoped Identity on Every Hop
Governed A2A is not about giving agents a shared credential pool. Each agent authenticates with its own identity, carrying only the scopes its configuration grants it. When agent A calls agent B, the call arrives with a verifiable identity, and agent B's endpoint validates that identity before processing the request.
This is the practical application of least privilege at the agent level. Agent A might have permission to invoke agent B's summarization capability but not its data-write capability. The enforcement happens at the connection, not by convention. A caller that does not hold the right scope for a given operation is rejected, regardless of how trusted its source organization is.
Praesidia manages this by treating each agent-to-agent link as an explicit connection: a named, policy-bound relationship between a caller and a target agent. The connection records which capabilities are permitted, what spend limits apply, and whether guardrails are active for that edge. Access to A2A communication is scoped to the organization's plan, so the number of agents that can participate stays within what has been provisioned.
Bidirectional Guardrails on the Call Path
Content guardrails apply to inter-agent calls just as they apply to user-facing interactions. An agent passing a large block of retrieved text to a second agent is a data flow that can carry PII, credentials, or policy-violating content. Guardrails on the A2A edge intercept that flow and can block, redact, or flag it before it reaches the target.
Bidirectional means the guardrails cover both the outbound request from the calling agent and the inbound response from the target. This is significant because responses from a downstream agent can contain data the calling agent should not have received, either because the target agent over-fetched or because the original request was crafted to extract more than intended.
Spend limits work the same way. Each connection carries a configurable cost cap. If an A2A call chain would push the calling agent — or the workflow it is part of — over the configured threshold, the call is blocked before it reaches the target. This prevents a runaway loop between two agents from producing an unbounded bill.
Disable and Reconciliation
When A2A communication is disabled for an agent, the platform does not simply remove the endpoint. It reconciles dependent connections — any connections that pointed to this agent as a target are marked disconnected. Callers that attempt to reach the agent through a stale connection get a clear failure rather than a silent timeout or, worse, a successful call to an endpoint that is no longer governed.
This reconciliation step is important for operational safety. In a real agent fleet, agents are updated, retired, and replaced frequently. Without automatic connection reconciliation, disabling an agent can leave dangling references in workflows and other agents' configurations, creating both reliability problems and potential security gaps if the endpoint URL is later reused.
Audit Visibility Across the Call Graph
Every A2A call is an auditable event. The audit trail captures which agent initiated the call, which target agent received it, which connection was used, and what the outcome was. For chains involving multiple hops, each hop produces its own audit record, so you can reconstruct the full execution path after the fact.
This matters for compliance and incident response. If an audit surfaces an unexpected data flow, you can trace it back through the call graph to the originating agent and the workflow that invoked it. Audit logs are append-only and hash-chained, so the record cannot be quietly modified to remove evidence of a misbehaving agent. For a deeper look at how audit log integrity is enforced, see tamper-evident audit logs with cryptographic proofs.
Real-time visibility complements the audit trail. State changes — when communication is enabled or disabled for an agent — are reflected in operational dashboards immediately, so the displayed state of the A2A network stays current.
Public vs Private Agents in A2A
Not every agent should be reachable from outside the organization. Praesidia distinguishes between private agents, which have a single private endpoint URL accessible only within the organization's network, and public agents, which additionally have a public endpoint URL that can be reached from external callers — including federated agents in other organizations.
Public endpoint URLs are validated before being stored. This prevents an operator from inadvertently registering an internal network address as a public endpoint, which could expose internal services to external A2A callers. The validation process rejects addresses that would route to private or internal infrastructure.
The distinction between private and public agents gives organizations fine-grained control over their A2A exposure. An internal orchestration agent that coordinates other internal agents does not need a public URL. An agent that is part of a published integration or a cross-organization workflow does.
Common questions
Does enabling A2A communication for an agent automatically allow any other agent to call it?
No. Enabling communication generates the agent's endpoint and card, but access is still controlled by connections. A calling agent must have an explicit, policy-bound connection to the target agent. Without that connection, the call is rejected regardless of whether the target agent has communication enabled.
What happens to active A2A connections if an agent is disabled mid-workflow?
When communication is disabled, the platform immediately marks all connections targeting that agent as disconnected. Any in-flight call that has not yet completed will fail. Workflows that depend on the agent will need to handle the failure — either through built-in retry logic or by escalating to an operator. The audit trail records the disable event and the connection state changes.
How do spend limits work across a chain of A2A calls?
Each connection in the chain carries its own spend limit, enforced independently at that edge. The calling agent's budget is also tracked at the workflow or organization level. If any limit in the chain is exceeded, the call is blocked at the point of enforcement. There is no single global counter; the controls are layered so that a limit can be applied per connection, per agent, or per workflow run. See budgets and quotas: preventing runaway agent costs for more on budget policy configuration.
Governed A2A communication is how agent networks scale without becoming ungovernable. Praesidia is designed to make every inter-agent call a policy-enforced, audited event — with scoped identity, content guardrails, and spend controls on every hop — so you can build agent workflows that are both powerful and accountable.