The OWASP Agentic AI Top 10: What Builders on AWS Need to Know • Technodrone☁️">Skip to main content
On this page
This is post #0 of the OWASP Agentic AI Top 10: What Builders on AWS Need to Know series.<br>You’ve secured your GenAI chatbot. You’ve got prompt injection filters, output validation, maybe even some content moderation guardrails in front of your model. You feel pretty good about it.<br>But here’s the thing. That chatbot? It’s a single API call. Ask a question, get an answer. Done.<br>Now imagine giving that same model memory , tools , the ability to call APIs , and multi-step autonomy to go figure things out on its own.<br>That’s an agent. And it’s a completely different security problem.<br>From Chatbot to Agent: What Actually Changed<br>Let me be direct about this. A chatbot and an agent are not the same thing with different marketing names. They’re fundamentally different architectures with fundamentally different threat surfaces.<br>A chatbot:<br>Receives a prompt<br>Generates a response<br>That’s it. Stateless. Done.<br>An agent:<br>Receives a goal<br>Plans a sequence of steps to achieve it<br>Calls tools (APIs, databases, file systems, other services)<br>Remembers context across sessions<br>Decides what to do next based on results<br>Delegates to other agents<br>Repeats until the goal is achieved (or until something goes very wrong)<br>See the difference? With a chatbot, the worst case is a bad answer. With an agent, the worst case is an autonomous system taking real actions in your production environment based on corrupted instructions it picked up from a poisoned document three days ago.<br>That’s not hypothetical. That’s happening right now.<br>Why the OWASP LLM Top 10 Wasn’t Enough<br>The OWASP Top 10 for LLM Applications was a solid start. It covered prompt injection, insecure output handling, training data poisoning, and the usual suspects for single-model applications.<br>But agents break the assumptions that list was built on.<br>When OWASP published the Top 10 for Agentic Applications in December 2025, it wasn’t because they were bored. It was because the security community realized that agents introduce threats that simply don’t exist in stateless LLM interactions:<br>What happens when an agent’s goal gets hijacked mid-execution?<br>What happens when one agent passes poisoned context to another?<br>What happens when an agent accumulates privileges across a chain of delegations?<br>What happens when a failure in one agent cascades through an entire system?<br>These aren’t theoretical. They have CVEs. They have incident reports. They have names:<br>EchoLeak (CVE-2025-32711) - a zero-click prompt injection in Microsoft 365 Copilot that exfiltrated confidential emails without any user interaction<br>ChatGPT Memory Poisoning - false memories planted via indirect prompt injection created a persistent exfiltration channel<br>AutoJack (AutoGen Studio) - a single malicious web page could RCE the host running your AI agent<br>CVE-2025-55319 (VS Code Agentic AI) - command injection via VS Code’s agentic AI functionality, no user interaction required<br>JADEPUFFER - the first fully autonomous AI-agent-conducted ransomware attack, exploiting CVE-2025-3248 in Langflow<br>The OWASP Agentic Top 10 At A Glance<br>Here’s what the list looks like:<br>#ThreatOne-linerASI01Agent Goal HijackPrompt injection redirects agent objectives mid-executionASI02Tool Misuse & ExploitationAgents weaponize their own legitimate toolsASI03Identity & Privilege AbuseAgents inherit or escalate privileges beyond intended scopeASI04Agentic Supply Chain VulnerabilitiesCompromised plugins, MCP servers, third-party toolsASI05Unexpected Code Execution (RCE)Agent-generated code runs without sandboxingASI06Memory & Context PoisoningPersistent corruption of agent memory or RAG dataASI07Insecure Inter-Agent CommunicationUnvalidated messages between agentsASI08Cascading FailuresOne agent failure propagates through the systemASI09Human-Agent Trust ExploitationOver-reliance on agent outputs, social engineering via agentsASI10Rogue AgentsAgents operating beyond intended boundaries without attacker involvementIf you’re building agents on AWS (or anywhere, really), every single one of these applies to you.<br>Three Principles That Run Through Everything<br>After reading the full OWASP document (all 57 pages of it, and yes it took a while), three principles keep coming back in every single mitigation:<br>1. Least Privilege (and its cousin: Least Autonomy)<br>Don’t give an agent more permissions than it needs. Don’t give it more autonomy than it needs. If your agent doesn’t need to delete files, don’t give it the tool. If it doesn’t need to operate unsupervised, don’t let it.<br>OWASP uses the term “Excessive Agency” and it’s the perfect framing. Every capability you give an agent is attack surface. Every tool, every permission, every degree of freedom.<br>2. Observability<br>If you can’t see what...