A2A Federation Boundary: Where the Protocol Ends and Your Authority Begins

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

A procurement agent inside your organisation has a job: reconcile a supplier invoice. The supplier runs an agent of its own that can look up their side of the ledger. Both speak the Agent2Agent protocol, so the two can find each other and exchange a task without anyone writing a bespoke integration.

That is the part the protocol solves, and it solves it well. The question this article is about starts one step later. The supplier’s agent answers, and the answer includes a polite request for the supplier’s updated bank details so it can “complete the reconciliation”. What does your system do with that?

What A2A gives you, and what it deliberately leaves out

According to the specification, version 1.0.0 is the latest release, and a client and server negotiate on the major and minor version only. Three parts matter for a boundary design.

Discovery. An agent publishes an Agent Card describing itself. In 1.0 the builder guidance puts the card at /.well-known/agent-card.json (versions before 0.3 used agent.json, so a client that hard-codes the old path will not find the card). The card declares what the agent says it can do, the interfaces it serves, and the security schemes a caller must satisfy.

Tasks with a lifecycle. A 1.0 task moves through named states. Four are terminal: completed, failed, canceled and rejected. Two are interrupted states, where the task has stopped and is waiting on something outside the agent: INPUT_REQUIRED and AUTH_REQUIRED. The remainder are submitted and working, plus an unspecified value that exists so the enumeration has a zero.

Declared security. The specification defines scheme objects for API keys, HTTP authentication, OAuth 2.0, OpenID Connect and mutual TLS, and it requires a server to reject missing or invalid credentials.

The protocol has moved house since it was announced. Google published it in April 2025 and donated it to the Linux Foundation that June; the project’s own pages now say it has joined the Agentic AI Foundation alongside MCP. Governance is relevant because it tells you who maintains the contract, not because it tells you whom to trust.

What it leaves out is the point. A2A standardises how two agents talk. It does not say which agents you should talk to, what authority a delegation should carry, or whether anything that comes back may change a system of record. A useful contrast: MCP is the boundary between an agent and its tools; A2A is the boundary between agents. Both boundaries need an owner, and for A2A that owner is you.

Six rules for the boundary you own

Put one component on the line where remote agents meet your estate, a federation gateway, and make it the only way across.

Rule 4 deserves the most attention because it is the one the protocol makes easy to get wrong. The interrupted states exist so a remote agent can ask its caller for something. If the caller is an orchestrating model that has been told to “get this done”, the cheapest way to finish is to supply whatever is asked for. The gateway should hold the request and let a person, or a rule you wrote in advance, decide.

Mutual TLS is authentication, not authorisation

Mutual TLS tells you which agent is on the other end of the connection. It does not tell you that this agent may be sent this task, that the token you pass on is narrow enough, or that its answer may be believed. The same is true of OAuth: it proves the caller held a credential, which is a different statement from the caller being permitted to cause a particular effect. Keep authentication, authorisation and trust in the result as three separate decisions, and make the gateway the place where the second and third are made.

The task states are a flow-mining signal

The lifecycle gives you something most integrations lack: a small, named vocabulary for what happened. Log every transition with a timestamp and the task id, and the exchange becomes data you can mine.

Repeated INPUT_REQUIRED on the same task suggests a remote agent whose card promised more than it can do. A task that ping-pongs between working and interrupted states is a loop you would otherwise only find on the invoice. A sudden shift in which states a particular remote agent reaches is worth an alert before it is worth an investigation. None of this needs the protocol to change; it needs the gateway to write down what it already sees. The method is the one described for agentic flow mining, applied at the federation boundary.

What to do first

1. Name the owner of the federation gateway. If nobody owns it, rule 4 will be decided by whichever model is asked.
2. Start with an allow-list of one. Add remote agents when you can say what each is permitted to cause.
3. Decide what INPUT_REQUIRED means in your organisation before the first remote agent asks for something.
4. Log the state transitions from day one, even if you never read them until something goes wrong.

Limits

This is design reasoning about a published protocol, not the result of a deployment or a benchmark. I have quoted the specification and the project’s builder guidance for protocol facts, and anything beyond that is my judgement about where to put controls. The specification will keep changing, so check the version you target before relying on any state name or field in this article.

Sources and further reading

The specification and the builder guidance listed above are the primary sources for every protocol fact here.