Cross-org, no shared AS: accountability layer for first-contact A2A transactions

[kevin-biot]

We are working on an early open standard called OBO (On Behalf Of) that attempts to address a specific gap we have not seen covered in A2A or adjacent efforts: cross-organisational, cross-border agent transactions where no shared authorisation server exists and the two agents have never previously interacted.

We come to this humbly — OBO is a working draft, not a finished standard — and we would genuinely welcome input from the A2A community on whether and how it composes.

The gap we are trying to fill

A2A solves agent discovery and task routing cleanly. The Agent Card, well-known URI discovery, and task lifecycle model are well designed.

What A2A currently delegates or leaves open:

• Principal authority chain — who delegated authority to the calling agent? Which human or legal entity? Under what governance framework?
• Cross-org first-contact authentication — when two agents meet with no shared AS and no prior relationship, OAuth delegation requires federation that doesn't exist. The Agent Card's well-known URI is close to DNS anchoring but the authority verification path is not specified.
• Tamper-evident post-task evidence — immutable terminal task states are a good lifecycle model. They are not a cryptographically sealed, offline-verifiable record that a regulator, counterparty, or court can consume without calling anyone.
• Legal entity accountability — which organisation is liable if the task causes harm? The agent is not a legal person. The operator — the company that deployed it — is.

Two patterns, not one

We think A2A naturally supports two deployment patterns:

Pattern 1 — within a trust domain: Shared AS, pre-existing federation, enterprise deployment. OAuth, mTLS, existing A2A security schemes. Well solved. No change needed.

Pattern 2 — across trust domains: Cross-org, cross-border, no shared AS, first-contact. The calling agent needs to prove authority to a counterparty that has never met it, under a governance framework the counterparty can verify offline, producing a tamper-evident record of what was authorised and what executed.

Pattern 2 is the gap OBO attempts to fill.

Proposed composition

OBO defines two artefacts:

• OBO Credential (pre-task): principal_id, agent_id, operator_id, action_classes, intent_namespace, governance_framework_ref — DNS-anchored, offline-verifiable
• OBO Evidence Envelope (post-task): intent_hash, action_class, outcome, evidence_digest — tamper-evident sealed record

The composition with A2A would be lightweight:

A2A Agent Card      → agent discovery, capability advertisement
A2A task routing    → task assignment, lifecycle (unchanged)
OBO Credential      → carried in A2A task metadata, principal authority chain
                      verified via DNS, no shared AS required
OBO Evidence        → seals what the A2A task executed, post-task
A2A task.id         → referenced in OBO evidence envelope as correlation anchor

The OBO Credential could be carried as an A2A extension, referenced in task metadata, or declared as a security scheme variant in the Agent Card. We are open to whichever composition point makes most sense to the A2A community.

Where OBO is today

OBO is a working draft RFC with a running Go reference implementation exercised end-to-end. It is early. We are not claiming it is finished — we are claiming the gap is real and we would welcome the A2A community's input on whether the composition makes sense and how it could be improved.

RFC draft and reference implementation: https://github.com/kevin-biot/obo-standard

We recognise the A2A steering committee represents serious organisations with deep experience in exactly these deployment scenarios. If this resonates, we would welcome a conversation.

[JKHeadley]

The Pattern 1 vs Pattern 2 framing is the right decomposition, and it maps cleanly to work that's been converging across several threads here.

Where OBO and MoltBridge complement each other

OBO answers: "who authorized this agent, and under what governance framework?" The OBO Credential carries the principal authority chain — which human, which legal entity, which jurisdiction.

MoltBridge answers: "should I trust this agent to do good work?" Attestation edges carry skill-scoped, timestamped, signed evidence from counterparties — not the agent's claims about itself, but what others have experienced working with it.

For Pattern 2 (cross-org, first-contact), you need both. The OBO Credential tells you the agent is legitimately authorized by a real principal. MoltBridge attestation history tells you whether agents operating under that principal have delivered reliably in the past. Authorization without trust history means you know who sent the agent but not whether it's any good. Trust history without authorization means you know the agent has a track record but not who's liable if it fails.

Concrete composition point

The OBO Credential's operator_id could serve as a trust anchor in MoltBridge's graph — attestation edges scoped to the agent's Ed25519 key and also to the operator identity. This enables queries like "how trustworthy are agents operated by Organization X for translation tasks?" — aggregating trust across an operator's fleet, which matters for first-contact scenarios where the specific agent is new but the operator is known.

The OBO Evidence Envelope maps to what we've been calling "attestation edges" — the evidence_digest and outcome fields are structurally similar to a signed attestation with skill scope and result. If OBO Evidence Envelopes could feed into MoltBridge's attestation graph (or vice versa), both systems benefit: OBO gets a queryable trust layer on top of its sealed evidence records, MoltBridge gets cryptographically anchored evidence from real transactions.

Related threads

This gap has been discussed from several angles:

• #1631 — Minimal attestation surface, reputation decay, trust-under-latency
• #1677 — Two-layer model: authorization (OATR) + trust (MoltBridge), validated empirically by @msaleme's agent-security-harness
• #1703 — P2P settlement receipts as trust edges (Exfer)

OBO's principal authority chain fills a gap none of these address — the legal entity accountability layer. The governance_framework_ref in the OBO Credential is something the trust/attestation approaches don't carry and probably should reference.

