An agent from another organisation can have a real identity and still have no business making the decision it is asking to make.
That sounds obvious until an architecture diagram compresses discovery, authentication and permission into an arrow labelled “trusted agent”. The arrow has acquired an impressive job description. Nobody has checked its references.
Cross-organisation agent identity needs separate answers to three questions: what service have we found, which peer are we actually talking to, and what may that peer do in this transaction? A2A and workload identity can help with different parts. Neither should be asked to invent the commercial agreement.
Finding an agent is not accepting its authority
Imagine a fictional retailer, Cedar, asking a freight partner for delivery quotes. Maya asks Cedar’s purchasing agent to compare options for consignment C-731. The freight partner’s agent advertises both quotation and booking capabilities. Maya has requested comparison only.
An A2A Agent Card helps the purchasing agent discover the service and understand how to interact with it. The A2A discovery guide describes published cards, curated registries and direct configuration. This is useful metadata. It does not turn every advertised skill into permission for this caller.
The current A2A specification separates authentication from the receiving server’s own authorisation policy. It also supports signed Agent Cards. A verified signature can protect the card’s integrity and provenance when the verifier has an appropriate trusted key relationship. It does not prove that the provider deserves access to Cedar’s customer records or that Maya approved a booking.
Cedar should therefore treat the card as a candidate service description. Onboarding determines whether the endpoint, provider and offered operation are acceptable. Credential validation establishes the peer for a request. Business policy determines what that peer may do. There is no useful shortcut in calling all three “trust”.
The passport is for the workload
Suppose the two organisations already operate compatible workload identity infrastructure. They could use SPIFFE identities to authenticate services across their environments. This is an architectural option, not an A2A requirement.
A SPIFFE ID identifies a workload within a trust domain. An SVID is the verifiable identity document used to present that identity. The SPIFFE identity specification is explicit that trust-domain names are not globally registered legal identities. A convincing name does not independently establish ownership of a company.
For our example, spiffe://freight.example/agents/quote-service could be the identity Cedar expects. The URI is illustrative. Cedar authenticates that freight endpoint before sending permitted data. In the other direction, the freight endpoint authenticates Cedar’s purchasing-agent caller before evaluating its request. Cedar would still need an onboarding process that associates the partner with an approved trust domain, trusted keys and the permitted service. A string supplied by the remote model should not create that association.
SPIRE is an implementation that uses node and workload attestation to issue identities against configured conditions. Those conditions can relate to the environment and process running the workload. This gives a stronger basis for service identity than a self-declared name in a message.
It does not establish that the model’s next answer is correct, that every instruction it follows is benign, or that Maya approved a particular shipment. Attestation checks what its configured evidence can support. It is not a personality assessment for software.
Federation admits an identity, not every request
SPIFFE federation provides a way to recognise identities from another trust domain through the relevant trust bundles. The relationship still requires explicit trust configuration and ongoing operation. It is not permission to accept every certificate from every organisation a partner has ever met.
For the proposed freight integration, I would allow the specific quote-service identity to receive a limited consignment description and return quote options. I would not grant a whole foreign trust domain access to all customer shipments simply because bundle exchange works.
The policy should also distinguish a service identity from the business context of a request. The workload may serve multiple customers. A valid connection from that workload does not tell Cedar which customer or consignment the current operation concerns. Those relationships need trusted mapping and object-level checks.
This matters in the other direction too. The freight server should not treat Cedar’s authenticated agent as authorised to inspect every task it has ever created for every client. Task identifiers help coordinate work. They do not replace a permission check on retrieving, updating or cancelling that work.
Keep the user’s mandate visible without copying every secret
Maya asked for quotes. The requesting agent should carry enough trusted context for the receiving system to evaluate that bounded request. The exact representation depends on the agreed identity and authorisation architecture. A free-text sentence saying “Maya authorised everything” is not a delegation mechanism.
The proposed application record would connect the authenticated caller, customer relationship, consignment reference, requested operation and applicable business approval. It would identify which evidence is checked locally and which assertion comes from a trusted issuer. This is a design proposal for the scenario, not a new field set mandated by A2A.
If the remote agent discovers that booking requires additional authority, the workflow should stop at that boundary and obtain it through the agreed process. The current A2A specification expressly says that entering an authorisation-required task state is not itself authorisation. A new state label cannot sign a purchase order.
Keep the booking operation separate from quotation in both product language and enforcement. Otherwise “find the best option” can quietly become “commit to whichever option the model prefers”. That is a product decision hiding inside a verb.
The agent identity record can document the operating relationship. The action-boundary article explains why documentation still needs an enforcing component.
A useful partner test includes a legitimate denial
At the freight endpoint, I would test an authorised quote request from Cedar’s recognised purchasing-agent identity, then change one condition at a time. Ask it to book without the required mandate. Ask for another customer’s consignment. Present a different workload identity from the same trusted domain. Substitute an unapproved endpoint in the discovered card.
The expected outcomes belong to the proposed policy: the valid quote succeeds; the other requests stop at their relevant boundary. These are fictional acceptance cases, not measured production results. Inspect the protected data or business effect as well as the response, so a cheerful denial message cannot conceal an operation that already happened.
Test the asynchronous surfaces too. A task created for one relationship must not become visible to another merely because its identifier was shared. If callbacks or downloads are used, their destinations and access checks need the same attention as the initial request. The most attractive demo often ends before that part begins.
You may not need a federation programme for this
There is a reasonable simpler answer. Two organisations integrating a narrow service may already have an effective OAuth or mutual-TLS arrangement. They do not need to deploy SPIRE merely to say their agents have identities. Operationally maintained credentials and explicit application permissions are more valuable than a fashionable identity layer nobody knows how to run.
SPIFFE becomes interesting where workload identity across environments is a real requirement and both parties can operate the trust relationship properly. Consider who maintains the mappings, reviews changes and handles a partner incident. Those responsibilities remain human even when the requests are automated.
Preserve enough audit evidence to connect the recognised peer to the authorised operation. Do not call that evidence proof of every internal step the other organisation took.
I would welcome a partner agent that can explain its capabilities clearly. I would trust the integration more when it can also receive a perfectly valid request from a perfectly real peer and say, correctly, “you cannot do that here”.
