In December, the OWASP GenAI Security Project released the Top 10 for Agentic Applications — ten risks, ASI01 through ASI10, distilled from more than 100 contributors. Six months on, the vendor explainers have landed, Microsoft has mapped its agent platform against it, and the list is showing up in enterprise security questionnaires.
The instinctive move is to forward it to the security team and get back to work. I think that’s the wrong routing. Read the mitigations instead of the risk names and a pattern jumps out: almost none of them are things a security team can bolt on afterward. They’re gateways, identity systems, registries, sandboxes, and blast-radius limits — the load-bearing walls of the platform the agents run on. The security team can audit those walls. Someone has to build them first.
Here’s the translation I wish had shipped with the list: the ten risks collapse into four control planes, and platform engineering owns all four.
Plane 1: the tool boundary — ASI01, ASI02, ASI05
Agent Goal Hijack (ASI01) is prompt injection grown up: instructions smuggled into whatever the agent reads — a ticket description, a log line, a retrieved document — that redirect what it does. Tool Misuse (ASI02) is the agent using legitimate tools in illegitimate ways: destructive parameters, unexpected tool chains. Unexpected Code Execution (ASI05) is what it sounds like, and agents that can run shell commands or generate code make it a first-class concern.
These three share a root cause you cannot patch: the model can’t reliably distinguish data from instructions, so anything it ingests can steer it. The fix isn’t a better system prompt — it’s refusing to trust the model’s output in the first place. Put a gateway between the agent and its tools and enforce policy where the actions actually happen: per-agent tool allowlists, parameter validation against schemas, dry-run defaults for destructive verbs, quarantine for content arriving from untrusted sources. Code execution gets a sandbox with no ambient credentials, not a warning in the prompt.
The mental shift is the same one we made for user input twenty years ago. Nobody “trusts but verifies” a web form anymore; the form data is untrusted, period, and the validation lives server-side. Model output pointed at your infrastructure deserves exactly that status.
Plane 2: identity — ASI03, ASI07
Identity and Privilege Abuse (ASI03) exists because agents inherit. They inherit the deploying engineer’s cloud role, a service account minted in 2021, a shared API key with every scope the team ever needed. OWASP’s phrasing is blunt: agents “often inherit user or system identities, which can include high privilege credentials, session tokens, and delegated access.” Every one of those tokens is now steerable by whatever steered the agent.
I’ve argued before that agents need identities, not API keys, and this is the risk that argument was about. Per-agent identity, short-lived credentials scoped to the task at hand, and audit trails that name the agent — not the key it borrowed — turn “the automation did something” into “this agent, on this task, with this authority, did this.”
Insecure Inter-Agent Communication (ASI07) is the same problem between agents: messages with no authentication, no integrity check, no validation. If you’re wiring agents to each other, they need the same mutual-auth discipline your services already have. The protocol layer is starting to help — A2A’s 1.0 release added signed Agent Cards for cryptographic agent identity — but the requirement stands regardless of transport: an unauthenticated agent message is untrusted input with a friendly tone.
Plane 3: knowledge — ASI04, ASI06
Agentic Supply Chain Vulnerabilities (ASI04) covers everything your agents pull in at runtime: third-party MCP servers, tools from public registries, plugins, skills. The 2026 twist is that agent components are fetched and composed far more casually than libraries ever were — teams that would never curl | bash a dependency will point an agent at a community MCP server they found that afternoon. The controls are boring and proven: a vetted internal registry, pinned versions, provenance checks, and the gateway refusing tools that didn’t come through the front door.
Memory and Context Poisoning (ASI06) is the sleeper. Anything an agent remembers — session memory, long-term stores, RAG indexes — is a write surface, and a poisoned write influences every future read. One malicious document in a knowledge base becomes advice the agent confidently repeats for months. The mitigation is treating memory writes with the same suspicion as code commits: gate what’s allowed to write, attach provenance to what’s stored, and make the retrieval layer surface where an answer came from so a bad source is findable and evictable.
Plane 4: blast radius — ASI08, ASI09, ASI10
Cascading Failures (ASI08) is what happens when an error compounds through a system that acts. One wrong conclusion becomes a wrong remediation becomes a new incident — I’ve catalogued how these failure chains actually unfold in production, and the pattern is always the speed. The controls are the autonomy limits I keep returning to: bounded autonomy on what an agent may touch, budgets that throttle how much it may do per window, and circuit breakers between agents so one agent’s confusion doesn’t become the fleet’s.
Human-Agent Trust Exploitation (ASI09) is the social one: people rubber-stamp what the agent proposes, and an attacker who steers the agent inherits the trust of everyone downstream. The infrastructure contribution is an approval surface that makes review real — show the diff, the blast radius, and the rollback, not a wall of reasoning with an Approve button at the bottom.
Rogue Agents (ASI10) — compromised or misaligned agents acting harmfully while appearing legitimate — is ultimately an inventory problem before it’s a detection problem. You cannot kill what you cannot enumerate. If agent sprawl means nobody knows how many agents run with production access, ASI10 isn’t a hypothetical; it’s a scheduled discovery.
Honest caveats
The mapping is the easy part; the walls still have to be built, and each plane is real engineering. ASI09 is mostly a process-and-culture problem wearing an infrastructure accessory — better approval UX helps, but it can’t make people care. Top-10 lists trail attackers by design, so treat this one as a floor. And a control you’ve never tested is a control you have on paper: the same argument for chaos-testing your MCP layer applies to every mitigation here — inject the poisoned document, replay the hijack attempt, pull the kill switch in staging and time it.
What to do Monday
- Map your agents against the four planes. One sheet, ten rows, per agent. Empty cells are your backlog, and the exercise takes an hour.
- Find every credential your agents can reach. Inherited roles, mounted secrets, shared keys. This is ASI03 reconnaissance, and it’s rarely a flattering inventory.
- Put destructive tools behind the gateway first. If a full policy layer is a quarter away, allowlisting write-capable tools per agent is a week’s work and covers the worst of ASI02.
- Add provenance to your RAG writes. Who or what wrote each document, and when. You’ll want it the first time an agent cites something wrong and you have to trace where the rot came from.
- Test the kill switch. If shutting down every agent takes longer than your incident SLA, ASI10 already has a head start.
The Agentic Top 10 is being read as a security document, and it is one. But the subtext, risk after risk, is that agent security is a property of the platform underneath — the boundary, the identity, the knowledge, and the blast radius. Security teams will hold the clipboard. Platform teams hold the walls.