OWASP LLM Top 10 is not enough
The OWASP LLM Top 10 is a runtime framework. It does not cover the persistent artifacts that ship capability to agents. Here is the map between the two and where each one's responsibility ends.
Where OWASP's framework ends
OWASP's LLM Top 10 is one of the more successful security frameworks of the last five years. It named threats quickly, kept the list short, and made it actionable. The 2026 revision continues that tradition. Use it. We do.
But the framework was designed around the question "how do I secure an application that calls an LLM?" That was the dominant shape of the problem in 2023 and 2024. In 2026 the dominant shape is different: agents that load persistent artifacts and act on them. The threat model shifts from "bad input to a model" to "bad artifact in the agent's capability stack".
The LLM Top 10 addresses the first shift. It does not address the second. Both are real; both need coverage.
Mapping OWASP items to their artifact-side analogs
The ten items in current OWASP LLM revision (simplified):
- Prompt injection
- Insecure output handling
- Training data poisoning
- Model denial of service
- Supply chain vulnerabilities
- Sensitive information disclosure
- Insecure plugin design
- Excessive agency
- Overreliance
- Model theft
Each has a runtime framing. Each also has an artifact-side framing that OWASP does not currently enumerate.
1. Prompt injection → Rule-file override
Runtime prompt injection is an input. Artifact-side prompt injection is a file: a .cursorrules or agents.md that persistently overrides the model's behavior on every invocation in that repo. Same primitive, different persistence. Catch the runtime case at the gateway; catch the artifact case on ingest. Coverage for the artifact case.
2. Insecure output handling → Tool-call smuggling
Insecure output handling assumes the output comes from a model. Tool-call smuggling is output from an artifact (usually a skill) being passed to a downstream tool. The downstream tool cannot tell. Detect on the artifact.
3. Training data poisoning → Artifact registry poisoning
OWASP's training data item covers model training. The artifact analog is a registry (Anthropic skills marketplace, a GitHub org, an MCP catalog) that contains hostile entries. Mitigations are different: registry curation, signing, publisher verification. This is where the skill scanning post lives.
4. Model denial of service → Capability explosion
Runtime DoS is a model pinned at max load. Artifact-side DoS is an agent loaded with so many MCP servers and skills that its planning becomes incoherent. Different root cause, similar operational impact. The fix is capability enumeration and scope pinning.
5. Supply chain vulnerabilities → The whole artifact ecosystem
This is the OWASP item closest to our thesis. The current item mostly covers model weights and foundational dependencies. It does not enumerate skills, MCP servers, rule files, or agent repos as first-class supply chain components. We think it should, and we make that case at length.
6. Sensitive information disclosure → Credential-in-artifact
Runtime sensitive disclosure is a model leaking training data or context. The artifact analog is a credential hardcoded into a skill or plaintext in an MCP config. Static signatures catch this at very high precision.
7. Insecure plugin design → MCP server threat model
OWASP's plugin item covers plugin vulnerabilities. MCP is now the dominant plugin surface in AI agents, and MCP-specific threat modelling (unsigned servers, tool-description poisoning, capability drift) is not yet enumerated in the Top 10. We published a ten-minute field guide for it.
8. Excessive agency → Sub-agent spawning
Excessive agency covers an agent with too much capability. Sub-agent spawning is how an agent gets that capability out-of-band: artifact tells agent to spawn sub-agent, sub-agent bypasses policy. Detect in the artifact, not at runtime.
9. Overreliance → Unreviewed artifact adoption
Runtime overreliance is users trusting model outputs. Artifact overreliance is engineering orgs adopting skills and MCP servers from the community without review. Same cultural failure mode, different asset.
10. Model theft → Artifact theft / re-distribution
Models are expensive to steal. Artifacts are trivial to steal and re-distribute, often for legitimate reuse but sometimes with silent modifications. Provenance and signing matter.
What a complementary framework needs
Our working list for an artifact-side top ten:
- Credential exfiltration in artifact source.
- Tool-call smuggling via skill or rule file output.
- Silent network calls not declared in the capability manifest.
- Capability drift between published and observed behavior.
- Dependency confusion across public and private registries.
- Sub-agent spawning with attacker-controlled system prompts.
- Prompt override in persistent rule files.
- Typosquatting and registry impersonation.
- Unsigned publishing and capability manifest forgery.
- Plaintext secrets in configuration files.
This is not meant to replace OWASP. It is meant to sit next to it. Use OWASP for the runtime surface. Use an artifact-side framework for the persistent surface.
What runtime defenses cannot do
A runtime AI firewall or DLP proxy inspects the input going to the model and the output coming back. It is a necessary control. It is not sufficient for artifact security because:
- By the time the artifact gets loaded, it is part of the agent's trusted capability stack.
- The artifact runs under the agent's credentials; runtime proxies see the agent's legitimate identity.
- Artifact behavior can be indistinguishable from legitimate tool use at the wire level.
You have to catch the artifact before it loads. Scan on ingest. Pin on use. That is the artifact-side equivalent of what runtime defenses provide on the input side.
Related: