On this page · 8 sections
Summary. Prompt injection is still the number one entry on the OWASP LLM Top 10 in 2026, and security researchers now treat it as an unsolved problem rather than a bug awaiting a patch. Documented injection attempts against enterprise AI rose about 340% year over year in late 2025, and indirect attacks, instructions hidden in an email, document or web page, now make up more than 55% of incidents with 20-30% higher success rates than direct attempts. With agentic AI, a successful injection is no longer a bad answer: it can mean a fraudulent transaction, data exfiltration or system compromise. The stakes are also regulatory. Under the EU AI Act, fines can reach €35 million or 7% of global annual turnover, and its rules for general-purpose models carry enforcement from August 2, 2026. This guide is for CTOs and security engineers who need to contain the risk, because you cannot filter it away.
Why prompt injection got worse, not better
A language model cannot reliably tell the difference between instructions from you and instructions hidden in the content it reads. That is the whole problem, and agents made it sharper. An assistant that only answers questions can be tricked into a wrong reply. An agent that reads email, queries databases and calls tools can be tricked into acting: moving money, deleting records, or leaking data to an attacker's server.
Simon Willison, an independent AI researcher, named the dangerous combination the "lethal trifecta": "access to private data, exposure to untrusted content, and the ability to externally communicate." When one system has all three, an attacker who controls any untrusted input can read your data and send it out. Coding agents are the worst case because they combine all three by design, which is why a June 2026 analysis described injection as possibly a permanent property of the architecture, not a defect that gets fixed.
That reframing matters. If you build on the assumption that a filter will catch every malicious instruction, you will ship an insecure system. Detection helps, but it is not a control you can depend on.
The three failure modes to design against
Agent security is broader than a single trick. Three risks dominate, and traditional application security tooling covers none of them well.
Prompt injection and jailbreaks: untrusted input overrides the agent's intended behavior. Indirect injection, hidden in content the agent reads, is the most dangerous vector.
Memory poisoning: an attacker corrupts the agent's long-term memory store, so a bad instruction persists across sessions and fires later.
Tool and plugin misuse: the agent is steered into calling a legitimate tool with harmful parameters, turning a normal capability into an attack.
You cannot filter it away, so contain the agent
Because injection is unsolved at the model layer, the working strategy in 2026 is containment: assume some injections will land, and make sure a landed injection cannot do much. Guardrails are a platform problem, not something each app team reinvents. The controls below are defense in depth, and they compound.
| Control | What it limits | How to apply it |
|---|---|---|
| Least privilege per tool | The scope of any successful injection | Per-tool permissions, allowed and blocked parameters, rate limits |
| Human-in-the-loop | Irreversible or high-risk actions | Approval step before moving money, granting access or deleting data |
| Sandboxed tool execution | The blast radius of a compromised call | Containers with gVisor or Firecracker, strict memory, CPU and network limits |
| Output validation | Data exfiltration to attackers | Scan responses for secrets and suspicious URLs before they leave |
| Dual LLM pattern | Untrusted data reaching privileged actions | A quarantined model handles untrusted content; a privileged model never sees it raw |
| Red teaming | Unknown attack paths | Regular tests with tools like Promptfoo and NVIDIA Garak |
Two of these deserve emphasis. Least privilege is the highest-use control: an agent that cannot call a payment tool cannot be tricked into a fraudulent payment, so scope every tool to the minimum it needs and nothing more. Human-in-the-loop is the backstop for anything irreversible; Google's approach uses a user-confirmation framework that asks a person to review and approve agent-generated actions before they run. The dual LLM pattern, a privileged model kept away from raw untrusted data and a quarantined model that processes it in isolation, is the architectural version of the same idea.
This containment mindset sits inside a broader plan. It builds on the layers in our guide to enterprise AI agent governance, the boundaries described in privacy-first AI architecture, and the delivery discipline behind enterprise AI agents in production. The security review is part of sound generative AI enterprise strategy, not a bolt-on.
Governance and compliance in 2026
Security and compliance now point the same way. Three frameworks anchor most enterprise programs: the OWASP LLM Top 10 as the technical reference, the NIST AI Risk Management Framework for governance, and the EU AI Act for legal obligation. The Act's rules for general-purpose AI models carry enforcement powers from August 2, 2026; a May 2026 agreement pushed some high-risk (Annex III) obligations to December 2, 2027, so the deadline picture is staggered rather than a single cliff. The financial exposure is real: penalties can reach €35 million or 7% of worldwide annual turnover for the most serious violations. Gartner has predicted that AI-related legal claims will exceed 2,000 by the end of 2026, tied to insufficient guardrails. Treat runtime security and human oversight as compliance evidence, and log every agent action so you can show an auditor what happened and why.
India-specific considerations
For Indian enterprises, agent security intersects directly with the Digital Personal Data Protection Act. If an agent reads or moves personal data, an injection that exfiltrates it is a reportable personal-data breach, with the same consent, security-safeguard and breach-notification duties that apply to any other system. The practical controls are identical to the ones above, with one addition: a data-classification gate so agents that touch personal or regulated data run under stricter tool permissions and mandatory human approval. Budget for security review as part of the build, not after an incident, because in rupee terms the cost of a breach and its notification dwarfs the cost of scoping tools correctly up front.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based, CMMI Level 5 technology consultancy that builds and secures enterprise AI agents. We design least-privilege tool permissions, human-in-the-loop approval for high-risk actions, sandboxed execution and output validation, then red-team the result and wire in the logging you need for OWASP, NIST and EU AI Act evidence. For an agent security review, contact our team.
References
_Last updated: July 9, 2026._
