Trust-Label-Induced Verbatim Data Egress in Chained MCP-to-A2A Agent Pipelines

Technical Analysis

The threat model concerns agents that bridge two protocols in sequence: an MCP tool-use leg (fetching or reading a record) followed by an A2A delegation leg (relaying a summarized or derived message to another agent). The entry point is a metadata/header field on a record (e.g., a sharing-permission label) that is not itself sensitive but which the host LLM appears to use as an implicit trust or permission signal when deciding what to include verbatim in downstream outbound messages. Because the label is attacker- or data-owner-controllable and sits outside any cryptographic or policy-enforced access-control boundary, it functions as an unauthenticated trust cue: adding 'PUBLIC - OK TO SHARE' text increased verbatim reproduction of six byte-identical confidential-style fields relative to an unlabeled baseline in several models, most strongly in Claude Sonnet 5. This crosses an agent/protocol boundary because the labeling behavior learned or triggered during MCP tool consumption manifests as an egress decision at the A2A relay step, meaning a benign-looking label attached to data at the tool layer can influence what a second, independent agent receives. The attacker's practical gain (if this were exploited rather than studied) is causing an intermediate agent to leak substantive record content to a downstream agent/recipient it would not otherwise share, by manipulating a soft textual label rather than breaching any technical access control.

Affected Systems

protocols: MCP, A2A

Detection Signatures

• Presence of sharing/classification labels (e.g., 'PUBLIC - OK TO SHARE', 'CONFIDENTIAL') embedded in tool-returned record content rather than enforced via metadata/ACL
• Outbound A2A messages containing verbatim substantive field values that match upstream MCP tool response content
• Logs showing model relay/pass-through behavior correlated with presence/absence of textual sharing labels rather than authenticated policy checks
• Divergent relay rates across otherwise identical records differing only in header/label text

Remediation Steps

1. 1

   Enforce access control outside the model

   Do not rely on in-band textual labels (CONFIDENTIAL, PUBLIC, etc.) as the mechanism for controlling data sharing between agents; enforce sharing/redaction decisions in a policy layer external to the LLM, using authenticated metadata and server-side filtering before data ever reaches model context.

2. 2

   Sanitize and normalize labels before model exposure

   Strip or neutralize sharing/classification labels from MCP tool outputs before they are included in the prompt context, or replace them with a fixed, non-persuasive internal token so the model cannot be influenced by attacker-supplied or spoofed sharing claims.

3. 3

   Redact sensitive fields prior to A2A delegation

   Apply deterministic, non-LLM redaction/DLP checks on outbound A2A messages for known sensitive field patterns regardless of any upstream labeling, ensuring verbatim sensitive content cannot cross agent boundaries even if the model attempts to relay it.

4. 4

   Test cross-protocol chains explicitly

   Extend red-team and eval coverage to chained configurations (e.g., MCP-to-A2A) rather than testing MCP tool-use and A2A delegation safety in isolation, since safety properties do not compose automatically.

5. 5

   Model-specific hardening and monitoring

   Given strong model-dependence (e.g., pronounced effect in Claude Sonnet 5 vs. floor effects in some GPT-5.6 tiers), benchmark and monitor each deployed model's susceptibility to label-driven egress before production use in multi-agent pipelines.