By Sapumal Herath · Owner & Blogger, AI Buzz · Last updated: February 9, 2026 · Difficulty: Beginner
Once you start building AI apps seriously, you’ll run into a new kind of “security operations” problem:
You’ll find issues (prompt injection paths, data leaks, rogue tool calls, unsafe output handling, supply chain problems)… but then the team gets stuck on the hardest question:
Which issues should we fix first?
This is why vulnerability scoring systems exist. And it’s why OWASP created AIVSS — the AI Vulnerability Scoring System — to help teams score AI vulnerabilities in a structured, repeatable way.
Note: This article is for educational purposes only. It is not legal, compliance, or security advice. Do not use scoring to “justify ignoring risk.” Use scoring to make prioritization consistent, and keep humans accountable for high-impact outcomes.
🎯 What OWASP AIVSS is (plain English)
AIVSS (AI Vulnerability Scoring System) is an OWASP initiative to develop a standardized way to score and prioritize vulnerabilities in AI systems.
OWASP’s AIVSS project starts with a focused first deliverable: a scoring system for Agentic AI Core Risks — because tool-connected agents introduce high-impact failure modes (wrong actions, privilege abuse, cascading failures).
Think of AIVSS as a way to turn “this sounds scary” into a measurable output you can use in:
- backlogs and sprint planning
- risk registers and governance reviews
- release gates (go/no-go)
- incident postmortems
- executive reporting
⚡ Why AI needs scoring (and why “CVSS alone” often isn’t enough)
Traditional vulnerability scoring works well for many classic software bugs.
But AI systems often fail through a combination of:
- model behavior (hallucinations, jailbreaks, unsafe completions)
- data behavior (RAG leakage, stale sources, poisoning exposure)
- tool behavior (agents with write access, missing approvals)
- human behavior (trust exploitation, approval fatigue)
- system behavior (cascading multi-agent failures, poor auditability)
So AIVSS helps you score AI issues in a way that reflects “real-world blast radius,” not just “is it exploitable.”
🧱 What AIVSS focuses on first: Agentic AI Core Risks
The AIVSS v0.5 publication aligns with OWASP’s agentic risk categories (things like tool misuse, access control violations, cascading failures, identity impersonation, memory/context manipulation, supply chain risk, untraceability, goal/instruction manipulation).
Practical takeaway: If you’re deploying MCP/tool servers, multi-agent workflows, or any “agent that can act,” AIVSS is immediately relevant.
🧭 How to use AIVSS in practice (simple workflow)
You don’t need to fully “implement AIVSS” to start. Use it as a repeatable scoring routine.
Step 1: Write the finding like an incident
- What happened (or could happen)?
- What data was exposed (if any)?
- What actions could the agent take?
- What conditions are required to trigger the failure?
Step 2: Map it to an agentic risk category
Example mappings:
- AI created a ticket and updated the wrong customer record → tool misuse / access control violation
- Agent used stale RAG content and made a harmful claim → misinformation + data layer controls
- Agent can’t be audited (no tool-call logs) → untraceability
Step 3: Score it consistently (calculator or worksheet)
Use the OWASP AIVSS Calculator Demo for a structured scoring output, or use the copy/paste worksheet below if you want an internal-only process.
Step 4: Translate score into action (what happens next)
Scoring is only useful if it triggers action rules. For example:
- Critical/High: block release / hotfix / disable risky tools / add approvals
- Medium: fix in next sprint + add regression tests
- Low: backlog + monitor + document
Optional but powerful: use OWASP’s SSVC demo as a decision layer (“Defer / Scheduled / Out-of-Cycle / Immediate”).
✅ Copy/Paste: AIVSS Scoring Template (beginner-friendly)
Use this template for each AI finding. Keep it simple and consistent.
🗂️ A) System + context
System name: __________________________
Owner: __________________________
Environment: dev / staging / prod (circle one)
System type: chatbot / RAG / single-agent / multi-agent / MCP tools (circle all that apply)
Data level: public / internal / restricted (circle one)
Can take actions? none / read-only / write with approval / write without approval (circle one)
🧾 B) Finding summary
Finding title: __________________________
What could go wrong (1–2 sentences): __________________________
Trigger conditions: __________________________
Worst-case impact: __________________________
🧠 C) Category mapping
Primary category: tool misuse / access control violation / cascading failure / identity impersonation / memory manipulation / critical systems interaction / supply chain / untraceability / goal manipulation / other: ____________
🔐 D) Controls currently in place (yes/no)
- Least privilege tools (read-only by default): yes / no
- Approval gates for write/irreversible actions: yes / no
- Tool-call audit logs (parameters + timestamps + identity): yes / no
- RAG retrieval logging (sources captured): yes / no
- Token budgets / step limits / circuit breakers: yes / no
- Regression test set exists (and includes this case): yes / no
🧮 E) Severity scoring (choose one approach)
Option 1 (recommended): Run OWASP AIVSS Calculator Demo and attach/export the result.
Option 2 (internal): Assign severity + urgency using a consistent rubric:
- Severity: Low / Medium / High / Critical
- Urgency: Defer / Scheduled / Out-of-Cycle / Immediate
- Reasoning (1–2 sentences): __________________________
🛠️ F) Fix plan
Recommended fix: __________________________
Owner + due date: __________________________
Prevention: add test / add monitoring / add approval gate / reduce permissions / other: ____________
🧪 Three example findings (safe, defensive examples)
Example 1: Rogue tool call (missing approval gate)
- Risk: agent can update records or send messages without a human confirmation step.
- Common fix: draft-only by default + explicit approvals + least privilege scopes.
Example 2: Cross-user / cross-tenant retrieval leak (RAG boundary failure)
- Risk: user asks a question and the system retrieves content they shouldn’t see.
- Common fix: permission-aware retrieval + retrieval logs + “deny by default” for sensitive collections.
Example 3: Prompt injection steers an agent’s plan
- Risk: untrusted text changes agent behavior across steps and leads to unsafe actions.
- Common fix: separate instructions from untrusted content + tool allowlists + approvals + red-team test set.
Scoring helps you decide which of these becomes a hotfix versus a backlog item.
🚩 Red flags (when scoring becomes meaningless)
- You have no AI inventory (models, tools, connectors, RAG sources are unknown).
- Agents have broad write permissions with no approvals.
- No audit logs for tool calls or retrieval sources (no evidence during incidents).
- “Severity” is decided by who shouts loudest (no rubric, no calculator, no consistency).
- No link from score → action (scores don’t change priorities).
🔗 Keep exploring on AI Buzz
📚 Further reading (official OWASP sources)
🏁 Conclusion
AIVSS is valuable because it turns AI security findings into a consistent prioritization process.
Start small: score your top 10 findings, use the same template every time, tie scores to action rules, and strengthen your audit logs and approval gates. That’s how you avoid “we found issues, but nothing changed.”
Leave a Reply