AVE is a behavioral classification standard for agentic AI components. This page explains the standard at two levels: a high-level view for partners and adopters, and a detailed view for developers and security engineers implementing the standard.
The standard at a glance
Conventional standards stop at the package: CVE identifies a flaw, OSV maps it to a version range. Agent component threats have no package and no version — the danger is behavioral. AVE assigns a stable id to each distinct behavioral vulnerability class, scores it with OWASP AIVSS v0.8, and maps it to the frameworks the field already uses. One record catches many textual variants of the same underlying attack.
If two scanners read the same record and produce divergent results, the standard has failed at its one job. The architecture below exists so any implementation agrees with any other.
The five detection layers
Every AVE record declares a detection_layer — where in the agent ecosystem the vulnerability class surfaces. This determines what kind of scanner or monitoring can detect it. Two scanners that implement the same AVE record correctly will agree on the layer; this is part of the implementer contract.
| Layer | Where evidence lives | Scanner that reaches it | Records |
|---|---|---|---|
|
content
static_detection
|
Text body of the skill file, prompt file, or MCP tool description field | bawbel scan ./skill.md |
— / |
|
server_card
static_detection
|
MCP server manifest (.well-known/mcp.json), tool schemas, parameter descriptions |
bawbel scan-server-card <url> |
— / |
|
registry_ metadata static_detection
|
Registry listing — server name, publisher, description on smithery.ai or the official MCP registry | Registry audit before install | — / |
|
runtime
runtime_observed
|
Tool results, memory writes, A2A messages, rendered UI payloads, async task results, image pixels | Behavioral sandbox or runtime monitor no static scanner reaches this |
— / |
| transport | HTTP headers, OAuth discovery endpoints, DNS responses, webhook destinations | Network proxy or monitor | — / |
Several records are at the runtime layer — RAG injection, tool result manipulation, memory poisoning, A2A injection, context flooding, vision injection, REPL code mode, and async task poisoning. A static scanner cannot catch these because the malicious payload only exists during a live session. They require either a behavioral sandbox (run the agent and observe) or runtime monitoring (proxy tool results, audit memory writes). This is the gap bawbel-scanner v1.1+ will address with runtime analysis.
How a record works
Anatomy
A record has two halves. The static definition describes the vulnerability class and never changes per scan: ave_id (immutable), attack_class, behavioral_fingerprint, severity, aivss, and the framework mappings. The evidence declarations (added in v1.1) are optional and declare the defaults a scanner uses to assign per-finding metadata.
Validation — the record/rule/fixture triangle
Every record requires a detection rule (pattern, YARA, or Semgrep) that references the ave_id, a positive fixture that must trigger it, and a negative fixture — a benign lookalike that must not. A rule without a negative fixture is an incomplete false-positive guard.
Consumption — the record declares, the scanner assigns
This is the most important rule for implementers. A record is static; a finding is a runtime instance. Confidence belongs to the finding, never the record — the same class in a docs folder and in a live skill file deserves different confidence. So the record declares a confidence_baseline and the scanner does the per-detection math.
| Record declares (static) | Scanner assigns to finding (runtime) |
|---|---|
| confidence_baseline | confidence (then FP-adjusted) |
| evidence_kind_default | evidence_kind |
| detection_stage | evidence_stage (floor) |
| evidence_basis_engines | evidence_basis |
| derivable_into | ToxicFlow.derived_from_findings |
In any finding, confidence and aivss_score are separate fields and are never merged. AIVSS answers “how bad would this be”; confidence answers “how sure are we.” Putting baselines in the standard rather than in scanner code is what keeps two implementations consistent.
Output — how AVE travels
A scanner emits findings as SARIF with the ave_id in ruleId and under taxonomies, plus aivss_score, confidence, owasp_mcp, and mitre_atlas in the properties bag. Because SARIF is already consumed by the GitHub Security tab and CI, AVE ids reach those surfaces for free. The open record set can be consumed by any tool, and crosswalks let other scanners’ finding types resolve to AVE ids.
The schema, records, rules, and fixtures are all open under Apache 2.0. Honor the declares-vs-assigns contract and the SARIF convention, and your tool’s findings will interoperate with every other AVE implementation. See the schema reference and the repository.