Notifications
Clear all
Topic starter
18/08/2026 2:15 pm
TL;DR: Direct and indirect prompt injection differ only by entry path, not by what happens after the attacker-written text reaches the model, according to ARMO. In production agents, untrusted text arrives through prompts, retrieved data, tool and MCP responses, other agents, and persisted memory, so containment has to work at the context-window boundary.
NHIMG editorial — based on content published by ARMO: Direct vs Indirect Prompt Injection: The Real Difference
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read ARMO's analysis of direct vs indirect prompt injection and AI agent containment →
Direct vs indirect prompt injection: where does the split stop mattering?
Explore further
18/08/2026 3:07 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Direct vs indirect prompt injection ends at the context window
