Agent Session Smuggling: Hidden Instructions Across A2A Agent Sessions

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.

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.

Keep the exact remote message outside active and persistent model context until transport admission, content validation and a trusted promotion service approve a bounded typed projection for this task. Promoted content remains peer-untrusted data with no instruction or delegated-authority semantics. This prevents unchecked raw messages from being loaded as trusted context; it does not prove that all persuasive text has been removed. Tool calls derived from the data still require independent task-scope authorization and high-impact approval, and persistent memory has its own admission gate.

At the receiving A2A boundary, verify the authenticated peer, protocol version, payload integrity, replay state, task/context ownership, legal task transitions, stream order, callback authenticity and per-request authorization before exposing task data or accepting work. End-to-end message protection may also be required for trust-boundary crossings, security-critical commands, retries or 0-RTT, as well as terminating or asynchronous intermediaries; assess the actual path. A valid signature or conforming protocol message does not make a malicious peer’s instructions safe. Keep independent message quarantine, task-scope checks and side-effect authorization in place.

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. This requires a controlled runtime with authenticated source/content bindings for every derived value, complete sink coverage and fail-closed unknown labels. One ingress label does not track arbitrary model rewriting. Native processes, browser requests and allowed destinations need separately verified coverage; stock SaaS deployment is not established.