We Found a Real Gap in AI Vulnerability Classification. Here's How We're Filling It

#mcp #security #ai #llm

TL;DR: CVE and CWE can't classify behavioral vulnerabilities in agentic AI components (MCP servers, agent skills, LLM plugins) because neither was built to describe something that isn't tied to a specific package or line of code. We built AVE, an open standard that fills that gap, and a second independent implementer just proved the ID scheme actually interoperates across unrelated codebases. Repo, schema, and real evidence below.

The problem, concretely

Run two different security scanners against the same MCP server. Both catch a prompt injection hidden in a tool description. Both report it.
Under two completely different names, with no shared identifier linking the findings at all.

This isn't a hypothetical. It's the exact situation that got this whole project started. And it doesn't happen with conventional software vulnerabilities, because CVE and CWE already solved the "shared vocabulary" problem for those, decades ago.

CVE identifies a package at a specific version. CWE names a weakness pattern in code. Neither has any concept of "a behavioral pattern that shows up in arbitrary text, with no fixed package or version at all," which is exactly what most agentic AI vulnerabilities actually are. A malicious instruction embedded in a tool description isn't a package CVE. It's not a CWE either, not cleanly. It's behavioral, and the same underlying attack can appear in effectively unlimited textual forms across completely unrelated codebases.

What we built

AVE (Agentic Vulnerability Enumeration): an open, vendor-neutral
standard specifically for these behavioral classes. Here's the shape of one actual record, trimmed for length:

{
  "ave_id": "AVE-2026-00002",
  "schema_version": "1.1.0",
  "component_type": "mcp_server",
  "title": "MCP tool description behavioral injection",
  "attack_class": "Prompt Injection - Tool Description",
  "severity": "HIGH",
  "aivss_score": 7.3,
  "owasp_mcp": ["MCP03", "MCP10"],
  "behavioral_fingerprint": "A tool description contains embedded instructions the model treats as authoritative context rather than inert metadata, causing it to deviate from user intent without any explicit tool call triggering the deviation.",
  "indicators_of_compromise": ["..."],
  "remediation": "..."
}

Stable ID, real severity score, crosswalks to existing frameworks,
enough detection detail that a scanner author can actually build a rule against it, not just a category name to file something under.

59 records total right now, each a genuinely distinct behavioral class. Scored with OWASP's own AIVSS framework (v0.8), a CVSS-style formula extended with agentic-specific amplification factors, not a severity scale we made up ourselves. Every record crosswalks into OWASP's MCP Top 10, the Agentic Security Initiative Top 10, and MITRE ATLAS where it applies, built deliberately as a layer underneath those frameworks, not a rival taxonomy sitting next to them.

Consuming it

Three integration patterns depending on your environment, fully covered in the implementer guide, but the smallest version is one line:

import httpx

def enrich_finding(ave_id: str) -> dict:
    resp = httpx.get(f"https://api.aveproject.org/records/{ave_id}", timeout=5)
    resp.raise_for_status()
    return resp.json()

finding = {
    "rule_id": "your-rule-id",
    "ave_id": "AVE-2026-00002",  # this line is the entire integration
    "severity": "HIGH",
}

For air-gapped or regulated environments, there's a bundled offline
JSON dump instead, dist/ave-records-latest.json, an unversioned alias that's always current, regenerated automatically on every corpus change, no release tag or network call required at scan time.

The evidence that actually matters

Anyone can claim their ID scheme is interoperable. Here's what makes this one worth believing: a completely independent tool, a static config-file auditor with zero shared code or ruleset with anything we'd built, ran a crosswalk against the same test files our own scanner used.
On the large majority of overlapping findings, both tools independently emitted the identical AVE ID. The handful of disagreements traced to each tool's own detection-pattern gaps, not to genuine disagreement about the classification.

Two unrelated codebases converging on the same answer, without
coordinating, is a meaningfully stronger signal than one tool simply adopting another's naming convention.

Where this honestly stands

Independently governed, not an OWASP project (not yet, no promises
either way). Apache 2.0, code and records both. A real second implementer with real cross-validation data, which is further along
than most young open standards get.

What I'd actually want from this community

If you've built detection tooling and hit the same "everyone names it differently" wall, or if you look at this and see something wrong, missing, or already solved better elsewhere, that's exactly the feedback this is worth posting for.