Using the OWASP Top 10 for Agentic Applications as an engineering checklist

Security frameworks for AI agents are no longer scarce. The harder problem is turning them into work that an engineering team can schedule. The OWASP Top 10 for Agentic Applications, published in December 2025, has become a common reference in security reviews of coding agents, and the UK's National Cyber Security Centre (NCSC) has since published practical controls that line up with much of it. This article uses the OWASP list as a checklist: for each of the ten risks, what it means for a team rolling out coding agents, and one or two controls worth putting on the backlog now.

What the OWASP list is

The OWASP resource page describes the list as a "globally peer-reviewed framework" for the most critical risks in autonomous and agentic AI systems, developed with more than 100 experts, researchers and practitioners. The full document, dated December 2025 and licensed under CC BY-SA 4.0, gives each entry a description, common weaknesses, example scenarios and prevention guidance, and maps entries to the OWASP Top 10 for LLM Applications and other OWASP work.

Two ideas run through it. The first is what the authors call least agency: avoid autonomy that a task does not need, because it widens the attack surface without adding value. The second is that strong observability is essential: without a clear view of what agents do and which tools they call, small problems become system-wide ones.

The ten entries, in the document's own words, are:

1. ASI01: Agent Goal Hijack
2. ASI02: Tool Misuse and Exploitation
3. ASI03: Identity and Privilege Abuse
4. ASI04: Agentic Supply Chain Vulnerabilities
5. ASI05: Unexpected Code Execution (RCE)
6. ASI06: Memory & Context Poisoning
7. ASI07: Insecure Inter-Agent Communication
8. ASI08: Cascading Failures
9. ASI09: Human-Agent Trust Exploitation
10. ASI10: Rogue Agents

Why it is useful now

The list is ten months old, so it is not news. What has changed is how many teams now run coding agents with real permissions: shell access, repository write access, connections to issue trackers and internal APIs through MCP. The NCSC's blog on managing the cyber risk of agentic AI, published on 20 August 2026 as interim advice ahead of formal guidance, adds what the OWASP list does not try to give: maturity levels for sandboxing and network access, and a plain recommendation not to rely solely on the protections built into models and agent harnesses where the consequences of failure are high.

Used together, the two documents give a security team a vocabulary and an engineering team a list of things to build.

The checklist

ASI01: Agent Goal Hijack

An agent's goal is redirected by instructions in content it reads: a README, an issue comment, a web page. OWASP's guidance starts with treating all natural-language input as untrusted, enforcing least privilege for tools, and requiring human approval for "high-impact or goal-changing actions".

Backlog item: list the actions your coding agents can take that change something outside the working copy (pushing, merging, opening tickets, calling production APIs) and require approval for them.

ASI02: Tool Misuse and Exploitation

The agent uses a legitimate tool in a harmful way. OWASP recommends per-tool least-privilege profiles, such as read-only database queries and no send or delete rights for summarising tools, plus outbound allowlists and usage budgets.

Backlog item: make every new tool connection read-only by default, and grant write access per tool, not per server.

ASI03: Identity and Privilege Abuse

Agents inherit or accumulate permissions they should not have. OWASP calls for task-scoped, time-bound permissions with per-agent identities and short-lived credentials. The NCSC makes the same point: every agent should have its own identity, distinct from human users, and credentials with "the shortest possible lifetime".

Backlog item: stop running agents with developers' long-lived personal tokens. Issue scoped, expiring credentials for agent work.

ASI04: Agentic Supply Chain Vulnerabilities

Tools, MCP servers, prompts and models come from outside and can be tampered with. OWASP's list includes signed manifests, an inventory of AI components, pinning by content hash and an emergency switch that disables a compromised tool across all deployments at once.

Backlog item: build an inventory of which AI tools and MCP servers run on which computers, and decide how you would switch one off across the organisation in an hour.

ASI05: Unexpected Code Execution (RCE)

Agents write and run code; injected instructions can make that code harmful. OWASP's guidance includes never running agent code as root, sandboxed containers with network limits, and separating code generation from execution with validation gates. The NCSC's compute isolation levels run from no isolation (level 1) to dedicated hardware (level 4), with containers at level 2 and virtualisation at level 3.

Backlog item: decide which NCSC isolation level your agents need for each kind of work, and check what your agent's built-in sandbox actually provides. The article on sandboxing coding agents covers the common tools.

ASI06: Memory & Context Poisoning

Persistent memory, project notes and retrieved context are corrupted so that later sessions behave differently. Among OWASP's supply chain controls is putting prompts, orchestration scripts and memory schemas under version control with peer review.

Backlog item: treat agent instruction files and shared memory like code: in the repository, reviewed, with history.

ASI07: Insecure Inter-Agent Communication

Agents that talk to each other can be spoofed or can pass on injected instructions. OWASP recommends mutual authentication and signed messages between agents, with no open registration.

Backlog item: if you run multi-agent setups, document which agents can message which, and authenticate those channels. The article on protocol pivoting looks at this risk in more depth.

ASI08: Cascading Failures

OWASP frames this entry around how faults spread and grow across agents, rather than where they started. A single bad output, repeated by several agents, becomes many bad actions.

Backlog item: add limits that stop runaway loops, such as caps on calls, spend and retries per session.

ASI09: Human-Agent Trust Exploitation

This entry is about people over-relying on agents or misreading what they did. OWASP's tool guidance suggests showing a pre-execution plan or dry-run diff before high-impact actions are approved.

Backlog item: make approval prompts show exactly what will happen, with arguments, so approving is a decision rather than a reflex.

ASI10: Rogue Agents

An agent acts outside its intended behaviour without active attacker control. OWASP's mitigations include "comprehensive, immutable and signed audit logs" and kill switches with credential revocation. The NCSC's equivalent is the ability to "pull the plug" quickly, including cutting network access.

Backlog item: confirm you can stop all agent activity and revoke agent credentials quickly, and that agent actions are logged somewhere agents cannot modify.

What it means for engineering and security leaders

The OWASP list is a taxonomy, not a standard you can certify against. Its value is shared language: when a security reviewer says "ASI02", the engineering team should know which controls they mean. The NCSC blog complements it with proportionality. Not every agent needs the strongest controls; the greater an agent's autonomy, the greater the need.

A practical way to use both is to classify your agent deployments by autonomy (suggestion only, acting with approval, acting alone) and set a minimum control set for each. Coding agents in a developer's terminal with approval prompts sit in a different class from scheduled agents with merge rights.

Practical takeaways

• Map each of your agent deployments to an autonomy level, and set required controls per level.
• Default every tool and connector to read-only; require approval for destructive actions.
• Give agents their own short-lived credentials, never a developer's personal token.
• Keep an inventory of AI tools and MCP servers on every computer, and a way to switch one off everywhere.
• Choose a sandbox isolation level for each class of agent work, using the NCSC's four levels.
• Log every agent tool call to a store agents cannot change, and test your shutdown procedure.

Where SpanDock fits

Some of these controls map to documented features. The SpanDock MCP gateway, on the Premium and Enterprise plans, starts every connector read-only for everyone, holds destructive tools for approval when write access is granted, and records every call. Process inventory, on the Enterprise plan and off by default, shows which AI tools run on each computer, including ones that send no telemetry. For related reading, see what NIST is saying about AI agent security and from prompt injection to code execution in agent frameworks.