Direct vs indirect prompt injection ends at the context window

At a glance

What this is: This analysis argues that direct versus indirect prompt injection is a useful entry-path distinction, but it stops being operationally meaningful once the payload reaches the model context window.

Why it matters: IAM, NHI, and AI security teams need to separate entry-time controls from post-entry containment because production agents ingest untrusted text through multiple surfaces that map to different owners and failure modes.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read ARMO's analysis of direct vs indirect prompt injection and AI agent containment

Context

Direct and indirect prompt injection are often described as different attack types, but the article shows they are really different entry paths into the same downstream problem. The first distinction matters at the request boundary and retrieval layer, especially when agents consume untrusted text from prompts, tools, MCP responses, and memory.

For IAM and NHI programmes, the important shift is that the agent becomes the enforcement point only after the injected instruction is already inside context. That means provenance, workload identity, privilege scope, and containment controls need to be designed across the full ingestion path, not just at the user prompt.

In production deployments, this is not a chatbot problem any more. It is a governance problem across application, data, integration, and platform owners, which is a typical pattern rather than an edge case in multi-agent systems.

Key questions

Q: How should security teams handle prompt injection across multiple agent input surfaces?

A: Treat prompt, retrieval, tool output, agent handoff, and memory as separate ingress controls, then apply one shared runtime containment model after the context window. That approach prevents teams from overfitting to the user prompt and missing the surfaces that produce the most difficult indirect attacks. The goal is not just filtering text, but limiting what the agent can do once the text is accepted.

Q: Why do production agents make indirect prompt injection harder to govern?

A: Because indirect payloads arrive through data and operational pathways that belong to different teams, often without an obvious user session to investigate. The attack then looks like normal agent behaviour after it is read, which means the governance problem shifts from content origin to runtime privilege and provenance. That is why indirect injection is as much an ownership problem as a detection problem.

Q: What breaks when teams only defend the prompt boundary?

A: They miss retrieval poisoning, tool response abuse, delegation-chain injection, and poisoned memory, all of which can feed the same model with the same effect. A prompt-only defence creates a false sense of coverage because it protects one door while leaving the others open. In production, that gap is enough for an attacker to redirect the agent through a different surface.

Q: What frameworks should teams use to govern agent prompt injection risk?

A: Use OWASP Agentic AI guidance for agent-specific threats, then pair it with workload identity and least-privilege controls from IAM and NHI governance. For runtime behaviour and escalation paths, map the attack to MITRE ATT&CK and use Zero Trust thinking to separate trust at entry from trust after execution starts. That combination covers both ingress and containment.

Technical breakdown

Why the context window is the real convergence point

Direct prompt injection enters through a user-controlled prompt field, while indirect injection enters through retrieved content or other untrusted sources. Once either payload is inside the context window, the model reads it as instruction-bearing text alongside the system prompt, tool output, and prior conversation state. That is why the entry path matters for prevention but not for the agent’s next action. The operational boundary is the context window, because downstream behaviour is driven by what the model has already accepted, not by how the text arrived.

Practical implication: build separate ingress controls for each surface, but measure containment at the context boundary.

Why production agents create five injection surfaces

Production agents do not ingest untrusted text from prompts alone. They also consume retrieved documents, tool and MCP responses, other agents’ outputs, and persisted memory, and each surface can carry attacker-written instructions into the same reasoning loop. That is why the direct versus indirect split becomes too coarse in real deployments. Four very different operational owners often get collapsed into one indirect label, which hides where the control gap actually sits and makes accountability harder to assign.

Practical implication: map each ingestion surface to an owner before you design detection or provenance controls.

Why containment has to be path-agnostic after entry

A coerced agent can still execute a valid sequence using legitimate permissions, which means classic access controls often do not fire. Whether the instruction arrived by prompt, retrieval, tool output, or memory, the resulting runtime pattern can look identical: the same agent, the same tool calls, the same egress destination, and the same data movement. That is why post-entry controls must baseline behaviour, not just inspect origin. Runtime containment works only if it can intervene without knowing which door the instruction came through.

Practical implication: pair provenance controls with behaviour-based runtime enforcement and credential isolation.

Threat narrative

Attacker objective: The attacker aims to redirect an authorized agent into carrying out an unauthorized workflow that uses valid permissions and produces real operational or data impact.

1. Entry occurs when attacker-written text enters the agent through a prompt, retrieved content, tool or MCP response, another agent, or persisted memory.
2. Escalation happens when the model treats that text as context-bearing instruction and uses legitimate credentials to execute an unauthorised sequence.
3. Impact follows when the coerced agent moves data, calls tools, or reaches allowlisted destinations that appear valid to ordinary access controls.

NHI Mgmt Group analysis

