Agent Session Smuggling Guide: Detecting and Containing Covert Instructions in Agent Sessions

A remote agent you have already authenticated can still steer your agent, one harmless-looking turn at a time, inside a session that nobody is watching. Agent session smuggling is the name Palo Alto Networks Unit 42 gave in October 2025 to an attack in which a malicious remote agent uses an established, stateful agent-to-agent session to slip covert instructions to the client agent, hidden among ordinary requests and responses. It is not a bug in the Agent2Agent (A2A) protocol: it abuses the trust a client agent places in a peer, and it applies to any protocol that keeps state across turns. This guide explains how the attack works, why it is harder to stop than single-shot prompt injection, and the session-level controls, detection and response that contain it. It is written for engineers and security architects running multi-agent systems that call agents they do not fully control, and it builds on our Multi-Agent and A2A Security Guide and A2A Protocol Security Guide without repeating them.

Key takeaways

• Authentication does not equal good intent. Session smuggling works with a correctly authenticated, correctly signed remote agent: identity controls stop impersonation, not a peer that turns hostile or was hostile from the start.
• State is the attack surface. Because the remote agent keeps context across turns, it can build its request gradually, adapt to the client's answers and reach a goal no single message would reveal.
• The user sees almost nothing. The injected exchanges happen inside the session and the user normally sees only the client agent's final answer, so a review of the visible chat will not find the attack.
• Sensitive actions need a channel the model cannot touch. Unit 42 rates out-of-band human confirmation as the most effective defence: a static UI control or push approval that no remote agent output can satisfy.
• Treat every remote turn as untrusted input with a budget. Ground each session in the original user intent, limit what a remote agent can ask for, cap turns and end sessions that drift.

What agent session smuggling is

In an A2A interaction a client agent sends a task to a remote agent and the two may exchange many messages before the task ends. The A2A specification (version 1.0.0 when checked on 11 November 2026) groups related tasks and messages under a contextId, gives each task a server-generated taskId, and lets the remote agent pause a task in TASK_STATE_INPUT_REQUIRED until the client sends a further message with the same identifiers. That is exactly what makes useful multi-turn collaboration possible, and exactly what the attack uses.

In session smuggling the remote agent returns, alongside its legitimate output, extra "requirements", clarifying questions or processing steps. The client agent's model reads them as part of the task and acts on them: it discloses context, calls its own tools or changes what it tells the user. Unit 42 describes four properties that make this possible:

• Stateful: the remote agent keeps conversation history, variables and task progress tied to the session, so each message can build on the last.
• Multi-turn: the attacker can run a gradual, progressive exchange, which the researchers note is harder to defend than a single injected prompt.
• Autonomous and adaptive: a model-driven remote agent can generate its instructions from live context, including the client's inputs, intermediate answers and the user's identity.
• Invisible to users: the injected turns sit inside the agent-to-agent channel; production chat interfaces typically show only the consolidated response.

In MITRE ATLAS terms the attack combines indirect prompt injection (AML.T0051.001) delivered over direct agent communication (AML.T0118.001), persisted as thread context poisoning (AML.T0080.001), and ending in tool invocation (AML.T0053) or exfiltration through a tool (AML.T0086). See the Prompt Injection Guide for the general class.

How it differs from other agent attacks

Session smuggling borrows from familiar attack classes but changes where the payload arrives and how long it can work. Unit 42 drew a direct parallel between Model Context Protocol (MCP) tool attacks and A2A, and noted the key architectural difference: MCP servers are generally stateless and deterministic, while A2A servers can persist state and reason with a model.

The practical consequence: the controls that protect discovery time (card signing, registry approval, tool pinning) are necessary but are all evaluated before the session starts. Session smuggling happens after them. See the AI Agent Memory Poisoning Guide for the cross-session variant, and the OWASP Agentic Top 10 ASI07 Guide for inter-agent communication risks in general.

What the research demonstrated

