AIVSS
AI Vulnerability Scoring System

The AI Vulnerability Scoring System (AIVSS) is an OWASP project that gives security teams a standardised, vendor-neutral way to score vulnerabilities specific to AI systems — prompt-injection, training-data poisoning, multi-agent governance gaps, time-to-enforce, model-supply-chain integrity. It is the AI counterpart to CVSS.

Unlike CVSS, AIVSS has to account for risks that don't exist in traditional software: a vulnerability in a base model propagates to every fine-tune; a prompt-injection becomes a privilege escalation; an agent's autonomy means the time between detection and enforcement is itself a scorable dimension.

The OWASP project page is at github.com/OWASP/www-project-artificial-intelligence-vulnerability-scoring-system.

aiegis authored the audit-pack-signing v0.5 race-test fixture for the AIVSS enforcement-effectiveness dimension. The fixture was merged into the OWASP working text on 2026-05-09. It is not a vendor claim — it is a public GitHub artifact with a deterministic SHA-256.

Verify the cite yourself:

aiegis participates in two open AIVSS working-group threads at the canonical OWASP project repo:

Both issues are public. Read, comment, or submit fixtures of your own.

The enforcement-effectiveness dimension of AIVSS rewards architectures that emit signed, layer-attributed decisions with a measurable time-to-enforce. aiegis' /api/protect endpoint maps directly to that contract:

Decisions persist to an append-only ledger with a 5-year retention floor (SQL-enforced via BEFORE DELETE / BEFORE UPDATE triggers; verify at /grid/ledger/retention). That ledger is the AIVSS evidence chain.

Talk to us about AIVSS scoring

AIVSS scores an AI vulnerability across dimensions that traditional CVSS does not capture. Each dimension is a sub-score; the composite is the AIVSS base score. The dimensions below reflect the working text as of the 2026-05-15 review cadence at the OWASP project repository — aiegis' contribution sits inside the enforcement-effectiveness dimension specifically.

• Prompt-injection susceptibility. Scores how easily an adversary can manipulate the model's output by crafting input that overrides system instructions. A model that follows a freshly-typed "ignore previous instructions" verbatim scores high; a model gated by a guard-layer with system-prompt isolation scores low. This is the dimension closest to a classical injection vulnerability.
• Training-data poisoning impact. Scores the blast radius when a contaminated record reaches the training corpus. The dimension accounts for base-model propagation: a poisoned record in a foundation model's pre-training set propagates into every downstream fine-tune, every retrieval-augmented agent, every distilled smaller model. CVSS has no analogue.
• Multi-agent governance gaps. Scores the risk created when agent A delegates a task to agent B and a vulnerability surfaces in the chain. AIVSS Issue #32 (Multi-Agent Governance Gaps) is the working thread for this dimension. The cross-agent attribution question — which agent caused the harm? — is itself a scorable property.
• Enforcement-effectiveness (time-to-enforce). Scores the gap between a detected violation and a blocked action. A platform that detects but does not block scores worst; a platform that blocks in single-digit milliseconds with a signed receipt scores best. aiegis' audit-pack-signing v0.5 race-test fixture exercises this dimension and is byte-for-byte cited in the OWASP working text.
• Model-supply-chain integrity. Scores how verifiable the provenance chain of the model is — whether weights are signed, whether the training-data manifest is published, whether the fine-tune lineage is reproducible from a deterministic seed. This dimension is the AI counterpart to SLSA for software supply chains.

The composite AIVSS score is then modified by environmental and temporal metrics — deployment context, agent autonomy level, exploit maturity — familiar in shape to CVSS users but recomputed for the AI risk geometry.

CVSS v4.0 is the canonical scoring system for traditional software vulnerabilities. It works because traditional software has well-defined privilege boundaries, deterministic state transitions, and a clear notion of "exploit". None of those primitives map cleanly to a non-deterministic, autonomy-bearing AI agent. AIVSS exists to fill the gap, not to replace CVSS.

• Attack vector. CVSS distinguishes network, adjacent, local, physical. AIVSS adds prompt and delegation — an attack that crosses agents through a delegation chain is a new vector class with no CVSS analogue.
• Privileges required. CVSS asks whether the attacker needs an account. AIVSS asks whether the attacker needs to be in-context — that is, whether the attack works only when the adversary's content reaches the model's input window. Many prompt-injection attacks require zero credentials but full in-context access via retrieval.
• Impact: confidentiality, integrity, availability. CVSS scores CIA on the targeted system. AIVSS scores CIA on the model behaviour — integrity of refusal, confidentiality of system prompts, availability of the guard layer — which is a different unit of measurement.
• Autonomy modifier. CVSS does not score how much agency the affected system has. AIVSS does — a vulnerability in an agent that can call tools, spend money, or send email scores far higher than the same vulnerability in a passive chat-completion endpoint.
• Time-to-enforce. CVSS treats detection and remediation as outside-of-score concepts. AIVSS treats time-to-enforce as a first-class scoring dimension because, for an autonomous agent, the gap between "detected" and "blocked" is the gap during which real-world harm can compound.

Procurement teams should expect to see both scores on a future AI-system vulnerability disclosure: a CVSS base-score for the surrounding software stack, and an AIVSS base-score for the AI-specific dimensions. The two are complementary, not competing.

Every decision emitted by aiegis' /api/protect endpoint carries a structured reason code. The reason-code namespace is engineered to map directly onto the AIVSS scoring dimensions so that an auditor can read a single decision row and locate the corresponding AIVSS sub-score without translation.