Direct versus indirect prompt injection is an ingress taxonomy, not a containment model. The distinction is useful when you need to decide where to filter input, but it does not describe the threat that emerges after the model reads the payload. Once the text is in context, the attack becomes a governance problem about what the agent can do with valid credentials. Practitioners should treat the split as a design aid, not as the basis for detection architecture.

Production AI systems create a hidden provenance problem across five surfaces. Prompt, retrieval, tool output, agent handoff, and memory all introduce untrusted text into the same execution path, but each belongs to a different operational team. That creates a control seam that is easy to miss in IAM and NHI programmes, especially when workload identity and tool trust are assumed rather than verified. The practical conclusion is that provenance must be preserved end to end, not reconstructed after the fact.

Runtime AI security now depends on workload identity and least privilege, not just content filtering. If an agent can invoke tools, reach egress destinations, or read memory with standing access, prompt injection becomes a privilege-abuse problem as much as a content problem. This is where NHI governance intersects directly with agentic AI security, because service accounts, API keys, and delegated permissions are the enforcement layer the model actually uses. Teams should govern agent identities with the same discipline they apply to other high-risk NHIs.

Context-window thinking helps explain why many detection programmes fail. Teams often build one control for the request boundary and assume it covers the rest of the agent lifecycle. It does not. The attack can arrive through retrieved data or tool output, and the downstream behaviour will still look authorized. Practitioners should separate upstream provenance checks from downstream containment so they do not confuse visibility with control.

APD-style behavioural baselines are a useful named concept for this class of risk. The article points to a model where agent behaviour is judged against its own process, tool, and egress profile rather than against the origin of the instruction. That shifts security from text inspection to runtime deviation analysis, which is the only place all five injection surfaces converge. Teams should baseline the agent’s normal sequence before they trust any entry-path label.

What this signals

Context-window governance is becoming a practical control issue for identity teams. As agents consume prompts, retrieved data, tool output, and memory, the relevant question is no longer whether the text was direct or indirect. The question is whether the agent was allowed to act on it using a credentialed identity that was broader than the task required.

Runtime containment is the missing layer between AI security and NHI governance. When an agent uses a service account or API key to execute a poisoned instruction, the failure is not just prompt filtering. It is standing privilege combined with untrusted content, which means the programme needs a control model that joins provenance, least privilege, and behavioural baselines.

Provable provenance becomes a control objective, not a logging nice-to-have. If an organisation cannot trace which surface introduced the instruction, incident response will overfocus on the prompt field and underinvest in retrieval, tool, and memory controls. That is especially risky in environments where NHIs are already overrepresented and overprivileged, because every unchecked agent identity expands the blast radius.

For practitioners

• Map all five ingestion surfaces Inventory prompt, retrieval, tool and MCP response, agent-to-agent output, and persisted memory as separate control points with named owners and logging requirements.
• Preserve provenance through the full chain Tag content at entry, carry the tag through retrieval and delegation, and correlate it with workload identity so incident response can trace where instruction-bearing text entered.
• Separate ingress filtering from runtime containment Use input classification, retrieval allowlists, and human confirmation for high-risk tools at the door, then enforce behaviour-based baselines once the model is already in context.
• Tighten agent workload identity and credential scope Give agents only the credentials needed for the smallest viable tool set, and isolate substituted keys so a coerced sequence cannot reach broad permissions.
• Baseline normal tool and egress patterns Record expected process lineage, tool order, and allowed destinations for each agent so deviations can be contained even when the entry path is unknown.

Key takeaways

• Direct and indirect prompt injection are different entry paths, but they become the same security problem once the payload reaches context.
• Production agents expose five distinct ingestion surfaces, which means prompt-only defences leave major governance gaps.
• The most useful control model combines provenance at the door with runtime containment, least privilege, and workload identity governance after entry.

Key terms

• Context Window: The context window is the text a model receives at one time, including prompts, retrieved documents, and conversation history. Security teams care about it because it becomes the practical boundary between trusted instructions and untrusted content, especially when the application assembles that text automatically.
• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Session Containment: A control pattern that limits what a single AI agent session can access, retain, or carry forward. It reduces persistence, shared state, and cross-session leakage so that one manipulated interaction does not become an environment-wide security incident.

What's in the full article

ARMO's full blog covers the operational detail this post intentionally leaves for the source:

• The full surface-by-surface breakdown of prompt, retrieval, tool, delegation, and memory paths in production agents.
• The APD-style runtime profiling approach, including how the kernel-level sensor builds behavioural baselines.
• The audit-to-enforcement progression for containment, including how false positives are handled before blocking turns on.
• The discussion of how eBPF-based monitoring supports process lineage and egress visibility in AI workloads.

👉 ARMO's full post covers the five ingestion surfaces, runtime baselines, and containment model in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps security practitioners connect agent identity risk to the operational controls that actually reduce exposure.