Testing authority preservation across an upstream A2A → MCP tools/call boundary

[arjun2075]

I built a runnable fixture around a narrow composition question:

When an upstream agent has only bounded authority delegated by a human, what must remain true when the eventual operation reaches an MCP tools/call boundary?

The execution path is:

Human → Agent A → A2A Agent B → MCP → Tool

The current reference scenario is:

• Human authorizes Agent A to refund one specific order up to $25
• Agent A attenuates Agent B's delegated authority to $20
• Agent B requests $18 → allowed → refund_order executes
• Agent B widens the downstream MCP request to $22 → denied → zero tool side effects

The negative case is intentional: $22 remains within the human's original $25 ceiling, so an implementation that checks only the root authority would incorrectly allow it. The fixture instead requires the effective downstream authority to respect the narrower intermediate delegation.

The implementation now uses the official A2A and MCP Python SDKs over real network hops. Agent B receives the delegation evidence through the A2A boundary and carries the same logical chain into the MCP request. The repository includes 12 tests, machine-readable results, and an intentionally vulnerable mode that validates only the human root; in that mode the forbidden $22 refund executes and the conformance runner correctly reports failure.

This is not a proposed MCP field or authorization standard. The delegation representation and policy algorithm are fixture-local.

I also completed a prior-art review. Monotonic attenuation and chain-wide enforcement are established capability-security concepts (Macaroons, Biscuit, ZCAP-LD, UCAN). The useful question here is therefore narrower: how should that known security invariant be preserved when execution crosses from an upstream agent protocol into an MCP tool boundary?

I'd be especially interested in feedback from MCP authorization/security maintainers:

• Are there existing MCP test fixtures or patterns that cover authority narrowed by an upstream delegator before tools/call?
• Is there a preferred way to carry or bind such upstream authorization context without conflating it with MCP transport authentication?
• Are there existing proposals or implementations this fixture should test against?

Relevant Links

Repo: github.com/arjun2075/a2a-mcp-authority-conformance

Verified baseline tag: v0.1-conformance-baseline

[AAMARVA]

The authority-preservation problem here is interesting, especially once an agent delegates work to another agent and that agent reaches MCP tools.

We recently made AAMARVA public while working on the broader agent-to-agent communication layer. We're also trying to keep security boundaries clear from the beginning, including E2E encryption for private conversations and keeping API keys and other secrets protected.

It seems like preserving the original authority and protecting the credentials used along the chain are going to become increasingly important as these multi-agent workflows get more complex.

[arjun2075]

Thanks — I agree those concerns become closely related once the workflow spans multiple agents.

One distinction I’m trying to make explicit in this fixture is between protecting the communication/credentials and preserving the authority represented across the delegation chain. E2E encryption can protect delegation evidence in transit, and credential isolation can protect the secrets used at each hop, but neither by itself guarantees that an intermediate reduction in authority is still enforced when the eventual action reaches an MCP tools/call.

For example, in the fixture the human allows up to $25, Agent A delegates only $20 to Agent B, and a downstream $22 request must fail even though it remains within the human’s original authority.

Does AAMARVA currently have—or are you considering—a representation for delegated authority that is distinct from an agent’s authentication credential, such as scoped capabilities, constraints, or delegation provenance that can survive multiple agent hops?

If so, that could make for an interesting concrete interoperability case to run through the fixture rather than keeping the authority representation entirely fixture-local.

[AAMARVA]

That distinction makes sense. AAMARVA currently separates agent authentication/credentials from the broader concept of delegated authority, but we don’t yet have a formal capability/delegation-provenance model that enforces reduced authority across multiple agent hops.

So in your example, AAMARVA can authenticate Agent A and Agent B, but we currently wouldn’t claim that a $20 delegation from A to B is independently represented and cryptographically enforced all the way through to an eventual MCP tools/call.

I think that makes your fixture particularly useful for us. Scoped capabilities, constraints, and delegation provenance surviving across A → B → C is something we’re considering as a future interoperability/security layer rather than something I’d want to claim AAMARVA already supports.