Teams exposing an agent to callers outside their own system, or calling one.
What to verify about a remote agent before letting your agent depend on it.
The control gap
A2A addresses agent-to-agent communication, where MCP addresses agent-to-tool. The security question changes shape. With a tool you at least control the server; with a remote agent you are trusting a declaration published by someone else about its own capabilities, and an Agent Card is a self-description. It says what the agent claims to do and how to authenticate. Neither claim is verified by the protocol.
What good looks like
Remote agents are treated as untrusted callees and untrusted callers, with their declared capabilities pinned, their authentication requirements met explicitly, and every delegated action authorized on your side.
- Fetch and pin the Agent Card. A capability set that changes after review is a change that needs reviewing.
- Serve your own card over TLS from a path you control, and keep it consistent with what the agent will actually accept.
- Authenticate in both directions, and do not rely on network position for either.
- Authorize every task a remote agent asks you to perform as if a user had asked, because from your side that is exactly what it is.
A production workflow
- Discover the remote agent's card and record its declared skills and authentication requirements.
- Establish credentials for that specific peer, scoped to the tasks you intend to delegate.
- Send tasks with your own agent identity and the delegated user carried as context.
- Evaluate every inbound task against policy before it reaches a tool, regardless of which agent sent it.
Evidence to require
- The Agent Card as fetched, with its hash and the date it was reviewed.
- Changes to a peer's declared skills or authentication requirements since review.
- Tasks sent and received per peer, with the delegated user on each.
- Inbound tasks denied by policy, and which peer sent them.
Buyer checklist
- Which remote agents can currently send your system work, and who approved each?
- Is the Agent Card pinned, or fetched fresh and trusted every time?
- Does an inbound task face the same authorization as a direct user request?
- Can you attribute an action to the originating human across two agent hops?
Practical answers
Common implementation questions
Is A2A a competitor to MCP?
They address different edges. MCP connects an agent to tools and data; A2A connects agents to each other. A system can use both, and the authorization questions compound rather than cancel.
What is the main risk in an Agent Card?
That it is self-asserted. It tells you what the agent says it does. Treat it as configuration to review and pin, not as an attestation, and keep your own authorization independent of what the card claims.
Does Endram support A2A?
Endram authorizes tool calls, so its role is on your side of the boundary: every action a remote agent's task leads to is evaluated before it executes, with the peer and the delegated user in the decision record.