OWASP's 2026 AI Security Guidance: Secure What Agents Can Do, Not Just What They Say
OWASP updated its AI security guidance in 2026. Learn how to protect AI agents with least privilege, approval gates, logging and adversarial tests.
Published-source dates: September 2026 and October 8, 2026
A chatbot that summarizes a document is one kind of application. An AI agent that can read a mailbox, browse websites, modify records, and send messages is another. Both can be fooled by malicious text, but the second has the ability to turn a bad interpretation into an actual action.
The OWASP GenAI Security Project announced its 2026 Top 10 for LLM Applications and an Agent Control Standard in September 2026. Its companion Top 10 for Agentic Applications focuses on systems that plan and execute tasks. These resources point to an important principle: a prompt is not a security boundary.
Why tool access changes the risk
Imagine an assistant asked to summarize customer feedback. It opens an external document containing an instruction that looks like an internal command: send a customer list to an unfamiliar address. A language model might confuse that lower-trust content with authorized instructions. If the application gives the assistant broad email and database privileges, the mistake can become a data incident.
The vulnerability is not simply that the final answer contains the wrong words. The agent may have performed an unauthorized action before anyone reads the answer.
| Agent capability | Failure to anticipate | Practical control |
|---|---|---|
| Read internal documents | Exposure of unrelated sensitive files | Minimum necessary document access |
| Send messages | Unapproved outbound communication | Human approval for exact recipients and content |
| Execute code | Access beyond intended sandbox | Isolated runtime and restricted network |
| Read websites | Prompt injection in external pages | Treat web content as data, never authority |
| Persistent memory | Poisoned instructions carried forward | Reviewable and revocable memory |
Start with least privilege
The safest agent is not necessarily the least capable. It is the one whose capabilities match its assignment. A support-ticket summarizer usually needs read access to a defined ticket queue, not permission to delete customers or edit invoices. Separate research-only tools from write tools. Give different workflows distinct service identities where practical.
For sensitive operations, bind approvals to the exact tool call and parameters. “You may help with accounting” is not the same as “Approve a transfer of $500 to this verified recipient.” Money movement, external publication, data deletion, and account permission changes deserve particularly careful controls.
Untrusted content needs an explicit boundary
An external page, PDF, email, or search result can contain instructions. The surrounding application should not let those instructions override the user's authorized task. Validate tool arguments, restrict destinations, and enforce policy outside the model. Keep logs of which tool was called, by which identity, with what parameters and outcome, while minimizing unnecessary sensitive data in logs.
OWASP's October 8 quarterly exploit roundup illustrates how connected tools and excessive permissions can increase impact. The roundup explicitly says it is a curated report rather than an official OWASP publication and warns that related disclosures should not be counted as independent attacks. It is useful context, not a reliable measure of how often every type of attack occurs.
How to test an agent before deployment
A demo that produces a good final paragraph is not proof of safe behavior. Build a small adversarial test suite:
- Place a malicious instruction inside a retrieved document.
- Ask the agent to perform a task outside its authorized scope.
- Remove a required permission and verify that the agent stops safely.
- Simulate a tool timeout or partial failure.
- Check whether the logs reveal unauthorized attempts without exposing secrets.
Measure actions as well as answers. The key question is: if the model makes a plausible mistake, what does the system still prevent?
A realistic first-week plan
Review the connected apps and their scopes. Identify every agent allowed to write or delete data. Add human approval to the highest-impact operations. Test one prompt-injection scenario for each major external content source. Finally, document who can disable the agent during an incident.
This is a starting point, not an OWASP certification. A formal threat model, ongoing testing, and incident response are still necessary for high-risk deployments.
FAQ
Can a better prompt eliminate prompt injection?
No. Authorization, isolation, and tool-level controls are needed even with strong models.
Does an OWASP Top 10 checklist certify an application?
No. It is security guidance, not a universal pass/fail certification.
Should an agent be allowed to send emails automatically?
Only where the business has defined and enforced appropriate authorization, safeguards, and auditability.