AVE MCP server

The open behavioral classification standard for agentic AI components.

Stable IDs, AIVSS scores, and behavioral fingerprints for every way a skill file, MCP server, system prompt, or agent plugin can be weaponized — scored consistently, mapped to the frameworks security teams already report against.

Registry · Schema · Crosswalks · Architecture · Scoring · Versions · API · Implementer guide

---

What is AVE?

Skill files, MCP server manifests, and system prompts are executable instructions, not documentation. Any process that loads them runs them. There is no compiler, no type checker, no sandbox. The runtime is an LLM that reads natural language and acts on it.

Existing vulnerability standards were built for conventional software. CVE identifies flaws in a specific product and version. OSV maps them to package and version ranges. Neither can describe a prompt injection hidden in an MCP tool description — there is no package, no version, no vulnerable dependency. The danger is in what the component does, not what it imports.

AVE fills that gap. It assigns stable identifiers to distinct behavioral classes in agentic AI, scores them with OWASP AIVSS v0.8, and maps every record to OWASP MCP Top 10 and MITRE ATLAS so findings land in frameworks defenders already use.

AVE is a standard, not a product. The bawbel-scanner implements it as the reference implementation. Any tool can map to it — see the implementer guide for how.

What AVE is not

AVE is a naming and classification standard. It assigns stable IDs to behavioral vulnerability classes and describes how to detect them. It is not a runtime enforcement mechanism, and an AVE ID on its own stops nothing. Enforcement requires a separate policy or gating layer that consumes AVE's records, the same relationship CWE has to an actual static analyzer, or a CVE has to a patch management system.

Your CI pipeline scans dependencies for known package vulnerabilities.
It does not scan your SKILL.md for prompt injection.
AVE fixes that.

---

How it works

AVE keeps three things apart on purpose.

	What it is	Where it lives
The standard	Records, each defining one behavioral class; the schema they validate against; two conformance fixtures per record; crosswalks to other frameworks and tools	this repository
Implementations	Scanners, gateways and dashboards that detect a class and report it under its ave_id. Their detection rules are their own	their own repositories
Consumers	CI gates, SARIF viewers, dashboards and ticketing: anything that reads findings or records and keys on ave_id	your systems

Definitions here, detections there. An AVE record is not a detection rule, and an ave_id on its own stops nothing.

A record is a class. A finding is one detection of it.

AVE record (this repository)	Finding (an implementation)
a behavioral class, written once by a person	one detection, produced by every scan
behavioral_fingerprint, severity, aivss, framework mappings, indicators, remediation	the ave_id, plus where and why it fired
may declare a confidence_baseline	assigns the actual confidence
never carries a confidence	always carries one

A record's life

1. Propose. A researcher finds an agentic behavior no record covers, with a citable primary source, and opens an issue. A new ave_id is only for a genuinely distinct behavioral class.
2. Write. The record (fingerprint, indicators, remediation, AIVSS score, framework mappings) and two fixtures: one text a conforming implementation must flag, one it must not.
3. Validate. CI checks the record against the schema, recomputes its score, and requires both fixtures. A maintainer reviews.
4. Publish. dist/ave-records-latest.json moves, and the API follows within about 15 minutes. The next catalog release freezes a copy: tagged, checksummed and attested.
5. Implement. A tool maps its own rules to the ave_id. Its findings carry the id, and each run records the catalog release it scanned against.
6. Consume. CI gates, SARIF viewers and dashboards deduplicate and report on the id, across tools.

---

Using AVE

curl -s https://api.aveproject.org/v1/records/AVE-2026-00046 \
  | jq '{ave_id, title, severity, score: .aivss.aivss_score, owasp_mcp}'

{
  "ave_id": "AVE-2026-00046",
  "title": "MCP tool hook hijacking - redirect tool execution to attacker-controlled callback",
  "severity": "CRITICAL",
  "score": 9.2,
  "owasp_mcp": ["MCP03", "MCP06"]
}

I want to	Do this
Read what a class is and how it is scored	Open it in the registry, or read records/AVE-YYYY-NNNNN.json
Look one up from a script, IDE or chat	Call the API
Filter or analyze the whole catalog	Download it and query it with jq or any JSON tool
Gate CI on a fixed set of records	Pin a catalog release and verify its checksums
Scan a skill file or MCP server	Run a tool that implements AVE, such as the reference implementation
Add AVE ids to my own tool	Follow the implementer guide and the AVE-in-SARIF convention
Compare AVE with another framework or scanner	Read the crosswalks
Propose a new behavioral class	Add a record

Filter the whole catalog

dist/ave-records-latest.json is every published record as one JSON array.

curl -sL https://raw.githubusercontent.com/aveproject/ave/main/dist/ave-records-latest.json -o ave-records.json

# every active CRITICAL and HIGH record
jq -r '.[] | select(.status == "active") | select(.severity == "CRITICAL" or .severity == "HIGH")
       | "\(.ave_id)  \(.aivss.aivss_score)  \(.title)"' ave-records.json

