Skip to content
T threat.cafe

· Constance Ibe-Whitmore (editorial persona) · Regulation and frameworks · on threat.cafe

OWASP's two agent Top 10s, ASI and AST, mapped to controls you can actually test

OWASP now publishes two separate Top 10 lists for agents. The Top 10 for Agentic Applications (ASI01 to ASI10), released on 9 December 2025, covers risks in agent systems as a whole. The Agentic Skills Top 10 (AST01 to AST10), still an incubator project, covers the skills those agents load. The two lists overlap most on supply chain, update drift and privilege. A control matrix that cites either list should pair every cited item with a test that produces evidence, and should mark the items that can only be tested by hand today rather than claim coverage it cannot show.

Status of the two documents

The two lists do not carry the same weight, and a policy should not cite them as if they did.

  • OWASP Top 10 for Agentic Applications for 2026 (ASI). Published by the OWASP GenAI Security Project on 9 December 2025, which describes it as identifying "the most critical security risks facing autonomous and agentic AI systems" (OWASP GenAI Security Project). The full text sits in a downloadable document; the item names used below follow the restatement published by Modulos, which should be checked against the OWASP download before a policy is signed.
  • OWASP Agentic Skills Top 10 (AST). The project page lists it as an "Incubator Project" at "Version 0.0.0" while also linking a "Whitepaper (V1)" (OWASP AST Top 10). The page carries no publication date. Treat its item numbering as subject to change.

The practical consequence is a citation rule. A control matrix may cite ASI item numbers as stable references. It should cite AST items with the version and the date accessed, because an incubator list can renumber or merge items before it reaches a first release.

The two lists in one paragraph each

ASI names ten system-level risks: Agent Goal Hijack (ASI01), Tool Misuse (ASI02), Identity and Privilege Abuse (ASI03), Agentic Supply Chain Vulnerabilities (ASI04), Unexpected Code Execution (ASI05), Memory and Context Poisoning (ASI06), Insecure Inter-Agent Communication (ASI07), Cascading Failures (ASI08), Human-Agent Trust Exploitation (ASI09) and Rogue Agents (ASI10). ASI04 is the item that names MCP servers, registries and pre-built agents as inherited exposure.

AST zooms into one artifact type. Its ten items are Malicious Skills (AST01, rated Critical), Supply Chain Compromise (AST02, Critical), Over-Privileged Skills (AST03, High), Insecure Metadata (AST04, High), Untrusted External Instructions (AST05, High), Weak Isolation (AST06, High), Update Drift (AST07, Medium), Poor Scanning (AST08, Medium), No Governance (AST09, Medium) and Cross-Platform Reuse (AST10, Medium). The project also publishes an assessment checklist with numbered controls per item, such as 7.1, "pin to an immutable hash rather than a mutable tag."

Does OWASP map one list to the other?

Not on the pages read for this article. The AST07 page cross-references other AST items, OWASP LLM03 (Supply Chain), ASVS V14.2 and CWE-1329, but no ASI item (AST07: Update Drift). The checklist page contains no ASI mapping either. The crosswalk below is therefore the threat.cafe editors' mapping. It is an interpretation, and a control owner may reasonably map an item differently.

The crosswalk

Each row gives the AST item, the ASI items it most directly instantiates, one test that produces evidence, and a tooling status. Status means:

  • Native: a client or registry setting exists that a test can exercise.
  • Scanner: vendor or registry scanners exist, with documented gaps.
  • Manual: no vendor-neutral tool was found; the test is a script or a review.
AST item                 ASI link          Test that produces evidence                          Status
-----------------------  ----------------  ---------------------------------------------------  -------
AST01 Malicious Skills   ASI04, ASI01      Add a harmless canary skill name to your denylist;   Native +
                                           attempt install; expect a block and a log line       Scanner
AST02 Supply Chain       ASI04             Attempt install from an unpinned ref and from a      Native
  Compromise                               repo with an unreviewed hooks file; expect refusal
