Notifications
Clear all
Topic starter
15/08/2026 6:10 pm
TL;DR: Prompt injection and indirect prompt injection exploit the same LLM weakness, but the hidden version is harder to detect because malicious instructions arrive through trusted data sources such as documents, web pages, emails, and RAG pipelines, according to AppSOC. The security problem is less about code flaws than about governance of AI inputs, outputs, and delegated actions.
NHIMG editorial — based on content published by AppSOC: Prompt Injection vs Indirect Prompt Injection: One You Can See, One You Can’t
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, making proper scoping 4.5 times more protective.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when hidden instructions are allowed into AI retrieval pipelines?
A: Hidden instructions can turn trusted documents, emails, or pages into execution triggers inside an LLM or agent.
Q: Why do AI agents make prompt injection more dangerous than chat-only tools?
A: AI agents are more dangerous because they can act, not just generate text.
Q: What do security teams get wrong about prompt injection defence?
A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload.
Practitioner guidance
- Define trust boundaries for retrieved content Classify every external and internal data source feeding an LLM or agent as untrusted until provenance, validation, and intended-use rules are explicit.
- Constrain agent actions with policy and approval gates Limit what AI agents can do after interpretation by binding tool use, write actions, and data export to policy checks and human or programmatic approval where risk is high.
- Log prompt, retrieval, and response paths together Capture the retrieved documents, the assembled prompt, the model response, and any downstream action in one audit trail so investigators can reconstruct whether hidden instructions influenced behaviour.
What's in the full article
AppSOC's full research covers the operational detail this post intentionally leaves for the source:
- A side-by-side breakdown of direct and indirect prompt injection examples in real AI workflows
- Specific runtime defence patterns for RAG and agent-based architectures
- The vendor's control approach for monitoring AI interactions and auditing downstream actions
- Practical examples of how malicious instructions can be hidden inside ordinary business content
👉 Read AppSOC's analysis of prompt injection and indirect prompt injection →
Prompt injection and indirect prompt injection: are your controls keeping up?
Explore further
15/08/2026 6:17 pm
Indirect prompt injection is a governance problem, not just a model-safety problem. The attack succeeds because organisations often assume retrieved content is context, not command. Once an AI system can read documents, emails, or web pages and then take action, the trust model collapses unless the surrounding controls distinguish data from instruction. Practitioners should treat every retrieval path as an access boundary that needs explicit governance.
A question worth separating out:
Q: How should organisations govern AI-generated content before it is published?
A: Organisations should treat AI-generated content like any other controlled business output. Require human review for factual accuracy, legal exposure, privacy impact, and brand sensitivity before publication. The safest model is a documented approval workflow with named owners, logging, and the ability to retract or correct content quickly when errors are found.
👉 Read our full editorial: Prompt injection and indirect prompt injection expose AI trust gaps
