OWASP Published a Top 10 for AI Agents. We Ran It Against a Live System and Failed Two of Them.
OWASP published its first Top 10 for Agentic Applications in December 2025. Nine months of coverage later, almost every explainer stops at what each risk means in theory. None run the list against a system that's actually live.
We did — against Archon, our own multi-agent system, the same one behind how we think about AI governance for small teams. Eight real findings came out of that pass, fixed the same day. Three map cleanly onto the OWASP list, and two landed in the same category — itself the finding.
What the OWASP Top 10 for Agentic Applications Actually Is
OWASP's Gen AI Security Project split agent risk out of the older LLM Top 10, because an agent that calls tools and holds memory fails differently than a chatbot that only answers questions:
- ASI01 — Agent Goal Hijack: an attacker redirects the agent's objective.
- ASI02 — Tool Misuse & Exploitation: a legitimate tool used the wrong way.
- ASI03 — Identity & Privilege Abuse: an agent has more access than the task needs.
- ASI04 — Agentic Supply Chain Vulnerabilities: a trusted dependency is compromised.
- ASI05 — Unexpected Code Execution: the agent runs code it shouldn't.
- ASI06 — Memory & Context Poisoning: bad data corrupts long-term memory.
- ASI07 — Insecure Inter-Agent Communication: one agent impersonates another.
- ASI08 — Cascading Failures: a small failure propagates unchecked.
- ASI09 — Human-Agent Trust Exploitation: persuasive output gets a bad approval.
- ASI10 — Rogue Agents: an agent drifts from its job, no attacker required.
We Ran It Against a System That Was Already Live
Most write-ups on this list come from vendors describing risks in the abstract. None appear to run a multi-agent system of their own. Archon does — the system behind our content pipeline, built on the same resilience-first thinking as our second-brain setup. So instead of reading the list, we tested against it.
ASI03: Identity & Privilege Abuse — Two of Three Fixes Landed Here
- An unscoped IDOR. One internal endpoint returned whatever object it was pointed to, without re-checking that the requesting agent had a reason to see it. Nothing was "hacked" — a reference just went unverified.
- Enforcement gaps across declared scopes. Tools declared the access they needed, a normal pattern, but enforcement wasn't checking every declared scope consistently. A tool could reach further than its declaration allowed.
Same failure, different clothes: a permission was written down, and the system trusted the declaration more than it verified the boundary. That's why privilege problems cluster instead of showing up as one-offs — see what an access-control gap costs when nobody catches it.
ASI02: Tool Misuse & Exploitation — The Third Fix
A PAT-minting bug. A tool built to mint short-lived, narrowly-scoped access tokens for one legitimate purpose could be invoked in a way that produced a token with broader scope than intended — used exactly as designed, but the design let it go further than it should.
No prompt injection, no external attacker: an authorized tool did something the system didn't mean to allow. Same lesson as a webhook that passed every test and was still wrong — green checks measure what you tested, not what's true.
Where We Haven't Found a Bug Yet (Not the Same as Clear)
The other eight categories didn't turn up a fix in this pass — a fact about this audit, not a guarantee:
- Agent Goal Hijack — has anyone fed your agent poisoned instructions through a retrieved document, not just the chat box?
- Agentic Supply Chain Vulnerabilities — do you know every third-party tool and model your agents depend on?
- Unexpected Code Execution — if your agent can write and run code, what stops it running the wrong code?
- Memory & Context Poisoning — could bad data enter long-term memory and corrupt later answers, the grounding problem behind RAG Explained?
- Insecure Inter-Agent Communication — running more than one agent, can one impersonate another today?
- Cascading Failures — does one agent's bad output silently become another's bad input, the dependency problem behind why software projects go late?
- Human-Agent Trust Exploitation — how much does a person trust an agent's summary unchecked, the same question a support AI has to answer honestly?
- Rogue Agents — would you notice an agent drifting from its job before a customer did?
A 30-Day Way to Audit Your Own Agents Against This List
Week 1 — Map every tool, credential, and scope each agent can reach. Most teams can't produce this list on demand — that gap is itself the finding.
Week 2 — Rank the ten categories by how your system is built: tool-heavy leans ASI02, multi-tenant leans ASI03, multi-agent leans ASI07/ASI08. Pick two or three before testing everything at once.
Week 3 — Test those categories adversarially, the way an attacker would, not a general code review with "security" in the title.
Week 4 — Fix what you find the same day. Write down what you can't fix yet, and why.
What to Measure Instead of "Did It Pass"
- How many privilege boundaries you can actually name, not just assume exist.
- How many tools can act outside their declared scope, tested or not.
- Time from finding a real issue to fixing it — same-day is the bar.
If You Want ZPro to Build This With You
At Zdravevski Professionals, an AI Systems Audit runs your own agents against this exact list — a targeted pass against the categories that apply to how your system is built. We can:
- map every tool, credential, and scope your agents can reach
- run adversarial tests against the categories most relevant to your architecture
- fix what we find the same day, the way we do it on our own systems
- leave you a written record of what's covered and what still needs attention