• L01_* identity & authentication failures. Mapped to the privileges-required input of the AIVSS attack-vector dimension. Includes missing passport, expired Ed25519 signature, revoked agent ID.
• L04_PROMPT_* prompt-class refusals. Mapped to the prompt-injection-susceptibility dimension. The suffix names the injection class detected (jailbreak, system-prompt-override, context-overflow, indirect-via-retrieval).
• L07_DELEGATION_* delegation-chain refusals. Mapped to the multi-agent governance gaps dimension. Carries the delegation depth and the upstream agent's policy version.
• L11_RATE_* rate-class refusals. Mapped to the availability-impact metric. Distinguishes per-agent, per-tenant, per-tool quotas.
• L15_AUDIT_* audit-trail failures. Mapped to the enforcement-effectiveness dimension. A decision that cannot be persisted to the append-only ledger fails closed and surfaces as an L15_AUDIT_FAIL_CLOSED reason code.

This taxonomy is published, not proprietary. Reason codes are stable across versions; new codes are added in working-group review with backward-compatible prefixes. The full reason-code reference is available at /developer for integrators.

The audit-pack-signing v0.5 race-test fixture is not a paper deliverable. It is an executable adversarial test that any implementor of the AIVSS enforcement-effectiveness dimension can run against their own platform to produce a comparable score. The fixture sits at race-test-fixtures/audit-pack-signing-v0.5/ in github.com/aeoess/aivss-enforcement-effectiveness.

What the fixture exercises. The fixture spawns N concurrent agents each emitting a stream of decisions that must be signed, sequenced, and persisted to an append-only ledger with no missed indices, no out-of-order sequence numbers, and no signature gaps under load. The test passes only when every decision row carries a verifiable signature chained to its predecessor.

Why the race-test framing matters. Many enforcement layers look correct at single-agent throughput and degrade silently under concurrency — a missed sequence, a duplicated row, a signed-but-unanchored decision. The race-test fixture is engineered to force that failure into the open, with deterministic seeds, reproducible across implementations.

Sub-paragraph-of-spec ownership. Inside the OWASP AIVSS working text, aiegis' specific authorship sits at the enforcement-effectiveness sub-paragraph that defines the contract the fixture exercises. The author attribution is in the merge commit; the fixture's spec.md is the byte-for-byte primary reference. Ownership is recorded, not implied.

To produce an enforcement-effectiveness sub-score that survives external review, the methodology must be reproducible by an auditor who has only the published fixture and the platform under test. The AIVSS race-test fixture defines that path.

• Step 1 — pin the fixture. Clone the repository at the merge commit, verify the spec.md sha-256 byte-for-byte, lock the fixture version in the test plan.
• Step 2 — configure the platform under test. The platform must expose a decision endpoint that accepts agent actions and returns signed, layer-attributed decisions with a measurable enforcement latency. aiegis exposes that at POST /api/protect.
• Step 3 — run the race harness. Spawn the concurrency profile defined in the fixture spec. Capture every returned decision into the candidate audit ledger. Run for the duration declared in the fixture (decision count, not wall-clock, is the unit).
• Step 4 — verify the ledger. Walk the ledger sequence end-to-end. Every row's signature must chain to its predecessor; every sequence number must be monotonic; no row may be missing, duplicated, or unsigned.
• Step 5 — compute the sub-score. Derive enforcement-effectiveness from the median decision_ms, the 99th-percentile decision_ms, and the fail-closed integrity of the ledger walk. The sub-score feeds the composite AIVSS base score.

The methodology is deliberately strict on the ledger walk: a single broken signature chain collapses the enforcement-effectiveness sub-score to zero, regardless of latency. The reasoning is that an audit chain that does not verify is not, in the AIVSS framing, an enforcement chain at all — it is a logging chain, and logging without integrity is not enforcement.

For a CISO or procurement lead evaluating an AI platform, AIVSS does three concrete things that CVSS alone cannot.

• It gives you a vendor-comparable AI risk number. Two AI platforms with similar feature sets can carry very different AIVSS profiles. The score makes the difference visible at procurement, not at incident.
• It demands evidence, not assertion. Vendors who claim "we have guardrails" can be asked: what is your AIVSS enforcement-effectiveness sub-score against the audit-pack-signing v0.5 fixture? A vendor that cannot answer the question has not engaged with the methodology.
• It aligns the security conversation with the regulatory geometry. EU AI Act Articles 9, 12, 15, and 26 each have measurable counterparts inside the AIVSS scoring dimensions. A platform that scores well on AIVSS is, by construction, easier to evidence under the Act.

For aiegis specifically: our authorship of the race-test fixture means the platform we ship is, by definition, the reference implementation against which other platforms compute their enforcement-effectiveness sub-score. That is not a marketing claim — it is a public artifact, with a verifiable SHA, hosted on a public OWASP-adjacent repository.

AIVSS adoption in 2026 looks similar in shape to CVSS adoption in the mid-2000s — first the maintainers of the scoring system itself, then a small set of security-vendor reference implementations, then the regulated-industry CISOs who need a number to put on a procurement spreadsheet. aiegis sits squarely in the second tier: a reference implementation whose authorship inside the working group is recorded, not asserted, and whose enforcement-effectiveness sub-score can be reproduced by anyone with the public fixture.

What to watch for next. The AIVSS working group is moving toward a v0.6 release of the audit-pack-signing fixture, with extended adversarial cases for delegation-chain integrity. Public comment on AIVSS Issues #31 and #32 is the canonical surface; the working text is the canonical artifact. aiegis' role is to keep the fixture executable, the SHA verifiable, and the implementation runnable end-to-end — not to define what the score ultimately should mean. That definition belongs to the open OWASP process.

If you are evaluating AI vendors and want to ask the AIVSS questions properly — what is your enforcement-effectiveness sub-score, what fixture version did you run against, what is the median and 99th-percentile decision_ms, can you produce a signed ledger walk — the conversation begins by pointing at the public artifact. The public artifact is the floor of the conversation; everything above it is vendor evidence.