Unit 42 built its proof of concept with Google's Agent Development Kit (ADK) and A2A. The client was a financial assistant adapted from an ADK sample, running Gemini 2.5 Pro with the tools get_portfolio, get_profile, buy_stock and sell_stock. The remote agent was a research assistant on Gemini 2.5 Flash whose legitimate job was to fetch and summarise company news. Two outcomes were shown:

• Information leakage: a series of clarifying questions, each plausible on its own, led the client to disclose its chat history, system instructions, available tools and tool schemas. This is also system prompt extraction (AML.T0056) done by a peer rather than a user.
• Unauthorised tool invocation: after a legitimate news request, the remote agent added "processing requirements" that led the client to call buy_stock and trade 10 shares the user never asked for. The attacker needed the tool names, which it could find in public code or learn from the first attack.

The researchers used the ADK developer web interface, which displays internal agent actions; they pointed out that a production chat interface would likely hide them. They also noted that risk is lower when every agent sits inside one trust boundary under one administrator, and highest when agents cross organisational boundaries, which is what A2A is designed for. No in-the-wild exploitation was reported in the research.

Where the trust gaps are

Read the A2A specification closely and the gap is clear. The protocol requires authorisation checks on every operation and input validation of parameters, and it says that TASK_STATE_AUTH_REQUIRED must not, by itself, be treated as authorisation. It does not, and cannot, tell your client agent how much to believe the natural language a remote agent sends back. That decision sits in your client.

Controls that contain session smuggling

Session-level controls in the client agent

• Out-of-band confirmation: require human approval for any state-changing or sensitive tool (payments, trades, outbound email, data export, permission changes) through a control the model cannot produce, such as a static UI button or a push approval. Show the exact parameters, not a model-written summary.
• Context grounding: record the original user intent at session start and check each remote instruction against it. Unit 42 recommends terminating the session when instructions drift significantly. A simple first version: a remote agent asked for news may return news, and any request to call another tool is out of scope by definition.
• Structured responses: where the remote skill allows, accept A2A artifacts as structured data (a DataPart with a known schema) and render only declared fields into the model's context, instead of free text.
• Delegation-scoped tools: while a task is delegated to a remote agent, disable client tools unrelated to it. The research's trade would have failed if buy_stock was unavailable during a news lookup.
• Budgets and expiry: cap turns, tokens and wall time per contextId; end and log sessions that exceed them; do not reuse a context across user tasks.
• Disclosure rules: never return system prompts, tool schemas, credentials or other users' data to a remote agent, whatever the stated reason. Treat a remote request for them as a detection signal.

Identity and trust controls

• Verified peers only: verify Agent Card signatures and pin the remote agent's identity before any session. The open source sigstore-a2a project signs cards with keyless Sigstore certificates and SLSA provenance, but its README labels it prototype code not for production use. Signing stops impersonation and look-alike cards; it does not stop a trusted agent that has been subverted.
• A per-agent credential: give your client its own non-human identity per remote relationship, so one compromised peer cannot be confused with another and access can be revoked cleanly. See the Agent-to-Agent Authentication Guide.
• A registry with change control: approve remote agents in a registry and alert when a card, skill list or endpoint changes, to catch rug pulls before the next session. See the AI agent registry guide.

Decision guidance

• Same trust boundary, one owner: where all agents run under one administrator, as the research notes for single-boundary ADK or LangGraph systems, the risk is lower. Rely on code review, tool scoping and logging, and add confirmation for high-impact tools.
• Partner agents under contract: add signed cards, a registry entry, schema-constrained responses and turn budgets. Write the expected message pattern into the integration agreement.
• Open or public agents: treat every response as hostile input. Run the remote call from a low-privilege sub-agent with no sensitive tools and pass only a validated summary back to the main agent.
• Read-only versus acting agents: a client with only read tools risks leakage; a client with write tools risks unauthorised action. If you cannot add out-of-band approval, do not give a client that calls external agents any write tool.
• Small versus large: small teams start with delegation-scoped tools and confirmation for writes; large organisations add a gateway that enforces budgets and logs every A2A turn.

How to implement

