When Your Agent Hands Off to Another Company's Agent: Accountability in Cross-Organization A2A

A procurement agent at your company needs a freight quote. It discovers a carrier’s agent through an A2A agent card, sends a task with the shipment details, and gets a price back in seconds. Nobody at either company was involved. It is the demo everyone wants. It is also a handoff of your data, and possibly your authority, to a system you do not operate, under terms nobody reviewed.

Inside one company, an agent that misbehaves is your problem and your logs. Across a company boundary it is a shared problem with only half the evidence on your side. This post covers what changes when the A2A protocol crosses an organization line, and what you can put in place so the handoff is something you can defend later.

What A2A does and does not settle

A2A standardizes how agents discover each other, describe their skills, and exchange tasks and results. The agent card declares an endpoint, skills and the authentication schemes the remote agent accepts. That solves interoperability.

It does not decide:

• Which of your data the remote agent should receive. The task payload is whatever your agent put in it.
• Whose authority the task carries. Authentication proves who is calling. It does not say what the caller may commit your company to.
• What the remote side keeps. Retention, training use and onward delegation are the other organization’s policy, not part of the message.
• Who investigates. If the result was wrong or the data leaked, each side holds a different slice of the record.

Those are governance questions, and they are easy to skip because the protocol works fine without answering them.

Four ways cross-organization handoffs go wrong

Over-sharing in the task. An agent builds the task from its context window. If the context contains a customer record, a contract or an internal note, any of it can end up in the payload. This is the data egress problem in the outbound direction.

Authority laundering. The remote agent acts on a request that looks authorized because it came through a trusted channel, while the original human never approved that scope. The delegation chain is only as good as what each hop actually verifies.

Re-delegation you cannot see. The carrier’s agent hands part of the job to a subcontractor’s agent. Your data now sits two hops past anyone you vetted.

Asymmetric evidence. Your log says “task sent, result received”. Theirs says something else, or nothing. When the two disagree, the side with the better record wins the argument.

A governance model that fits on one page

1. Classify before you send. Decide which data classes may leave the company in an A2A task and which may not. Enforce it on the outbound call, not in a policy PDF.
2. Bind each task to a person’s authority. The task should carry who delegated it and for what. Our post on power of attorney for AI agents covers why scope and expiry belong in the credential, not the prompt.
3. Require approval for first contact and for commitments. A new counterparty, or any task that commits money or sends personal data, waits for a human. Approval fatigue is real, so keep the rule narrow.
4. Pin the counterparty. Verify the agent card you approved is the card you are talking to. Agent card spoofing and skill poisoning both exploit trust that was granted once and never rechecked.
5. Write your own record. Log the full outbound task, the decision that allowed it, and the result, on your side, in a form you can stand behind in an incident.
6. Carry a trace ID across the boundary. Without trace propagation, correlating your record with theirs is manual work done under pressure.

Credentials: the part that must never cross

The remote agent will need to authenticate to you for callbacks, and your agent may need credentials to reach it. A common shortcut is to put a long-lived API key in the agent’s configuration and let it go. Do not let the key travel inside task payloads, and do not let the model hold it at all.

Prefer short-lived credentials resolved at call time, bound to the destination host so they cannot be replayed elsewhere (see host-bound credentials). Treat any push-notification webhook the remote side calls as an inbound surface that needs its own authentication.

The business case

Cross-company agents are where the commercial upside is, and where a security review will stall the project if you cannot answer a few questions in writing: what data leaves, under whose authority, with what approval, and where is the record. A team that can answer those ships the integration. A team that cannot waits for legal, or ships it without asking and finds out later.

Fullmakt sits between your agents and the systems and agents they call, so the controls above are enforced rather than described:

• Credentials by reference. Agents hold a reference, not the secret. Fullmakt resolves it when the call is made and scrubs resolved credential values from captured output.
• Policy per call. Rules evaluate each outbound request, including which destinations are reachable and which calls need approval.
• Human approvals. Calls that need a decision are held until a person approves or rejects them, and the decision is recorded.
• Your own audit trail. Agent, delegating user, decision and outcome are recorded on your side, with sensitive fields kept out of stored arguments, so a dispute starts from your evidence and not theirs.

FAQ

Is A2A authentication enough for cross-organization use?

It tells you who the caller is. It does not limit what data you send, confirm that a person authorized the scope, or give you a record. Those need controls on your side of the call.

Should we let our agent discover counterparties on its own?

For new counterparties, no. Let discovery propose and a person approve. Once a counterparty is approved, pin it and let routine tasks run without asking again.

What should a contract with the remote party cover?

Retention, training use, onward delegation to subcontractor agents, breach notification and log access. The protocol carries none of these, so they have to be written down.

Who is liable if the remote agent misuses the data?

That depends on your agreements and jurisdiction, and we are not giving legal advice. What you can control is whether you can show what you sent, why it was allowed, and who approved it. See also GDPR data ownership in A2A delegation.

Does this slow agents down?

Policy checks on a call are cheap. The human step applies only to first contact and to commitments, which is where a pause is worth having.

See how Fullmakt brokers credentials for AI agents or browse the Fullmakt blog.