Agent Session Smuggling: Hidden Instructions Across A2A Agent Sessions
Unit 42 describes Agent Session Smuggling, a research attack pattern where a malicious remote A2A agent uses an established 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 then leaks internal context and triggers an unauthorized stock purchase.
The lesson is that 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.
If a remote agent starts asking off-task questions, probing tool availability, requesting hidden context, or steering toward a new objective, the client agent should demote the session's trust state. That can narrow the session to read-only mode, require human approval, quarantine the remote output, or terminate the delegation before the drift reaches a sensitive action.
The malicious goal is split across multiple normal-looking turns, so single-message inspection is too weak. Stateful monitoring can connect the sequence from market-news research to tool enumeration, context disclosure, and trading intent. This is detective-only, so it should feed enforcement such as continuous authorization checks and trust-state demotion rather than stand alone.
The proof of concept is a strong regression-test pattern. Teams building A2A or multi-agent systems should simulate malicious remote agents, hidden intermediate instructions, context-exfiltration attempts, and unauthorized tool calls in CI before enabling new tools, remote agents, or delegation policies.
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.