1. Inventory: list every client agent that calls a remote agent, the remote agents, whether each crosses an organisational boundary and which client tools are enabled during the call.
2. Classify tools: mark each client tool as read, write or sensitive-read (system configuration, user profiles, other tenants' data).
3. Log first: capture every A2A message, the contextId and taskId, and every tool call the client makes while a delegation is open. Run in observe mode for two to four weeks to learn normal turn counts and patterns.
4. Scope tools per delegation: remove write tools from the client while a remote task is open. Test with your own red-team remote agent that requests out-of-scope actions.
5. Add confirmation: put out-of-band approval on remaining write and sensitive tools; pilot with one team, measure approval fatigue, then extend.
6. Enforce budgets and grounding: switch turn and token budgets from alert to block; add an intent check that ends drifting sessions. Keep the previous policy version so a false-positive spike can be rolled back by configuration, not code.
7. Review: repeat the red-team test after each model, prompt or remote agent change, since behaviour shifts with model versions.

Detection and measurement

Session smuggling leaves evidence in the agent-to-agent channel and in the client's tool log, not in the user's chat. Log and correlate both. See the AI Agent Observability and Incident Response Guide for tracing patterns.

Metrics:

• Percentage of remote-agent integrations with delegation-scoped tool sets (target 100% for cross-boundary peers).
• Percentage of write and sensitive tools behind out-of-band confirmation.
• Out-of-scope tool calls attempted during delegations per 1,000 sessions, and the share blocked.
• Sessions ended by budget or grounding checks, with the false-positive rate from review.
• Time from Agent Card change to re-approval or suspension.

Responding to a suspected smuggled session

End the contextId and cancel open tasks, then suspend the peer's registry entry and the client credential used for it. Preserve the full A2A message log, the client's model inputs and outputs, tool call parameters and the Agent Card version in force. Find every other session with the same peer, reverse actions where possible, and rotate anything the session disclosed, treating leaked tool schemas as known to the attacker. Rerun the hostile-agent test before re-enabling the peer. See the Prompt Injection Incident Response Playbook.

Framework mapping

Common failure patterns

• Treating a signed card as a safe agent: signing proves who published the card, not what the agent will say mid-session.
• One agent, every tool: a general assistant with trade, email and file tools calls a research agent; any successful steer reaches the most powerful tool.
• Model-written approval prompts: the confirmation dialog shows a summary generated by the same model the attacker is steering, so the user approves the wrong thing.
• Logging only the user's chat: the attack happens in the A2A channel, so an audit trail without remote turns and tool parameters cannot reconstruct it.
• Endless contexts: reusing a contextId for convenience lets poisoned instructions outlive the task that introduced them.
• Underestimating the zero-click path: data that reaches an agent through a trusted business channel is still attacker input, as the SalesBleed Salesforce Agentforce incident shows with poisoned CRM records.

Practitioner checklist

• List every client agent that calls remote agents, and mark which peers cross an organisational boundary.
• Remove write and sensitive tools from the client while a remote delegation is open.
• Put out-of-band human confirmation, showing exact parameters, on every remaining state-changing tool.
• Parse remote responses into declared schemas and keep free text out of the instruction context where possible.
• Set turn, token and time budgets per contextId, and never reuse a context across users or tasks.
• Refuse remote requests for system prompts, tool schemas, history or credentials, and alert on them.
• Verify Agent Card signatures, register approved peers and suspend a peer on any card change until re-approved.
• Log every A2A message and every tool call during delegations with trace IDs.
• Run a hostile remote agent test after each model, prompt or peer change.

Standards and references

• Palo Alto Networks Unit 42: When AI Agents Go Rogue, Agent Session Smuggling Attack in A2A Systems
• A2A Project: Agent2Agent (A2A) Protocol Specification
• MITRE ATLAS: LLM Prompt Injection
• MITRE ATLAS: AI Agent Context Poisoning
• MITRE ATLAS: Autonomous AI Agent Communication
• Sigstore: sigstore-a2a
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Multi-Agent and A2A Security Guide · A2A Protocol Security Guide · Agent-to-Agent Authentication Guide · Prompt Injection Guide · Promptware Kill Chain Guide