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
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.
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.
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
- Propose. A researcher finds an agentic behavior no record covers, with a citable primary source, and opens an issue. A new
ave_idis only for a genuinely distinct behavioral class. - Write. The record (fingerprint, indicators, remediation, AIVSS score, framework mappings) and two fixtures: one text a conforming implementation must flag, one it must not.
- Validate. CI checks the record against the schema, recomputes its score, and requires both fixtures. A maintainer reviews.
- Publish.
dist/ave-records-latest.jsonmoves, and the API follows within about 15 minutes. The next catalog release freezes a copy: tagged, checksummed and attested. - 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. - Consume. CI gates, SARIF viewers and dashboards deduplicate and report on the id, across tools.
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 |
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.jsonFilter 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.
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.Zreads a fixed catalog release instead of the latest data. Releases fromv1.2.0can be pinned.- Every data response names its source in the
AVE-Catalog,AVE-Records-SHA256andAVE-Schema-Versionheaders. /v1is the versioned contract. The unversioned paths are aliases with identical bodies.- A
deprecated,mergedorrejectedrecord is served with itsstatus. Only an id that was never published is a404. - 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.
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.
| 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 |
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.pydoes it, with Python'sround()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.pyrecomputesaivss.aarsfrom the factors and the score from the formula for every record, and requires the top-levelaivss_scoreto 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.
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.
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.
89 records, click to expand
| AVE ID | Title | AIVSS | Severity |
|---|---|---|---|
| AVE-2026-00001 | Metamorphic Payload via External Config Fetch | 8.0 | HIGH |
| AVE-2026-00002 | Tool Poisoning via Description Manipulation | 7.3 | HIGH |
| AVE-2026-00003 | Data Exfiltration via Credential Theft | 6.8 | MEDIUM |
| AVE-2026-00004 | Arbitrary Code Execution via Shell Pipe Injection | 5.9 | MEDIUM |
| AVE-2026-00005 | Destructive Command Execution | 5.6 | MEDIUM |
| AVE-2026-00006 | Cryptocurrency Drain via Wallet Access | 7.5 | HIGH |
| AVE-2026-00007 | Goal Hijacking via Prompt Injection | 6.1 | MEDIUM |
| AVE-2026-00008 | Persistence via Self-Replication | 6.3 | MEDIUM |
| AVE-2026-00009 | Jailbreak via Safety Constraint Removal | 5.5 | MEDIUM |
| AVE-2026-00010 | Hidden Instruction Concealment | 5.6 | MEDIUM |
| AVE-2026-00011 | Dynamic Tool Call with Attacker Parameters | 5.7 | MEDIUM |
| AVE-2026-00012 | Privilege Escalation via Permission Grant | 4.5 | MEDIUM |
| AVE-2026-00013 | PII Exfiltration Pattern | 6.5 | MEDIUM |
| AVE-2026-00014 | Social Engineering via Trust Escalation | 3.7 | LOW |
| AVE-2026-00015 | System Prompt Disclosure | 4.9 | MEDIUM |
| AVE-2026-00016 | Indirect Prompt Injection via RAG Retrieval | 6.4 | MEDIUM |
| AVE-2026-00017 | MCP Server Impersonation | 5.7 | MEDIUM |
| AVE-2026-00018 | Tool Result Manipulation | 4.4 | MEDIUM |
| AVE-2026-00019 | Agent Memory Poisoning | 5.6 | MEDIUM |
| AVE-2026-00020 | Cross-Agent Injection via A2A Protocol | 5.9 | MEDIUM |
| AVE-2026-00021 | Human-in-the-Loop Bypass | 4.5 | MEDIUM |
| AVE-2026-00022 | Scope Creep via Undeclared Resource Access | 6.0 | MEDIUM |
| AVE-2026-00023 | Context Window Manipulation | 5.8 | MEDIUM |
| AVE-2026-00024 | Supply Chain: Binary Content Disguised as Skill | 6.8 | MEDIUM |
| AVE-2026-00025 | Conversation History Injection | 4.5 | MEDIUM |
| AVE-2026-00026 | Tool Output Exfiltration via Encoding | 6.8 | MEDIUM |
| AVE-2026-00027 | Multi-Turn Persistence Attack | 5.6 | MEDIUM |
| AVE-2026-00028 | File Content Injection | 5.9 | MEDIUM |
| AVE-2026-00029 | Homoglyph and Unicode Obfuscation | 4.8 | MEDIUM |
| AVE-2026-00030 | False Role Claim | 4.3 | MEDIUM |
| AVE-2026-00031 | Feedback Loop Poisoning | 5.4 | MEDIUM |
| AVE-2026-00032 | Internal Network Reconnaissance | 4.0 | MEDIUM |
| AVE-2026-00033 | Unsafe Deserialization in Skill Context | 4.2 | MEDIUM |
| AVE-2026-00034 | Dynamic Skill Import at Runtime | 6.6 | MEDIUM |
| AVE-2026-00035 | Sensor and Environment Manipulation | 4.2 | MEDIUM |
| AVE-2026-00036 | Lateral Movement via Agent Pivot | 5.9 | MEDIUM |
| AVE-2026-00037 | Vision and Multimodal Injection | 5.1 | MEDIUM |
| AVE-2026-00038 | Unbounded Tool Use | 5.9 | MEDIUM |
| AVE-2026-00039 | Covert Exfiltration via Steganographic Channel | 4.9 | MEDIUM |
| AVE-2026-00040 | Insecure Output Handling | 5.4 | MEDIUM |
| AVE-2026-00041 | MCP Server-Card Injection | 8.2 | HIGH |
| AVE-2026-00042 | REPL Code Mode Credential Exposure | 4.7 | MEDIUM |
| AVE-2026-00043 | MCP App UI Injection | 4.7 | MEDIUM |
| AVE-2026-00044 | Async Task Result Poisoning | 8.1 | HIGH |
| AVE-2026-00045 | Cross-App-Access Escalation | 6.4 | MEDIUM |
| AVE-2026-00046 | MCP Tool Hook Hijacking | 9.2 | CRITICAL |
| AVE-2026-00047 | Hardcoded Credentials in Agent Component | 7.6 | HIGH |
| AVE-2026-00048 | Unsafe Agent Delegation Chain | 7.7 | HIGH |
| AVE-2026-00049 | HTTP Host Header Injection (BadHost) | 7.2 | HIGH |
| AVE-2026-00050 | Parasitic Toolchain — Silent Tool Registration | 7.2 | HIGH |
| AVE-2026-00051 | OAuth Discovery Rebinding | 7.2 | HIGH |
| AVE-2026-00052 | MCP Tool Implementation Command Injection | 7.5 | HIGH |
| AVE-2026-00053 | MCP Resource Path Traversal | 6.3 | MEDIUM |
| AVE-2026-00054 | Code-Execution Sandbox Escape | 6.7 | MEDIUM |
| AVE-2026-00055 | MCP STDIO Launch Configuration Injection | 7.7 | HIGH |
| AVE-2026-00056 | Zero-Click Exfiltration via Rendered Content Auto-Fetch | 5.8 | MEDIUM |
| AVE-2026-00057 | Obfuscated Payload — Static Scanner Evasion | 4.4 | MEDIUM |
| AVE-2026-00058 | Deceptive Trigger — Activation-Scope Manipulation | 3.1 | LOW |
| AVE-2026-00059 | Fragmented Cross-Description Reassembly (ShareLock) | 7.1 | HIGH |
| AVE-2026-00060 | STDIO Transport Shell Injection | 7.2 | HIGH |
| AVE-2026-00061 | TLS Verification Disabled in Agent Configuration | 4.1 | MEDIUM |
| AVE-2026-00062 | Unpinned Dependency Supply Chain Substitution | 4.4 | MEDIUM |
| AVE-2026-00063 | Approval Gate Bypass via Configuration | 4.8 | MEDIUM |
| AVE-2026-00064 | Zero-Click Code Execution via Auto-Run Configuration | 5.2 | MEDIUM |
| AVE-2026-00065 | A2A Agent Card Poisoning | 7.1 | HIGH |
| AVE-2026-00066 | Hallucinated Skill-Name Squatting (HalluSquatting) | 6.2 | MEDIUM |
| AVE-2026-00067 | Skill Composition Trust Transfer (SCR-TrustLift) | 5.0 | MEDIUM |
| AVE-2026-00068 | CLI Command Composition Risk (MOSAIC) | 5.1 | MEDIUM |
| AVE-2026-00069 | Multimodal Image-Hidden Instructions (SkillCamo) | 4.8 | MEDIUM |
| AVE-2026-00070 | Distributed Cross-Agent Backdoor Fragments | 6.4 | MEDIUM |
| AVE-2026-00071 | MCP Daemon Redirect (Container Posture) | 5.6 | MEDIUM |
| AVE-2026-00072 | MCP Server Bound to All Interfaces (NeighborJack) | 5.0 | MEDIUM |
| AVE-2026-00073 | Telemetry/Endpoint Redirect via Static Configuration | 4.1 | MEDIUM |
| AVE-2026-00074 | Reclaimable Dead External Anchor (SkillJacking) | 7.1 | HIGH |
| AVE-2026-00075 | Bytecode Poisoning (Compiled Cache/Source Divergence) | 4.4 | MEDIUM |
| AVE-2026-00076 | Natural-Language Steering of an Approval Classifier Subagent | 4.5 | MEDIUM |
| AVE-2026-00077 | Cross-Origin Tool and Resource Declaration in a Single MCP Server Manifest | 4.8 | MEDIUM |
| AVE-2026-00078 | Consensus Poisoning: Unverified Multi-Agent Result Acceptance | 6.4 | MEDIUM |
| AVE-2026-00079 | Plan Hijacking via False Completion Signal | 6.2 | MEDIUM |
| AVE-2026-00080 | Silent Agent Substitution (Sybil) via Unverified Retry | 6.8 | MEDIUM |
| AVE-2026-00081 | Lingering Authority: Stale Capability Survives Episode Closure | 6.1 | MEDIUM |
| AVE-2026-00082 | Local Skill Name Collision (Deterministic Router Shadowing) | 4.4 | MEDIUM |
| AVE-2026-00083 | Silent guardrail comparison failure: a protection mechanism that executes but never evaluates its verdict | 6.3 | MEDIUM |
| AVE-2026-00084 | Lifecycle hook trust decoupling: a vetted plugin update silently rebinds hooks outside the model's decision path | 7.0 | HIGH |
| AVE-2026-00085 | Collusive cross-skill composition: a malicious workflow split across independently benign skills | 7.1 | HIGH |
| AVE-2026-00086 | Mid-session WebMCP tool hijacking: a live registry swap replaces an already-discovered tool under its own name | 7.0 | HIGH |
| AVE-2026-00087 | Agentjacking: a crafted tool response visually mimics a trusted system template to hijack an agent | 7.8 | HIGH |
| AVE-2026-00088 | Sandbox side-effect trust handoff: an agent-written workspace file is run by a trusted component outside the sandbox | 6.4 | MEDIUM |
| AVE-2026-00089 | Model-supplied sandbox boundary: a tool parameter the model sets defines or widens the sandbox's writable scope | 6.6 | MEDIUM |
bawbel/scanner is the reference implementation of this standard. Detection rules are implementation artifacts, not part of AVE: they live in the tools that implement it, not in this repo.
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.mdExample 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 and schema are open. See the architecture guide and the implementer guide for the full consumption patterns including air-gapped environments.
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.
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; from v1.3.0 it carries a fourth, the SARIF taxonomy, which the
attestation covers too:
ave-records.json: every published record.ave-records.manifest.json: the release tag,schema_version,record_count, the SHA-256 ofave-records.jsonandsource_commit, the commit it was built from.ave-taxonomy.json(from v1.3.0): the SARIF taxonomy of exactly these records, stamped with the release's own version, date and download link, ready to embed in a tool's SARIF output.SHA256SUMS: checksums of the data files (three of them from v1.3.0).
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/avecheck_release_assets.py confirms the checksums, that the manifest matches the
records file, and that source_commit is the commit the tag points at. From
v1.3.0 it also regenerates ave-taxonomy.json from the records file and requires
a byte for byte match, and refuses a release without it.
From v1.3.0 on, add the taxonomy to the same steps. --repo is the repository the
release is published under, so verify a fork's release with --repo owner/name:
TAG=v1.3.0
curl -fsSLO "https://github.com/aveproject/ave/releases/download/$TAG/ave-taxonomy.json"
sha256sum -c SHA256SUMS # now covers three files
python ave-src/scripts/check_release_assets.py . --tag "$TAG" --git-dir ave-src --repo aveproject/ave
gh attestation verify ave-taxonomy.json --repo aveproject/aveThe taxonomy has stable URLs: https://github.com/aveproject/ave/releases/download/vX.Y.Z/ave-taxonomy.json
for a release, and https://github.com/aveproject/ave/releases/latest/download/ave-taxonomy.json
for the newest.
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).
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 · evidence_vantage ·
evidence_method · verification_basis · security_boundary ·
missing_control · vulnerability_rationale · framework_sources ·
revisions · merged_into · rejection_reason
verification_basis is derived, never authored (scripts/write_verification_basis.py).
revisions is an append-only history of changes to a record's severity, status or
derived basis (CONTRIBUTING.md).
merged_into and rejection_reason apply only to the merged and rejected statuses.
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
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.
Open a New AVE Record issue before writing any JSON. Include:
- The proposed
attack_classand one-sentencebehavioral_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.
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');
"Add two files in this repo; scripts/check_fixtures.py fails the PR without them:
tests/fixtures/AVE-2026-NNNNN_positive.md # a conforming implementation MUST flag this
tests/fixtures/AVE-2026-NNNNN_negative.md # a conforming implementation MUST NOT flag this
Detection rules (YARA, Semgrep, patterns) are implementation artifacts and live in the tool that implements them, such as bawbel/scanner. A coordinated PR there is encouraged, but this repo's PR does not wait for it. See CONTRIBUTING.md, Step 4.
Target develop, not main. 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_compromiseentry a defender can actually search for - Link to the primary source
- A link to the coordinated PR in the implementing tool's repo, if one exists
AVE records carry four framework fields. Crosswalk files map AVE onto further frameworks and vocabularies, and other tools' categories onto AVE. 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 |
| MAESTRO (Cloud Security Alliance), a pilot | no dedicated schema field | crosswalks/ave-to-maestro.json |
| OWASP AI Exchange, a pilot | no dedicated schema field | crosswalks/ave-to-owasp-ai-exchange.json |
| agent-evidence-vocabulary, field by field | the evidence fields (evidence_vantage, evidence_method, ...) |
crosswalks/ave-to-agent-evidence-vocabulary.json |
| This scanner | Maps to AVE via |
|---|---|
| cfgaudit | crosswalks/cfgaudit-to-ave.json |
| ClawScan (OpenClaw) | crosswalks/clawscan-to-ave.json |
| nova-proximity (Nova-Hunting) | crosswalks/nova-proximity-to-ave.json |
| Ramparts (Highflame Inc.) | crosswalks/ramparts-to-ave.json |
| Semia (RiemaLabs) | crosswalks/semia-to-ave.json |
| SkillSpector (NVIDIA) | crosswalks/skillspector-to-ave.json |
| skill-security-scanner (honysyang) | crosswalks/skill-security-scanner-to-ave.json |
| skillsentry (vythanhtra) | crosswalks/skillsentry-to-ave.json |
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.
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.
| aveproject.org | Public registry and documentation |
| bawbel/scanner | Reference implementation |
| aveproject/ave-site | Website source |
| api.aveproject.org | Reference API: lookup by AVE ID, search, pinned releases (API section, implementer guide) |
| OWASP AIVSS v0.8 | Scoring specification |
| MITRE ATLAS | AI threat technique catalog |
| OWASP MCP Top 10 | MCP attack surface framework |
AVE records and schema are published under Apache 2.0.