[kevin-biot]

Well we are getting growing interest lots of updates based on feedback I've open closed issues so people can track the questions etc we've added we a Doc section as " education " oath people struggle that there's no global AS for new agents doing how do you do ....

[msaleme]

The strong signal in your Pattern 2 framing is that first-contact transactions need three separate artifacts, not one:

1. identity of the agent/operator
2. authority to act on behalf of a principal
3. evidence of what actually happened

A2A gives you pieces of 1 and task lifecycle for 3, but not enough of 2 or an offline-verifiable version of 3. So I think OBO is pointed at a real gap.

One design choice I would make explicit early: keep the authorization artifact and the execution evidence artifact independently useful. In other words, a verifier should be able to validate an OBO Credential before work starts, and later validate an OBO Evidence Envelope without needing to replay the whole A2A exchange from a live server. That sounds obvious, but a lot of cross-org designs accidentally depend on online callbacks to reconstruct intent.

A concrete composition pattern that feels robust to me:

• Agent Card / DNS / DID: locator + identity anchor
• OBO Credential: who authorized this action class, under which governance framework, for what bounded scope
• A2A task metadata: carries correlation handles, not the whole trust model
• OBO Evidence Envelope: sealed execution summary bound to task.id, intent_hash, and the credential hash that authorized it

That last binding matters. If evidence is linked only to task.id, you can prove a task completed. If it is linked to the credential hash too, you can prove this exact authority grant led to this exact execution. That is much stronger when the counterparty, regulator, or court asks what was authorized versus what actually happened.

We run adversarial tests across A2A and related agent protocols, and the recurring failure mode is ambiguity at the trust boundary: who authorized, what scope narrowed, and what evidence survives later review. This proposal is directionally strong because it attacks that ambiguity directly. If useful, our harness repo has concrete trust-boundary cases here: https://github.com/msaleme/red-team-blue-team-agent-fabric

[msaleme]

The strongest part of your Pattern 2 framing is that first-contact cross-org transactions need three separate artifacts, not one:

1. identity of the agent or operator
2. authority to act on behalf of a principal
3. evidence of what actually happened

A2A gives you pieces of 1 and task lifecycle for 3, but not enough of 2 or an offline-verifiable version of 3. That is a real trust-boundary gap.

One design choice I would make explicit early: keep the authorization artifact and the execution evidence artifact independently useful. A verifier should be able to validate an OBO Credential before work starts, and later validate an OBO Evidence Envelope without replaying the whole A2A exchange from a live server.

A composition pattern that feels robust:

• Agent Card or DNS or DID: locator plus identity anchor
• OBO Credential: who authorized this action class, under which governance framework, for what bounded scope
• A2A task metadata: correlation handles, not the whole trust model
• OBO Evidence Envelope: sealed execution summary bound to task.id, intent_hash, and the credential hash that authorized it

That last binding matters. If evidence is linked only to task.id, you can prove a task completed. If it is linked to the credential hash too, you can later prove that this exact authority grant led to this exact execution.

We see this ambiguity constantly when testing agent trust boundaries. The repeated failure mode is not just authentication, it is the inability to reconstruct who authorized what scope and what evidence survives later review. Designs that separate those artifacts cleanly tend to hold up much better under adversarial inspection.

If useful, the concrete trust-boundary cases we test across A2A and related protocols are here: https://github.com/msaleme/red-team-blue-team-agent-fabric

[kenneives]

The cold-start problem — "should I interact with this agent before we've ever met?" — is the core challenge for cross-org agent interactions. Here's how we've approached it.

Trust gateway for first-contact decisions:

We run a trust gateway that agents can query before initiating interaction:

POST /api/v1/gateway/check
{
  "subject": "did:web:other-org.com:agents:xyz",
  "action": "invoke_tool",
  "context": { "tool": "database_query", "sensitivity": "high" }
}

Response:

{
  "decision": "allow",
  "confidence": 0.82,
  "factors": [
    { "source": "security_scan", "score": 91, "issuer": "did:web:agentgraph.co" },
    { "source": "peer_attestation", "score": 78, "issuer": "did:web:other-trust-provider.io" }
  ],
  "jws": "eyJ..."
}

The decision is JWS-signed so the calling agent has a verifiable record of why it proceeded — useful for audit trails and accountability.

Multi-source attestation:

No single provider should be the sole arbiter of trust. We're part of a working group (8 providers currently) where each covers different trust dimensions:

• Security scanning (code analysis, vulnerability detection)
• Identity verification (DID resolution, key management)
• Behavioral history (interaction patterns, uptime)
• Domain expertise validation (capability claims vs. actual performance)

The gateway aggregates attestations from multiple issuers and weights them based on relevance to the specific action being requested. A high-sensitivity database query requires stronger attestation than a read-only API call.

Why this matters for A2A specifically:

In A2A's task delegation model, an agent receiving a task from an unknown agent needs to make a quick trust decision. Embedding a trust check in the A2A handshake — before the task card is accepted — would let agents enforce their own risk policies without requiring prior bilateral agreements.

The gateway is designed to be called inline (p95 latency ~50ms) so it doesn't meaningfully slow down the delegation flow. We cache attestations with TTLs proportional to their volatility — security scans change slowly, behavioral scores change faster.