# active records mapped to one OWASP MCP Top 10 category
jq -r '.[] | select(.status == "active") | select(.owasp_mcp | index("MCP04")) | .ave_id' ave-records.json

Filter on status: a record that is deprecated, merged or rejected stays in the file, and a consumer must treat anything other than active as not active. The latest file changes with every change to records/; for anything that must be reproducible, pin a catalog release instead.

---

The API

api.aveproject.org is a read-only reference API over the published records: no authentication and no write endpoints. The interactive reference is at api.aveproject.org/docs, the source and full contract are in aveproject/ave-api, and how to use it from a tool is in the implementer guide.

Method	Path	Returns
GET	/v1/records	every record, deprecated ones included with their status
GET	/v1/records/{ave_id}	one record
GET	/v1/records/{ave_id}/mitigation	the record's vendor-neutral mitigation object only
GET	/v1/search?q=...	records whose title, description, attack class or fingerprint contain the text
GET	/v1/releases	the catalog releases, and which of them can be pinned

curl -s "https://api.aveproject.org/v1/search?q=hook" | jq -r '.[].ave_id'
curl -s "https://api.aveproject.org/v1/records/AVE-2026-00046?release=v1.2.0" | jq .schema_version

• ?release=vX.Y.Z reads a fixed catalog release instead of the latest data. Releases from v1.2.0 can be pinned.
• Every data response names its source in the AVE-Catalog, AVE-Records-SHA256 and AVE-Schema-Version headers.
• /v1 is the versioned contract. The unversioned paths are aliases with identical bodies.
• A deprecated, merged or rejected record is served with its status. Only an id that was never published is a 404.
• Limits: 60 requests a minute per IP for each path, from a single instance that scales to zero, so the first request after a quiet spell is slow. Use the API for lookups and links. A scanner that resolves ids on every finding should read a pinned release locally.

Anyone can run their own instance, and nothing about AVE depends on the hosted one staying available.

---

Independent validation

AVE's ID scheme has been tested by people who didn't build it, not just used by people who did.

Eight independent tools, cfgaudit, ClawScan, nova-proximity, Ramparts, Semia, SkillSpector (NVIDIA), skill-security-scanner, and skillsentry, none of them sharing code with AVE or with each other, built crosswalks against AVE's records on their own initiative, unprompted. In each case the comparison went beyond matching category labels: mechanism-level correspondence was checked field by field, real trigger conditions against real behavioral fingerprints, and dozens of findings converged on the identical AVE ID independently.

One of those crosswalks (Ramparts) also surfaced a real methodological lesson: two independently-drafted readings of the same still- unratified OWASP MCP Top 10 numbered their own categories differently, confirmed and documented so future crosswalks match by category meaning, not by tag number.

Separately, an external maintainer caught a real attribution error in two published AVE records, corrected the underlying process documentation, not just the two records, credited in CONTRIBUTORS.md.

89 records. 8 independent crosswalks. See crosswalks/ for the full mappings, and docs/writeups/ for full technical write-ups on individual records.

---

Stats

Total records	89
Schema version	1.3.0
AIVSS spec	v0.8
CRITICAL (>= 9.0)	1
HIGH (7.0-8.9)	20
MEDIUM (4.0-6.9)	66
LOW (< 4.0)	2
Framework: OWASP MCP Top 10	all records
Framework: MITRE ATLAS	where applicable
Framework: OWASP Agentic AI Top 10	where applicable
Framework: NIST AI RMF	where applicable

---

AIVSS Scoring

Every record is scored with OWASP AIVSS v0.8:

AIVSS = ((CVSS_Base + AARS) / 2) x ThM x Mitigation_Factor

AARS (Agentic Amplification and Reachability Score) is the sum of 10 Agentic Amplification and Risk Factors (AARF), each scored 0.0-1.0. They are stored in aivss.aarf, and aivss.aars is their sum:

#	Factor	Why it matters
1	Autonomy	Agent acts without human approval
2	Tool Use	Agent has access to external tools or APIs
3	Multi-Agent	Agent interacts with or spawns other agents
4	Non-Determinism	Behavior varies unpredictably across runs
5	Self-Modification	Can alter own instructions or memory at runtime
6	Dynamic Identity	Assumes roles or identities at runtime
7	Persistent Memory	Retains state across sessions
8	Natural Language Input	Instruction surface via natural language
9	Data Access	Reads sensitive data (files, env vars, databases)
10	External Dependencies	Loads external code, skills, or remote content

Severity bands:

Band	AIVSS	Meaning
CRITICAL	>= 9.0	Immediate exploitation, full agent compromise
HIGH	7.0-8.9	Significant data loss or privilege escalation
MEDIUM	4.0-6.9	Meaningful risk requiring review
LOW	< 4.0	Limited impact or requires chaining

ThM (Threat and Heuristic Multiplier) valid values: 0.75 (theoretical) · 0.90 (PoC exists) · 1.0 (in-the-wild)