AST03 Over-Privileged    ASI02, ASI03      Deny Read(~/.ssh/**) and Read(./.env); have a test   Native
  Skills                                   skill try both; expect two denials
AST04 Insecure Metadata  ASI04, ASI09      Scan every SKILL.md for zero-width characters and    Manual
                                           compare declared vs requested tools
AST05 Untrusted External ASI01, ASI06      Extract every URL a skill references; confirm each   Manual
  Instructions                             is pinned or on an egress allowlist
AST06 Weak Isolation     ASI05             From inside the agent sandbox, request a host not    Native
                                           on the allowlist; expect a network failure
AST07 Update Drift       ASI04             Recompute installed skill hashes; diff against the   Manual
                                           hash recorded at approval
AST08 Poor Scanning      ASI04, ASI01      Submit a harmless natural-language canary skill to   Scanner
                                           your scanner; record whether it is flagged           (gap)
AST09 No Governance      ASI03, ASI10      Produce a list of every skill on every developer     Manual
                                           machine; time how long it takes
AST10 Cross-Platform     ASI04             Load the same skill in two clients; compare which    Manual
  Reuse                                    controls fire in each

Three ASI items have no AST counterpart: ASI07 (inter-agent communication), ASI08 (cascading failures) and most of ASI09 (human trust exploitation). That is expected, because AST covers one artifact type, not agent-to-agent behaviour. A matrix that cites only AST has not covered them.

Where a native control exists

AST01, AST02 and AST03 can be tested against settings that already ship. In Claude Code, a PreToolUse hook that exits with code 2 "blocks the tool call," while exit code 1 is treated as a non-blocking error, so a hook meant to enforce policy must use exit 2 (Claude Code hooks). Permission rules are evaluated "deny, then ask, then allow," and a managed deny "can't be overridden" by any other level (Claude Code permissions). Those two facts make AST03 testable in minutes: write the deny rules for credential paths, run a test skill that reads them, and keep the denial output as evidence.

AST02 has a documented test plan in the client docs. AST checklist item 2.5 says repository config files should be treated as executable code that needs approval. Claude Code publishes a table of what a repository can run before you trust its folder: hooks in the repository's settings files are used when you trusted only a parent folder and in claude -p or SDK runs, and .mcp.json servers connect without asking in a never-trusted claude -p run (Claude Code permissions). The test is to place a harmless hook, one that writes a marker file, in a scratch repository and run your CI agent there non-interactively. If the marker appears, item 2.5 is not met in that environment; the docs name --setting-sources user as the way to stop project settings loading.

AST06 is testable where a sandbox exists. The test is a network request from inside the agent's sandbox to a host that is not on its allowlist. A pass is a connection failure, captured in a log.

AST01 also has registry scanning, with stated limits. ClawHub hashes each published skill, checks it against VirusTotal and re-scans active skills daily (OpenClaw, 7 February 2026). Claude Enterprise can scan skills uploaded in claude.ai and Cowork and block failures, but the scan does not cover skills uploaded through the Skills API, skills already present when scanning was enabled, or organizations with CMEK, ZDR or HIPAA configurations (Anthropic, Agent Skills enterprise docs). A matrix that cites a scanner for AST01 should name its scope.

Items that need a manual test today

AST08 is the weakest row, and the vendors say so. OpenClaw's own announcement states that a skill instructing an agent to do something malicious "won't trigger a virus signature," and that "a clean scan doesn't mean a skill is safe." AST08's description makes the same point: "Natural-language-plus-code blends defeat signature scanners." The test above, a harmless canary instruction such as a skill that tells the agent to print a fixed marker string and stop, measures whether your scanner reads the natural-language layer at all. Record the result; do not assume it.

AST04, AST05 and AST07 reduce to scripts. Zero-width characters can be found with a single search across skill folders:

grep -rlP '[\x{200B}-\x{200D}\x{2060}\x{FEFF}]' ~/.claude/skills ./.claude/skills

URL extraction for AST05 and hash comparison for AST07 are similarly short. None of them is hard. None of them runs unless someone schedules it.

AST09 and AST10 are organizational tests. AST09 asks for an inventory, an approval record and a revocation path. The honest test is to time how long it takes to produce the list of every skill on every developer machine. GitHub's MCP allowlist illustrates the AST10 problem: it is enforced in the Copilot app, Copilot CLI and VS Code, and the changelog names no other client (GitHub changelog, 6 August 2026). A skill or server blocked in one client may load in another.

How to cite these lists in a control matrix

A defensible entry has five fields. Use this template for each item you cite:

Framework item:   OWASP AST07 Update Drift (incubator v0.0.0, accessed 2026-10-15)
Related item:     OWASP ASI04 Agentic Supply Chain Vulnerabilities (Dec 2025)
Control:          Skills pinned to content hash at approval; drift check weekly
Test & evidence:  Hash diff script output, stored with date and machine count
Status:           Manual. No vendor-neutral tool in use; owner: platform team

Three drafting rules follow from the documents' status. First, a matrix shall not state that it "covers the OWASP agentic Top 10" without naming which list. Second, it should record the AST version beside every AST citation, because v0.0.0 can change. Third, it may mark an item "not yet testable" when that is the truth; an auditor can work with a documented gap more easily than with an overstated control.

Open questions for the next revision

Two things would change this crosswalk. If AST reaches a first release with different numbering, the rows need renumbering, not rethinking, because the underlying risks are stable. If OWASP publishes its own ASI-to-AST mapping, it should replace the editors' mapping in the second column. Until then, the column is an interpretation and should be labelled as one in any audit file.

AST01, AST07 and AST10 are the rows a shared list of known-bad skills and servers speaks to most directly; the threat.cafe board records those incidents with sources and finder credit.

Sources

#owasp #agentic-ai #agent-skills #control-mapping #governance

All posts