The OWASP Agentic AI Top 10: What Builders on AWS Need to Know

This is post #0 of the OWASP Agentic AI Top 10: What Builders on AWS Need to Know series.

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.

But here’s the thing. That chatbot? It’s a single API call. Ask a question, get an answer. Done.

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.

That’s an agent. And it’s a completely different security problem.

From Chatbot to Agent: What Actually Changed

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.

A chatbot:

• Receives a prompt
• Generates a response
• That’s it. Stateless. Done.

An agent:

• Receives a goal
• Plans a sequence of steps to achieve it
• Calls tools (APIs, databases, file systems, other services)
• Remembers context across sessions
• Decides what to do next based on results
• Delegates to other agents
• Repeats until the goal is achieved (or until something goes very wrong)

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.

That’s not hypothetical. That’s happening right now.

Why the OWASP LLM Top 10 Wasn’t Enough

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.

But agents break the assumptions that list was built on.

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:

• What happens when an agent’s goal gets hijacked mid-execution?
• What happens when one agent passes poisoned context to another?
• What happens when an agent accumulates privileges across a chain of delegations?
• What happens when a failure in one agent cascades through an entire system?

These aren’t theoretical. They have CVEs. They have incident reports. They have names:

• EchoLeak (CVE-2025-32711) - a zero-click prompt injection in Microsoft 365 Copilot that exfiltrated confidential emails without any user interaction
• ChatGPT Memory Poisoning - false memories planted via indirect prompt injection created a persistent exfiltration channel
• AutoJack (AutoGen Studio) - a single malicious web page could RCE the host running your AI agent
• CVE-2025-55319 (VS Code Agentic AI) - command injection via VS Code’s agentic AI functionality, no user interaction required
• JADEPUFFER - the first fully autonomous AI-agent-conducted ransomware attack, exploiting CVE-2025-3248 in Langflow

The OWASP Agentic Top 10 At A Glance

Here’s what the list looks like:

If you’re building agents on AWS (or anywhere, really), every single one of these applies to you.

Three Principles That Run Through Everything

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:

1. Least Privilege (and its cousin: Least Autonomy)

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.

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.

2. Observability

If you can’t see what your agent is doing, why it’s doing it, and which tools it’s invoking, you’re flying blind. And unlike a human employee, an agent won’t tell you when something feels off.

Comprehensive logging, behavioral baselines, anomaly detection. Non-negotiable.

3. Human-in-the-Loop

For high-impact actions, a human needs to approve. Not rubber-stamp. Actually review. The moment you remove human oversight from irreversible actions is the moment you accept whatever your agent decides to do at 3 AM on a Sunday.

How This Maps to AWS

When I started reading this doc, I started thinking. How would I implement these mitigations on AWS? Can you even do it with existing services? I couldn’t really find a proper answer anywhere. Not a systematic one, at least. So I decided to write it myself.

None of this requires exotic tooling. It’s IAM, Step Functions, Bedrock Guardrails, CloudWatch. Services you already know. The challenge is knowing where to apply them and why.

What This Series Covers

Over the next 10 posts, I’m going to take each one of these threats and break it down:

• What it is and why it matters specifically in agentic systems
• Real attack scenarios from the OWASP document and public incidents
• AWS mitigation playbook with specific services, configurations, and architecture patterns
• Code and config examples where relevant (CDK, IAM policies, Bedrock SDK)

By the end, you’ll have a practical, AWS-specific security playbook for agentic AI systems.

The series of 12 posts, is long (really long, 25,000+ words). You are going to need patience and time to read through it all. I have divided it up in to posts, one for each of the top 10, and an opening and closing post.

Up Next

Post 1: Agent Goal Hijack (ASI01) - How prompt injection evolves when agents have multi-step autonomy, and how Amazon Bedrock Guardrails helps you defend against it.

I would be very interested to hear your thoughts or comments, so please feel free to ping me on LinkedIn or Twitter. If you’re already building agents and have hit security challenges, I genuinely want to know.

Let’s go!!