Worked example — AVE-2026-00001 (Metamorphic Payload):

AARF factors:
  autonomy=1.0  tool_use=1.0  multi_agent=0.5  non_determinism=1.0  self_modification=1.0
  dynamic_identity=0.0  persistent_memory=0.5  natural_language_input=1.0
  data_access=0.5  external_dependencies=1.0

AARS = 1.0 + 1.0 + 0.5 + 1.0 + 1.0 + 0.0 + 0.5 + 1.0 + 0.5 + 1.0 = 7.5
CVSS_Base = 8.5   ThM = 1.0 (in-the-wild)   Mitigation_Factor = 1

AIVSS = ((8.5 + 7.5) / 2) x 1.0 x 1 = 8.0  ->  HIGH

Before you rely on a score:

• Rounding. The score is the result rounded to one decimal the way scripts/validate_records.py does it, with Python's round() on the floating-point result, so a value that looks like a tie can fall either way: 9.25 is stored as 9.2.
• Checking. scripts/validate_records.py recomputes aivss.aars from the factors and the score from the formula for every record, and requires the top-level aivss_score to match.
• Not a confidence. AIVSS says how bad a class is if it fires. How sure a scanner is that it fired is confidence, assigned per detection on the finding and never stored in a record (record versus finding).
• Scores can move, ids do not. A re-score is a correction to a record (Stability). Pin a catalog release if a score must not change under you.

The Scoring page shows the factor definitions, how the published scores are spread, and worked examples built from the records themselves.

---

Stability

What you can rely on, and where each promise is defined. They are commitments the project holds itself to; the ones a machine can check are checked in CI.

You depend on	What is promised	Defined in
An ave_id	Never renumbered, reused or deleted once published. A record found wrong keeps its id and changes status instead.	ID stability
What a record says	It can be corrected as understanding improves (description, remediation, severity, score), but the id keeps pointing at the same behavioral class. A change to severity, status or the derived verification_basis is recorded in the record's append-only revisions, and CI fails a change that leaves it out.	ID stability, CONTRIBUTING.md
A record's status	active, deprecated, merged (with merged_into) or rejected (with rejection_reason). Treat anything other than active as not active, and expect new values.	Deprecation policy
The schema	A minor version never removes or renames a field, changes its meaning, or narrows a type or enum; anything else is a major version. Each published schema/ave-record-X.Y.Z.schema.json and dist/ave-records-vX.Y.Z.json is frozen, and a test fails if one changes. Every record validates against the version it declares.	Schema versioning policy
A catalog release	A GitHub Release vX.Y.Z never changes, and carries checksums and a build provenance attestation. A patch release corrects existing records, a minor one adds records or takes a minor schema, a major one takes a major schema or changes what an id means. At most monthly unless a correction is urgent.	Catalog releases, Releases and pinning
The API	/v1 is the versioned contract and the unversioned paths stay as aliases. A pinned release (?release=) never changes.	aveproject/ave-api

What is not promised: the latest data (dist/ave-records-latest.json, or the API without ?release=) changes whenever the records do. For repeatable scans, pin a release.

---

Trust, and how to check it

AVE is young, and a standard is only worth using if you can check it. Each row says what is verified and how to verify it yourself.

You want to know	What is checked	Check it yourself
A record is well formed and scored consistently	Every pull request validates every record against the schema version it declares and recomputes its aars and score. A failure fails the check.	python scripts/validate_records.py
The class is real and sourced	The schema requires at least one reference on every record, a pull request must link the primary source, and a maintainer reviews it.	the record's references
An implementation can test itself against it	Every record has a positive fixture a conforming implementation must flag and a negative one it must not. CI fails without both.	tests/fixtures/AVE-YYYY-NNNNN_positive.md and _negative.md; python scripts/check_fixtures.py
The framework mappings are anchored	Every framework a record maps to has a framework_sources entry saying which edition the mapping was made against, or that the edition is unknown. CI fails without it.	python scripts/check_framework_sources.py --strict
A record did not change under you	A change to severity, status or the derived basis is recorded in revisions, and git keeps every version. A released copy never changes.	git log -p records/AVE-YYYY-NNNNN.json
The files you downloaded are the ones published	Each catalog release carries SHA-256 checksums and a build provenance attestation.	the commands in Releases and pinning
Others have tested it	Eight independent tools built crosswalks against the records on their own initiative.	Independent validation, crosswalks/
The repository itself is looked after	CodeQL, dependency review, secret scanning and OpenSSF Scorecard run on it.	the badges at the top

What AVE does not claim: that it lists every agentic vulnerability. Records grow with research, not with quotas, and a class with no record is a gap to report, not a clean bill of health. Nor does AVE enforce anything; an ave_id stops nothing on its own (what AVE is not).

Found a mistake, or something AVE does not cover? Open an issue: a bug report for a wrong record, a schema change proposal, or a new record submission. To send a critical or pre-disclosure finding privately, see SECURITY.md.

---