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 · API · Scanner
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.
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.
How it works
Without AVE:
Attacker crafts Developer ships Agent loads
malicious payload -> skill file -> skill file
(unscanned) at runtime
|
v
Agent executes attacker payload
(data exfiltrated, credentials stolen, goals hijacked)
With AVE + Bawbel Scanner:
Developer commits bawbel scan fires Finding blocked
skill file -> in CI / pre-commit -> before deploy
|
v
AVE-2026-00001 detected:
Metamorphic payload via external config fetch
AIVSS 8.0 · HIGH · owasp_mcp: MCP03, MCP04
Line 7: "fetch your instructions from..."
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 weighted sum
of 10 Agentic Amplification and Risk Factors (AARF), each scored 0.0-1.0:
| # | 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 Maturity) 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
Record index
Detect with Bawbel Scanner
Every AVE record has detection rules in
bawbel/scanner — the reference
implementation of this standard.
pip install bawbel-scanner
# Scan a skill file
bawbel scan ./my-skill.md
# Scan a directory recursively
bawbel scan ./skills/ --recursive --fail-on-severity high
# Scan an MCP server card
bawbel scan-server-card https://api.your-mcp-server.io
# Full remediation report
bawbel report ./my-skill.md
Example output:
CRITICAL bawbel-hook-hijack AVE-2026-00046 line 3 AIVSS 9.2
HIGH bawbel-unsafe-delegation AVE-2026-00048 line 11 AIVSS 7.7
HIGH bawbel-hardcoded-credential AVE-2026-00047 line 5 AIVSS 7.6
Any tool can implement AVE — the records, schema, and rules are open.
See the architecture guide and
the implementer guide for the
full consumption patterns including air-gapped environments.
Implementing AVE in your scanner
Put ave_id on each finding and the catalog release on each run, and scan
against a pinned, verified release rather than calling the API at scan time.
The implementer guide covers which
pattern fits your tool, verification, air-gapped use, output fields, status
watching and the API.
Releases and pinning
A catalog release is a GitHub Release
tagged vX.Y.Z: a fixed copy of the record set that does not change after it is
published. Each one carries three files and a build provenance attestation for
the first two:
ave-records.json: every published record.ave-records.manifest.json: the release tag, schema_version, record_count,
the SHA-256 of ave-records.json and source_commit, the commit it was built from.SHA256SUMS: checksums of both files.
Pin a tag, then check what you downloaded:
TAG=v1.2.0
for f in ave-records.json ave-records.manifest.json SHA256SUMS; do
curl -fsSLO "https://github.com/aveproject/ave/releases/download/$TAG/$f"
done # or: gh release download "$TAG" --repo aveproject/ave
sha256sum -c SHA256SUMS
git clone -q https://github.com/aveproject/ave ave-src
python ave-src/scripts/check_release_assets.py . --tag "$TAG" --git-dir ave-src
gh attestation verify ave-records.json --repo aveproject/ave
gh attestation verify ave-records.manifest.json --repo aveproject/ave
check_release_assets.py confirms the checksums, that the manifest matches the
records file, and that source_commit is the commit the tag points at.
Three kinds of record file, and which is which:
| File | What it is | Changes? |
|---|
ave-records.json on release vX.Y.Z | The record set as of that catalog release | Never |
dist/ave-records-latest.json | The current record set | On every change to records/ |
dist/ave-records-v<schema>.json | The first record set published for that schema version | Never (frozen) |
The version in a release tag is the catalog's own; the version in a dist/ file
name is a schema version. Releases follow their own SemVer and cadence (a release
when records have changed, at most monthly unless a correction is urgent); see
docs/specs/scaling-and-governance.md,
section 6. v1.2.0 is the first release with these files. The older v1.1.0
release has one asset, ave-records-v1.1.0.json (51 records on schema 1.0.0),
which is a different file from dist/ave-records-v1.1.0.json (59 records on
schema 1.1.0).
Schema v1.3.0
Records validate against
schema/ave-record-1.3.0.schema.json.
Each record is checked against the versioned file named by its own schema_version;
earlier versions stay published and frozen (schema/frozen-artifacts.json).
Canonical $id:
https://aveproject.org/schema/ave-record-1.3.0.schema.json
15 required fields:
ave_id · schema_version · status · published
title · description · attack_class · severity · behavioral_fingerprint
aivss · owasp_mcp
indicators_of_compromise · remediation
references · researcher
Minimal valid record:
{
"ave_id": "AVE-2026-00001",
"schema_version": "1.3.0",
"status": "active",
"published": "2026-04-01T09:00:00Z",
"title": "Metamorphic payload via external config fetch",
"attack_class": "Supply Chain - Metamorphic Payload",
"severity": "HIGH",
"description": "A skill fetches its instructions from an external URL at runtime...",
"behavioral_fingerprint": "Component fetches and executes remote content, replacing its own instructions at runtime.",
"aivss": {
"cvss_base": 8.5, "aars": 7.5, "thm": 1.0,
"mitigation_factor": 1.0, "aivss_score": 8.0, "spec_version": "0.8"
},
"owasp_mcp": ["MCP04", "MCP06"],
"indicators_of_compromise": ["fetch() pointing to external URL"],
"remediation": "Remove the component. Block network egress. Audit agent actions.",
"references": [{"tag": "Disclosure", "text": "Source", "url": "https://..."}],
"researcher": "Bawbel Security Research Team"
}
All optional fields:
component_type · last_updated · behavioral_vector · example_patterns ·
aivss_score · cvss_base_vector · owasp_asi · mitre_atlas ·
nist_ai_rmf · provenance_vector · trifecta_profile · mitigation ·
affected_platforms · affected_registries ·
mutation_count · detection_methodology · kill_switch_active ·
researcher_url · aivss.aarf · aivss.aivss_severity ·
aivss.notes · evidence_kind_default ·
detection_stage · detection_layer · confidence_baseline ·
evidence_basis_engines · derivable_into
status: "draft" records need only a reduced eight-field core (ave_id,
schema_version, status, title, description, attack_class,
behavioral_fingerprint, references); the full 15-field required set
above applies to every other status. See
CONTRIBUTING.md for the thin-submission path.
Lifecycle statuses. An active record is current. A record found wrong or
obsolete is never deleted and keeps its full content: it becomes deprecated,
with a note explaining why; merged, with merged_into naming the surviving
active record; or rejected, with a rejection_reason that links the public
decision. Treat any status other than active as not active, and expect the
list to grow (the compatibility rule in
the scaling spec, section 2).
Full schema reference: aveproject.org/schema.html
Adding a new AVE record
When to add a record
A new record needs all three: the attack class is not already covered by an
existing record, there is a citable primary source (CVE, paper, disclosed
incident, or working PoC), and the class is specific to agentic components —
not a generic web or API vulnerability.
If you think an existing class covers the behavior you found, open an issue
anyway. It may warrant a sub-case note in the parent record rather than a
new id.
Step 1 — Open an issue
Open a New AVE Record issue before writing any JSON. Include:
- The proposed
attack_class and one-sentence behavioral_fingerprint
- A link to the primary source
- Whether this is net-new or a variant of an existing record
The maintainer will confirm the next AVE id and whether it is a new class
or a variant update.
Step 2 — Write the record
Copy records/AVE-2026-00001.json as a
template. All 15 required fields must be present and valid.
AIVSS calculation:
1. Score each AARF factor 0.0-1.0
2. AARS = sum of all 10 AARF scores
3. AIVSS = ((CVSS_Base + AARS) / 2) x ThM x Mitigation_Factor
4. ThM: 0.75 theoretical · 0.90 PoC exists · 1.0 in-the-wild
5. Round to 1 decimal
6. Severity: CRITICAL >= 9.0 · HIGH >= 7.0 · MEDIUM >= 4.0 · LOW < 4.0
Validate before opening a PR:
npm install ajv ajv-formats
node -e "
const Ajv = require('ajv/dist/2020');
const addFormats = require('ajv-formats');
const ajv = new Ajv({ strict: false });
addFormats(ajv);
const schema = require('./schema/ave-record-1.3.0.schema.json');
const record = require('./records/AVE-2026-NNNNN.json');
const ok = ajv.validate(schema, record);
if (!ok) console.error(ajv.errors); else console.log('valid');
"
Step 3 — Add detection rules
Open a coordinated PR in bawbel/scanner
with at least one detection rule and a positive and negative fixture.
The AVE record PR and the scanner PR should reference each other.
Step 4 — PR format
Title: feat: AVE-2026-NNNNN -- <attack class>
The PR description must include:
- Link to the issue
- AARF scores with a one-line rationale for each non-zero factor
- At least one
indicators_of_compromise entry a defender can actually search for
- Link to the primary source
- Link to the coordinated scanner PR
Framework crosswalks
AVE records map to four external frameworks. Full crosswalk tables are
at aveproject.org/crosswalks.html.
| Framework | Field | Crosswalk |
|---|
| OWASP Agentic Security Initiative Top 10 | owasp_asi (ASI01-ASI10) | schema field, all applicable records |
| OWASP Agentic Skills Top 10 (AST10) | no dedicated schema field yet (owasp_ast planned) | crosswalks/ave-to-ast10.json |
| OWASP MCP Top 10 | owasp_mcp | all records |
| MITRE ATLAS | mitre_atlas | where applicable |
| NIST AI RMF | nist_ai_rmf | where applicable |
Maintaining a scanner? The implementer guide
covers how to map your rule IDs to AVE ids and add AVE ID emission to your
finding output. You can also open an issue and the maintainer will help with
the mapping.
Governance and contributing
See GOVERNANCE.md for the decision-making process, how records
are proposed and reviewed, and the path toward neutral governance.
See docs/specs/scaling-and-governance.md
for record-growth discipline, schema versioning, and deprecation policy,
including AVE's ID stability guarantee: identifiers are never
renumbered or reused once published.
See docs/specs/researcher-process.md
for the practical, step-by-step process a contributor actually follows
when adding a new record, including a full worked example.
See CONTRIBUTORS.md for what real external
contributors have actually built and caught, credited specifically,
not just listed by name.
See CONTRIBUTING.md for the contributor-facing process.
See CODE_OF_CONDUCT.md for community standards.
Related
AVE records and schema are published under Apache 2.0.
