The OWASP-AI checklist on every listing, explained for providers
The OWASP-AI checklist on every listing, explained for providers
Every listing on ai-supply.store has an OWASP-AI checklist on its Security tab. This covers OWASP AI Security Top 10 (LLM01–LLM10) and OWASP ML Security Top 10 (ML01–ML10) — the de facto standard for AI-specific security evaluation.
This guide explains each item from a provider's perspective: what triggers it, and what you can do before uploading to keep it green.
OWASP AI Security Top 10 (LLM01–LLM10)
LLM01 — Prompt Injection
What it checks: Can an adversarial input override the capability's intended behaviour by injecting instructions into a prompt context?
Triggered by: Prompts or MCP servers that pass unsanitised user input directly into system prompts; templates that allow control-character injection.
How to pass: Validate and sanitise all inputs. Treat user-provided content as data, not instructions. For MCP servers, use schema validation (Zod, Pydantic) on all tool arguments.
LLM02 — Insecure Output Handling
What it checks: Does the capability's output flow unsanitised into downstream systems that interpret it (HTML rendering, SQL queries, shell commands)?
Triggered by: MCP servers that return raw LLM output and document inserting it into a database without escaping.
How to pass: Document output encoding requirements. Sanitise outputs before returning them where the context is known. Warn buyers about injection risks in dynamic output contexts.
LLM03 — Training Data Poisoning
What it checks: Is there evidence that training inputs were manipulated to influence model behaviour in adversarial ways?
Triggered by: Datasets with suspiciously uniform labels, anomalously high agreement on controversial categories, or documentation suggesting non-diverse sourcing.
How to pass: Document your dataset sourcing methodology. Include diversity statistics. Use a citation to the original data source.
LLM04 — Model Denial of Service
What it checks: Can a crafted input cause excessive compute, memory, or time consumption?
Triggered by: MCP servers that accept unbounded input sizes without validation; recursive template expansions.
How to pass: Set max_length on all text inputs. Implement timeouts. Document resource bounds in your listing description.
LLM05 — Supply Chain Vulnerabilities
What it checks: Are dependencies tracked, pinned, and free of known CVEs?
Triggered by: Floating version ranges, missing lockfiles, osv-scanner CVE findings.
How to pass: Pin all dependencies. Include a lockfile. Run osv-scanner before every upload.
LLM06 — Sensitive Information Disclosure
What it checks: Could the model or capability leak training data, system prompts, or sensitive context?
Triggered by: System prompts that include confidential instructions that could be extracted via prompt injection; models with known memorisation of training data.
How to pass: Avoid embedding confidential business logic in published system prompts. Document what information the model was trained on.
LLM07 — Insecure Plugin Design
What it checks: Do tool/plugin inputs have proper validation, and are side effects constrained?
Triggered by: MCP tool definitions with no input schema; tools that perform write operations without confirmation steps.
How to pass: Every MCP tool should have a complete JSON Schema or Zod schema for its inputs. Destructive tools should require an explicit confirm: true parameter.
LLM08 — Excessive Agency
What it checks: Does the capability request more permissions than it needs for its stated function?
Triggered by: An MCP server that requests filesystem write access when it only reads; an agent that requests manage scope when it only needs read.
How to pass: Declare minimum necessary permissions in your manifest. Document why each permission is needed.
LLM09 — Overreliance
What it checks: Does the listing encourage uncritical trust in model output without appropriate caveats?
Triggered by: Listings that claim the output is always accurate without disclaimers, especially in high-stakes domains (medical, legal, financial).
How to pass: Include appropriate accuracy caveats in your listing description. Recommend human review for high-stakes applications.
LLM10 — Model Theft
What it checks: Is the artifact structured in a way that makes extraction or reverse-engineering trivial?
Triggered by: Exposed model weights in unprotected formats; API wrappers that return full model logits.
How to pass: For proprietary models, use hosted endpoints rather than distributing weights. For open-source models, this item is generally not penalised.
OWASP ML Security Top 10 (ML01–ML10)
The ML items focus on model and dataset artifacts specifically. The most important for most providers:
- ML01 (Input manipulation / adversarial examples): Does your model documentation describe robustness to adversarial inputs?
- ML02 (Data poisoning): Was your training data curated with integrity controls?
- ML04 (Membership inference): Could an attacker determine whether a specific record was in your training data?
- ML06 (AI supply chain): Are pre-trained model components from verified sources?
- ML10 (Model poisoning): Was the model fine-tuned on untrusted data that could embed backdoors?
Practical checklist before you publish
- All tool inputs have schemas with length/type constraints (LLM01, LLM04, LLM07)
- No secrets in any file (LLM06, scanner Layer 2)
- Dependencies pinned and clean (LLM05)
- Permissions declared at minimum scope (LLM08)
- Accuracy caveats in description for any generative output (LLM09)
- Dataset sourcing documented (LLM03, ML02)
For a buyer's guide to reading this checklist on a listing page, see reading a listing's OWASP-AI security report. Everything on the platform — including publishing — is free right now.