Executive Summary
Vulnerability management ranks findings by how bad the flaw is and how likely it is to be exploited. For software that only answers requests, that works. An AI agent changes the result, because the same flaw does very different damage depending on the agent behind it. A prompt injection in a read-only assistant leaks an answer. The same injection in an agent that can approve payments, call a database tool, act without review and remember what it was told yesterday can move money and keep doing it. Agent-aware vulnerability management keeps traditional exploitability as the floor and adds five things the score leaves out: the agent’s autonomy, its permissions, the tools it can call, how long its memory persists, and the business impact of the process it runs. OWASP’s AI Vulnerability Scoring System (AIVSS) already turns most of these into an uplift on top of CVSS. ISO/IEC 27090:2026, published by ISO and IEC in October 2026, is a new international standard on security threats to AI systems. It describes how AI vulnerabilities are exploited and what they lead to; it leaves the ranking to the organisation. The two fit together: 27090 for the threats, an agent profile for the ranking.
10
agent factors OWASP AIVSS v0.8 adds on top of a CVSS v4.0 base score, including autonomy, tools, identity and persistent memory
4.3 to 7.9
the same Medium finding rescored for an autonomous finance agent under the AIVSS formula, in our illustrative case
56
pages in ISO/IEC 27090:2026, guidance on understanding, detecting and mitigating threats to AI systems across their life cycle
One third
the most that strong, validated mitigations can take off an AIVSS score; the framework sets the floor at 0.67
Core conclusions
- A CVSS score describes a flaw in a component. For an agent, the damage depends on what the agent can do with it, so the same finding needs a different priority in different agents.
- Rank agent findings on six inputs: exploitability, autonomy, permissions, tools, memory persistence and business impact. The last five belong in the AI system register, kept current by the agent’s owner, so the security team can score against them.
- ISO/IEC 27090 supplies the threat catalogue and the life cycle view. It does not rank. Use it to decide what to look for, and an agent profile to decide what to fix first. Often the fastest fix is to cut the agent’s reach, because many agent flaws have no patch.
The argument, in ten slides
Save it, or send it to whoever runs vulnerability management for your AI systems.
Most vulnerability programmes run on the same loop. A scanner or a tester finds a flaw, the flaw gets a CVSS score, the score sets a fix deadline, and the team that owns the system works the queue. Better programmes add a view of the threat: whether the flaw is on CISA’s Known Exploited Vulnerabilities list, and what FIRST’s EPSS model puts as the chance of exploitation in the next 30 days. Boards see the result as a count of open Criticals and Highs, and an ageing chart.
That loop assumes the score describes the risk. For an ordinary application it comes close, because the application does what its code says, and the damage a flaw can do is set by the application’s permissions. An AI agent breaks that assumption. It decides what to do, it carries credentials, it calls tools, and some agents remember. The same flaw in two agents can lead to a wrong answer in one and a wire transfer in the other, and the CVSS score is identical in both.
Maria and I wrote earlier this month about how agents join low-rated findings into one attack path. This post is the other half of that argument: how to rank a single finding once you know which agent it sits in. It also looks at ISO/IEC 27090, the new international standard on threats to AI systems, and where it fits.
What a vulnerability score measures
CVSS v4.0, the current version of the Common Vulnerability Scoring System from FIRST, rates a flaw on how it is exploited (attack vector, complexity, privileges and user interaction needed) and what it does to the system it sits in and to systems beyond it. Version 4.0 split impact into two sets for this reason: impact on the vulnerable system, and impact on subsequent systems. That second set is the closest CVSS comes to describing an agent, because an agent is often the route from one system to another.
The base score still describes the flaw. It is meant to be the same wherever the component is deployed. Environmental metrics exist to adjust for a particular deployment, but many programmes leave them blank, and none of them ask whether the component acts on its own, which tools it holds or whether it remembers.
EPSS and KEV answer a different question: whether attackers are using the flaw. They help sort a queue of thousands of CVEs. Many agent flaws never receive a CVE at all. A prompt injection path through a particular agent’s email connector is a property of that deployment, found by a red team or a tester, and it has no entry in any exploit database.
Why the same flaw matters more in an agent
OWASP’s AI Vulnerability Scoring System, a project led by Ken Huang, Michael Bargury and Vineeth Sai Narajala, states the principle plainly. In version 0.8 its authors write that in ordinary software a vulnerability has a fixed impact ceiling set by the application’s permissions, while in an agent the ability to plan, use tools and persist memory “acts as a Force Multiplier for technical flaws.” Their example is a SQL injection: dangerous in a passive reporting tool, and catastrophic in an agent that can read the database, interpret the results and email them out on its own.
We see three reasons for the multiplier in the agents we review.
The agent chains steps for the attacker. An attacker who controls what the agent reads does not need to write an exploit for each system. The agent plans and carries out the next steps with its own access.
The agent crosses system boundaries. Instructions arrive as natural language in an email, a document or a tool description, and leave as an API call to a different system. A flaw in one place becomes an action somewhere else.
The damage can persist. If the agent writes what it was told into long-term memory, a single injection keeps shaping its behaviour in later sessions, for other users, after the original email has been deleted.
None of this changes the CVSS score of the underlying flaw. All of it changes how fast it needs fixing.
The six inputs to an agent-aware priority
Agent-aware vulnerability management keeps traditional exploitability as the starting point and adds five properties of the agent. We use the six below. The first comes from the finding; the other five come from the agent, and should be on record before any finding arrives.
| Input | Question it answers | Where the answer comes from | Low | High |
|---|---|---|---|---|
| 1. Exploitability | How easy is the flaw to use, and is anyone using it? | CVSS v4.0 base metrics, EPSS, KEV, red team results | Needs internal access; no known exploit | Reachable by anyone who can send the agent content; working exploit exists |
| 2. Autonomy | Can the agent act without a person approving? | Agent design, approval logs | A person approves every action | Acts in production with no review |
| 3. Permissions | Whose authority does the agent act with, and how far does it reach? | Identity platform, service accounts, delegated scopes | One narrow service account, read-only | Broad or changing roles, crosses tenants or business units |
| 4. Tools | What can the agent call, and with what privilege? | Tool and MCP inventory, API scopes | Read-only lookups on an allow-list | Write access to payments, databases, cloud, CI/CD or email |
| 5. Memory persistence | Does what the agent is told survive the session? | Agent architecture, vector stores, retraining pipelines | Stateless; nothing kept | Long-term memory shared across sessions or users, or fed into retraining |
| 6. Business impact | What happens to the business if this agent is misused? | Business impact analysis, process owner | Internal convenience task | Customer money, regulated decisions, safety, or a critical service |
Our framework. Inputs 2 to 5 correspond to the Autonomy, Identity, Tools and Persistence factors in OWASP AIVSS v0.8; input 6 corresponds to the mission and well-being decision points in CISA’s SSVC.
Inputs two to five measure reach: how far one flaw can travel through this agent. Input six measures what is at the end of that reach. Keeping them separate matters, because the controls are different. Reach is cut by engineering changes to the agent. Business impact is cut only by moving the agent away from the process, which is a business decision.
How OWASP AIVSS turns agent factors into a score
AIVSS is the most developed public attempt to score this. Version 0.8 takes a CVSS v4.0 base score as the floor and adds an “agentic uplift”. It assesses ten factors, each scored 0, 0.5 or 1: execution autonomy, external tool control surface, natural language interface, contextual awareness, behavioural non-determinism, opacity, persistent state retention, dynamic identity, multi-agent interactions and self-modification.
The arithmetic is short. The uplift fills part of the gap between the CVSS base score and 10, in proportion to the sum of the ten factors, adjusted by exploit maturity:
- Agentic uplift = (10 minus CVSS base) times (factor sum divided by 10) times the threat multiplier
- AIVSS = (CVSS base plus agentic uplift) times the mitigation factor
The threat multiplier is 1.0 for a flaw under active attack, 0.97 where working exploit code or a detailed walkthrough exists and 0.5 where no exploit is known. AIVSS defaults to 0.97, on the reasoning that agent exploits are mostly natural language and need no compiling, so the gap between published exploit code and an attack is small. The mitigation factor runs from 1.0 for absent or weak controls to 0.67 for strong controls that have been validated and fail closed. That floor means validated controls can take at most a third off the score.
Here is what that does to one finding. Suppose a tester finds that instructions hidden in an incoming email can redirect an agent, and the finding scores 4.3, Medium, under CVSS v4.0. The organisation runs two agents that read that mailbox.
| Factor | Read-only assistant | Finance operations agent |
|---|---|---|
| Autonomy | 0: a person acts on every answer | 1: posts payments in production without review |
| Tools | 0: read-only search | 1: ERP and payment APIs with write access |
| Natural language control | 0.5: questions and answers only | 1: email text drives tool calls and plans |
| Context | 0 | 0.5: reads supplier records to decide |
| Non-determinism | 0.5 | 0.5 |
| Opacity | 0.5 | 0.5 |
| Persistent memory | 0: stateless | 1: long-term vector memory across sessions |
| Identity | 0: one fixed service account | 0.5: acts for several approvers |
| Multi-agent | 0 | 0.5: hands off to a reconciliation agent |
| Self-modification | 0 | 0 |
| Factor sum | 1.5 | 6.5 |
| AIVSS score (threat multiplier 0.97, no mitigation credit) | 5.1, Medium | 7.9, High |
An illustrative case. Factor values follow the AIVSS v0.8 rubric; the CVSS base score is assumed.
One CVSS 4.3 finding scored with the agent factors
AIVSS 5.1 · MediumAIVSS 7.9 · High
In the finance agent, autonomy, write tools and long-term memory push the same finding to 7.9, High.
Illustrative case. Formula and factor rubric: OWASP AIVSS v0.8, threat multiplier 0.97, no mitigation credit. The CVSS base score is assumed.
The finding is the same in both columns. In the assistant it stays Medium. In the finance agent it moves up a severity band, and it now outranks a finding scored 7.0 in the assistant, which AIVSS would put at 7.4. AIVSS v0.8 says this reordering is the point: its authors tell practitioners to rank on the AIVSS result over the CVSS result, and to read scores by severity band, because a 9.4 and a 9.7 should be treated alike.
What the score still leaves out
AIVSS covers four of our five agent inputs directly: autonomy, tools, permissions through its identity factor, and memory through persistence. It does not score business impact. Its formula measures how far the flaw can travel, then stops. A finance agent and a staff-canteen agent with the same factor profile get the same score.
We handle business impact as a separate step, after the severity score, and so does AIVSS. Version 0.8 notes that the project is working on an approach based on CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC), and that the two are designed to be used together. SSVC is a decision tree. CISA’s version takes exploitation status, technical impact, whether exploitation can be automated, mission prevalence and public well-being impact, and returns one of four decisions: Track, Track*, Attend or Act. Act means the vulnerability needs attention from both supervisory-level and leadership-level people in the organisation.
The practical version for an agent register is short. Give each agent a business impact tier when it is approved, set by the process owner, and combine it with the severity band:
| Severity band (agent-adjusted) | Tier 1: money, regulated decisions, safety | Tier 2: customer-facing or sensitive data | Tier 3: internal support |
|---|---|---|---|
| Critical | Act now: contain within 24 hours, then fix | Act: fix within 7 days | Attend: fix within 14 days |
| High | Act: fix within 7 days | Attend: fix within 30 days | Track closely |
| Medium | Attend: fix within 30 days | Track closely | Track |
| Low | Track closely | Track | Track |
Our illustrative policy. Deadlines are examples to adapt, not a benchmark. Decision labels follow CISA’s SSVC.
Under this policy the finance agent’s injection finding becomes Act, with a seven-day deadline. The same finding in the read-only assistant is Track closely. Both are the same Medium on the scanner report.
Agent-aware priority for one finding
Act: fix within 7 days. The same finding scores 4.3, Medium, on the scanner report.
Score: OWASP AIVSS v0.8, AIVSS = (base + (10 - base) x factor sum / 10 x threat multiplier) x mitigation factor. Decision: the illustrative deadline table in this post, with labels from CISA's SSVC. Starting values are the post's finance agent case.
Where ISO/IEC 27090 fits
ISO and IEC published ISO/IEC 27090:2026, Cybersecurity, Artificial intelligence, Addressing security threats and compromises to AI systems, in October 2026. It runs to 56 pages and comes from JTC 1/SC 27, the committee responsible for ISO/IEC 27001 and 27002. ISO describes it as guidance on understanding, detecting and mitigating security threats specific to AI systems throughout their life cycle, which “explains how vulnerabilities can be exploited, what the consequences can be and which measures can help address them.” It is written for any organisation that develops or uses AI. It gives guidance rather than requirements, so organisations are not certified against it the way they are against 27001.
We have worked from ISO’s published description of the final standard and from public descriptions of the drafts. Those describe a catalogue of deliberate attacks on AI systems, among them data and model poisoning, evasion, attacks that infer training data membership or invert the model, model stealing, and prompt and output injection, each with its consequences, detection and mitigation, and annexes mapping attacks to the stages of the AI life cycle and to the assets they target. Readers with the final text should check the clause structure against their copy.
The correlation with agent-aware vulnerability management is close, and it runs in one direction. ISO/IEC 27090 tells you what can go wrong with an AI system and what it leads to. It does not say which finding to fix first in which agent. That is the job an agent profile does.
| Agent-aware input | What ISO/IEC 27090 contributes | What it leaves to the organisation |
|---|---|---|
| Exploitability | How each AI-specific threat is carried out, and how to detect it. ISO’s summary says these attacks “can be difficult to detect and can compromise systems even when conventional protections are in place” | Scoring a particular finding; CVSS, EPSS and red team results still do that |
| Autonomy | Consequences of compromise during operation, across the life cycle | How much the agent can do without a person, which sets how far a consequence spreads |
| Permissions | Identifying what needs protecting, from training data to models | The credentials and roles the agent itself holds, which are the assets an attacker reaches through it |
| Tools | Prompt and output injection, the threats that turn text into actions | The inventory of tools each agent can call and their privilege |
| Memory persistence | The standard’s own example: data collected in operation can later be used to retrain, so “operational inputs can also become training data” | Whether the agent’s memory is kept across sessions and users, and who can write to it |
| Business impact | Connecting threats “to their potential impact”, with particular weight on safety-critical uses | The business impact tier of each agent and the fix deadline that follows |
Our mapping. Quoted text is from ISO’s published description of ISO/IEC 27090:2026.
Two points in that mapping deserve more attention.
The first is memory. ISO’s description of the standard singles out model updates and retraining: if data gathered in operation is corrupted and later used to update a model, the vulnerability carries into future versions, and in systems that learn continuously, everyday inputs become training data. An agent with long-term memory is a faster version of the same problem. It does not wait for a retraining cycle. What it is told today shapes what it does tomorrow. The OWASP Top 10 for Agentic Applications lists this as ASI06, Memory and Context Poisoning. Persistence therefore deserves its own field in the register, and a finding that can write to persistent memory should be ranked above the same finding in a stateless agent.
The second is the place of conventional controls. ISO says the standard complements ISO/IEC 27001 and 27002 and that “established cybersecurity practices remain essential.” Most organisations already run vulnerability management under ISO/IEC 27002 control 8.8, management of technical vulnerabilities. Agent-aware prioritisation does not need a new process. It needs the existing 8.8 process to read five more fields when a finding lands on an agent. ISO/IEC 27090 gives the security team a recognised reference for asking that the fields be kept, and ISO/IEC 42001’s AI system impact assessment is the natural place to record business impact.
Many agent flaws have no patch
Conventional vulnerability management ends with a patch. A large share of agent findings have none. Prompt injection through retrieved content is a property of how language models read text, and no vendor update removes it. The finding stays open, or it gets risk-accepted, and the queue fills with items nobody can close.
Agent-aware scoring shows a second route. If the score is driven by reach, cutting reach lowers it. In the finance agent example, three changes would bring the factor sum from 6.5 down to 4.5:
- Require approval for payments to a new or changed bank account (autonomy from 1 to 0.5).
- Split the ERP tool so the agent can draft a payment but not release it (tools from 1 to 0.5).
- Keep memory per session, and send anything the agent wants to remember long term through a review queue (persistence from 1 to 0).
The CVSS finding is untouched, and the agent’s AIVSS score falls from 7.9 to 6.8, back into Medium. If those controls are tested and fail closed, the mitigation factor can lower it further. This is often faster than waiting for a fix that may never come, and it is a decision the agent’s owner can take this week.
It also changes who owns the work. A patch belongs to the platform team. A cut in autonomy, a tool scope or a memory policy belongs to the person accountable for the agent. In the attack path post we argued that every agent needs a named path owner. Agent-aware vulnerability management gives that owner a queue.
How to start
We would start small and use what already exists.
- Add five fields to the AI system register. For each agent in production: autonomy, permissions, tools, memory persistence and business impact tier, scored on the 0, 0.5 and 1 scale, with a named owner and a review date. The agent’s owner fills them in; security checks them.
- Join findings to agents. Every finding on a model, a connector, a retrieval source or an agent’s host gets tagged with the agents it can reach. This is the step most programmes miss, because scanners report by host and not by agent.
- Rescore and set deadlines by band. Apply the AIVSS uplift, or your own version of it, then the business impact tier. Report agent findings to the risk committee by adjusted band, alongside the CVSS band, so the difference is visible.
- Use ISO/IEC 27090 as the test plan. Its threat catalogue is a ready list of what red teams and testers should try against each agent, mapped to the life cycle stage where each one bites.
- Track reach reductions as remediation. When an owner cuts autonomy, tools or memory to lower a score, record it as a fix with evidence and a retest, the same way a patch would be.
Questions for the board
We would ask management for written answers to five questions:
- For each agent in production, do we have a current record of its autonomy, permissions, tools, memory and business impact tier, and who keeps it current?
- When a vulnerability is found on a system an agent uses, how do we know which agents it affects?
- How many open agent findings would change severity band if we scored the agent as well as the flaw, and which way?
- Which agent findings have no patch, and what have we done to reduce the agent’s reach in the meantime?
- Has our security team mapped our agent testing to ISO/IEC 27090, and which of its threats have we never tested for?
Question three is the one we would ask first. The answer shows whether the current queue is ranked on the risk or on the flaw.
Free tool
Agent Risk Assessment Matrix
Place each agent on an autonomy and consequence grid, see which ISO/IEC 42001-referenced controls apply, and print a register entry. A quick way to fill in two of the five agent fields this post recommends.
Evidence & Methodology
The standards, scoring methods and definitions come from their primary sources. We have not read the full text of ISO/IEC 27090:2026; its scope comes from ISO’s published description, and its threat list from public descriptions of the drafts, graded accordingly. The six inputs, the finance agent case, the deadline policy and the mapping are ours.
| Claim | Source | Grade |
|---|---|---|
| ISO/IEC 27090:2026 published October 2026, edition 1, 56 pages, JTC 1/SC 27; guidance on threats to AI systems across the life cycle | ISO catalogue page for ISO/IEC 27090:2026 | Standard publisher’s description |
| 27090 notes that operational inputs can become training data, and that it complements ISO/IEC 27001 and 27002 | ISO catalogue page, FAQ | Standard publisher’s description |
| 27090 catalogue includes poisoning, evasion, attacks that infer training data membership or invert the model, model stealing, prompt and output injection; annexes map attacks to life cycle and assets | iso27001security.com, describing the draft text | Reported, based on drafts |
| AIVSS v0.8: ten agent factors scored 0, 0.5 or 1; uplift formula; threat multiplier 1.0, 0.97 or 0.5; mitigation factor 1.0 to 0.67 | OWASP, AIVSS Scoring System for OWASP Agentic AI Core Security Risks v0.8 | Framework text, pre-1.0 |
| AIVSS recommends ranking on the AIVSS result and reading scores by band; SSVC work under way to complement it | Same document, section 3.2 | Framework text |
| CVSS v4.0 splits impact into vulnerable system and subsequent system | FIRST, CVSS v4.0 specification | Standard text |
| EPSS estimates the probability a published CVE is exploited in the wild in the next 30 days | FIRST, EPSS | Standard text |
| CISA’s SSVC uses five decision points and returns Track, Track*, Attend or Act | CISA, SSVC | Government guidance |
| ASI06 Memory and Context Poisoning in the OWASP Agentic Top 10 | OWASP GenAI Security Project, 9 December 2025 | Framework text |
| 4.3 to 5.1 and 7.9; 7.0 to 7.4; factor sum 6.5 to 4.5, giving 6.8 | Our calculation with the AIVSS v0.8 formula on an illustrative case | Illustrative |
| The six inputs, the mapping to 27090 and the deadline policy | Our assessment | Our call |
Sources
- ISO and IEC. (2026, October). ISO/IEC 27090:2026 Cybersecurity, Artificial intelligence (AI), Addressing security threats and compromises to AI systems. Edition 1.
- ISO27k Infosec Management Standards. (2026). ISO/IEC 27090. Commentary on the draft standard.
- OWASP. (2026). AIVSS Scoring System for OWASP Agentic AI Core Security Risks, v0.8. OWASP AI Vulnerability Scoring System project.
- FIRST. (2023). Common Vulnerability Scoring System v4.0: Specification document.
- FIRST. Exploit Prediction Scoring System (EPSS).
- CISA. Stakeholder-Specific Vulnerability Categorization (SSVC).
- CISA. Known Exploited Vulnerabilities Catalog.
- OWASP GenAI Security Project. (2025, December 9). OWASP Top 10 for Agentic Applications for 2026.
- ISO and IEC. (2022). ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection, Information security controls. Control 8.8, Management of technical vulnerabilities.
How AI Agents Turn Low-Rated Security Findings Into a Serious Risk
How agent access joins separate findings into one attack path.
The Vulnerability Didn't Change. The Attacker Did.
Why risk acceptances priced on attacker effort need rescoring.
Why the AI Model Is the Weakest Link in Your Supply Chain
Integrity, provenance and limits that assume the model is compromised.
An AI Management System Is Not a Policy Binder. It's the Machine ISO 42001 Actually Audits.
Where the agent register and impact assessment live in an AIMS.
My thanks to Maria Singh, who co-wrote this post with me.
If your organisation wants its agent findings rescored against what each agent can do, with owners and deadlines that match, that review is where I usually start. My consulting work covers technology and AI risk governance for boards of regulated firms and public agencies.