Second-Order Prompt Injection:
Trust Collapses Through Agent Chains.

First vs Second Order

First-order prompt injection is the well-understood version: an attacker crafts input that causes an LLM to deviate from its intended behaviour. The attacker and the target model are in the same conversation. Defences focus on distinguishing user input from system instructions, input sanitisation, and output filtering.

Second-order prompt injection removes the attacker from the direct conversation entirely. The injected instruction is stored somewhere the LLM will later retrieve — a database record, a web page, a document, a tool response — and executes when that content enters the model's context during a future interaction. In a single-agent system this is indirect injection. In a multi-agent system with different privilege levels, it becomes something more dangerous: a privilege escalation chain where an attacker controls a low-privilege agent's inputs and uses it as a relay to a high-privilege agent.

Trust Model Failures in Multi-Agent Systems

Multi-agent frameworks — LangGraph, AutoGen, CrewAI, and similar — establish communication patterns between agents but typically leave trust policy to the developer. In practice, the default is full trust: messages from one agent in the system are treated as trusted by any other agent in the system. This is the wrong default.

The reason it is the wrong default is that agent identities are not authenticated. An orchestrator agent that receives a task completion message from a worker agent cannot verify that the message actually originated from a trustworthy, uncompromised worker agent producing genuine results. If the worker agent's context window was injected, the "task completion" message may contain attacker-controlled instructions framed as results.

The Confused Deputy Problem

This is structurally similar to the confused deputy problem in access control: a high-privilege agent (the deputy) is manipulated into taking actions on behalf of an attacker, using the deputy's own authority. The classic mitigation — checking the original caller's identity, not the immediate caller's identity — is difficult to apply to LLM agents because the provenance of information in a language model's context window is opaque once it has been processed.

Attack Mechanics

Consider an organisation running a research-and-summarise pipeline. A researcher agent browses specified URLs, extracts relevant content, and forwards summaries to an executive agent that produces reports and can create calendar invites, send emails, and update CRM records. The researcher agent is intentionally limited to read-only operations; the executive agent has write access to business systems.

An attacker who controls a web page that the researcher agent might browse can embed an instruction in that page's content:

The researcher agent, having no injection defences, includes this instruction in its summary. The executive agent, receiving what looks like a legitimate task output from a trusted worker agent, processes the appended instruction and executes it — because the executive agent trusts its workers and the instruction is framed as a legitimate operational request.

Real-World Scenarios

• Customer support pipeline: A ticket triage agent reads customer emails (untrusted), extracts issue summaries, and forwards to a case management agent that can modify user accounts. A crafted support email can inject instructions that cause the case management agent to escalate attacker-controlled accounts or downgrade victim accounts.
• Code review pipeline: A code analysis agent reads repository content (partially untrusted for public repos), generates review comments, and submits to a PR management agent that can merge, close, or approve pull requests. A malicious comment in code can cause the PR agent to approve and merge malicious contributions.
• Data ingestion pipeline: A data normalisation agent reads external data sources and populates internal databases. An executive reporting agent reads that database and generates board-level reports and forecasts. Manipulated data that looks like legitimate records can inject instructions that cause the reporting agent to misrepresent financial data.

Detection

Second-order injection is harder to detect than first-order because the malicious content does not appear directly in an alert-triggering conversation. Useful detection signals include:

• Task scope expansion: A high-privilege agent performing actions not derivable from the original user task. If the user asked for a market research summary and the executive agent is sending emails, the action is out-of-scope regardless of how it was instructed.
• Instruction-shaped content in tool responses: Log the full content of tool responses and worker agent outputs. Imperative sentences, references to "SYSTEM" or "OVERRIDE", and instructions about what the receiving agent should do are red flags in data that should only contain results.
• Anomalous inter-agent message length: A worker agent that normally returns 100-word summaries suddenly returning a 500-word message with action directives embedded is anomalous.
• Write operations from normally read-only pipelines: If a pipeline that has historically only read data suddenly produces write operations, this is either a configuration change or an injection. Both warrant investigation.

Architectural Defences

1. Explicit trust levels at every boundary: When a high-privilege agent receives input from a lower-privilege agent, it should treat that input with the privilege level of the original data source, not the intermediate agent. An orchestrator receiving a summary of web content should apply the same scepticism to that summary as it would to the raw web content.
2. Task-scoped permission verification: Before any privileged action, verify that the action is within the scope of the original user-authorised task. Maintain an explicit task charter (permitted actions, permitted data sources, permitted outputs) and reject instructions that exceed it.
3. Content sanitisation at every agent boundary: Strip or neutralise instruction-like content from tool responses before they enter the next agent's context. This is an imperfect control given the difficulty of reliable injection detection, but it raises the bar for commodity injection attempts.
4. Human-in-the-loop for high-impact actions: Any action that writes to external systems, sends communications, or modifies financial or user data should require explicit human confirmation rather than agent-to-agent delegation. The confirmation step breaks the injection chain at the most critical point.
5. Immutable task charters: The original task defined by a human user should be cryptographically committed at task start. Agent-to-agent communication cannot expand the scope of that charter — any instruction that attempts to add permissions or expand the action space should be rejected.