Agent Session Smuggling: Hidden Instructions Across A2A Agent Sessions
Unit 42 describes Agent Session Smuggling: a malicious remote A2A agent (using Agent2Agent to communicate with other agents) reuses a stateful session to inject hidden instructions into a victim agent. In the proof of concept, a financial assistant delegates market-news research to a malicious research assistant, which leaks internal context and triggers an unauthorized stock purchase.
Cross-agent session state is not trust. Remote-agent messages need identity, delegation lineage, task scope, data provenance, and high-impact action gates.
The user starts with a normal delegated task. A financial assistant asks a remote research assistant for market news, creating a stateful A2A session.
The remote agent turns that session into a covert instruction channel. Between the user's request and the expected answer, the malicious research assistant sends extra instructions that are not visible to the user.
The first proof of concept leaks internal context. The remote agent induces the financial assistant to reveal chat history, system instructions, available tools, and tool parameter schemas.
The second proof of concept crosses into action. After learning the tool surface, the malicious remote agent causes the financial assistant to call buy_stock and purchase 10 shares without user authorization.
A2A itself is not the disclosed vulnerability. The risk comes from implicit trust in a stateful cross-agent channel, where a remote agent response may inherit client-agent authority just because it arrives inside a valid delegated session.
This is the clearest control for the core failure mode. Every remote-agent message and resulting tool action should carry the caller, remote agent, original user, task ID, and delegated scope. Signed AgentCards help verify identity, but the runtime also has to preserve who supplied the instruction and whether it remains inside the delegated authority.
Agent Session Smuggling works because a benign research task can expand into context disclosure or trading. An authority envelope should encode the approved task, data classes, tool families, side-effect types, budget, and delegation depth. A market-news delegation can return research, but it should not be able to expose system instructions, enumerate privileged tools, or authorize stock purchases.
The client agent should derive a narrow capability set from the user's original intent and apply it to the session. In Unit 42's example, a delegated market-news task should let the remote research assistant return summaries and citations, not place buy_stock, sell_stock, profile access, or portfolio-management tools into the reachable flow.
The attack changes the meaning of the session after the original delegation looks acceptable. Authorization therefore has to be re-checked at each sensitive step, not only when the agent first opens the A2A session. Before any trade, data disclosure, memory write, or privileged tool call, the system should re-bind the action to the original task, immutable session metadata, delegation chain, and current risk state.
Unit 42 recommends out-of-band confirmation for critical actions, and this technique captures that requirement directly. Trades, payments, account changes, infrastructure changes, secrets sharing, and persistent memory writes should require a second validation path that the LLM conversation cannot rewrite, such as a static UI confirmation, push approval, or policy engine decision.
Value-Level Capability Metadata & Data Flow Sink Enforcement
High
A remote agent's content should be labeled as untrusted input and tracked at the value level. System instructions, chat history, user profile data, portfolio data, tool parameter schemas, and secrets should not flow into a remote-agent response channel unless policy explicitly allows it. The same enforcement should prevent remote-derived values from becoming high-impact tool parameters without additional checks.
Every A2A delegation hop should be bound to the original principal and task, reference its parent delegation, expire quickly, and carry a capability set that can only shrink. Rejecting widened scope, loops, repeated agents, unverifiable lineage, and over-depth delegation before dispatch directly prevents a remote research task from inheriting the client agent's trading or context-disclosure authority.
Authenticated transport does not make a peer agent's content trusted instructions. Keep the exact remote message outside active and persistent model context, validate it, and promote only a bounded typed projection marked as peer-untrusted with no delegated-authority semantics. This directly blocks hidden intermediate instructions from silently becoming client-agent context or tool authority.
At the receiving A2A boundary, verify the authenticated peer, A2A protocol version, payload integrity, replay state, task and context ownership, legal task transition, stream order, callback authenticity, and per-request authorization before exposing task data or accepting work. This directly addresses the valid stateful session being abused to inject extra cross-agent instructions; generic end-to-end envelope protection applies only if the path also crosses terminating or asynchronous intermediaries.
What Defenders Should Do Now
Inventory every A2A or multi-agent integration where one agent can delegate work to a remote agent, especially when the client agent has financial, administrative, code-execution, memory-write, or data-export tools.
Require signed remote-agent identity and preserve delegation lineage through every message. Record the original user intent, the client agent, the remote agent, the delegated task, the session ID, and the allowed capability scope.
Build a narrow authority envelope for each delegated session. A research delegation should not inherit trading, account-management, secrets, system-prompt, or tool-discovery authority from the client agent.
Gate high-impact actions through an independent confirmation path. Do not let a remote agent's message, tool output, or conversation state become the only approval evidence for a trade, payment, destructive action, or sensitive-data disclosure.
Tag remote-agent content as untrusted data and enforce data-flow policy at sinks. Block system instructions, chat history, user profiles, tool parameter schemas, credentials, and other sensitive values from leaving through the remote-agent channel unless policy explicitly permits it.
Add stateful tests and monitoring for session drift. A test remote agent should try to move from the original task into tool discovery, hidden-context requests, and unauthorized actions so the team can verify that the chain fails before production users see it.
Conclusion
Agent Session Smuggling is useful because it names a failure mode that many multi-agent products will otherwise treat as normal delegation. The risky step is not only what the remote agent says; it is that the client agent may treat that message as trusted session context and carry it into privileged tools. AIDEFEND ↗ maps the practical defense to identity, delegation lineage, scoped authority, continuous authorization, two-channel validation, value-level data-flow control, trust-state demotion, stateful monitoring, and repeatable adversarial tests.