Podcast: Why OWASP’s AIVSS Scores Agentic AI at Maximum Risk

Tova Dvorin (00:01.42) OWASP just dropped a new scoring framework for agentic AI systems. And I don’t mean they updated their LLM top ten. They built an entirely new vulnerability scoring methodology, AI CVSS, specifically for autonomous AI agents. Adrian, you’ve been through it. Before we get into the mechanics, what’s the headline? Adrian (00:20.418) The headline is that the most dangerous AI agent scenario in the framework scores a perfect 10, not a nine point something as we’re used to from CVSS, a 10. And that’s not a theoretical worst case. It’s the scored example for a compromised multi-agent orchestration system, which if you’re in any kind of enterprise, agentic AI deployment right now is not a thought experiment. Tova Dvorin (00:47.268) So OWASP didn’t just say agentic AI is risky, they quantified it. Adrian (00:51.458) They did quantify it and more importantly, they built a model that shows why agentic systems score so differently from traditional vulnerabilities. The short version, your CVSS score is just the floor. The ceiling is set by what the agent can do once the floor is exploited and autonomous agents with memory, tool access and the ability to make decisions without human sign off, push that ceiling very high and very fast. Tova Dvorin (01:19.554) Welcome to the Cyber Resilience Brief, a Safe Breach podcast. And this is our episode about the 2026 updates to OWASP’s Agentic AI framework. Let’s back up for listeners who haven’t been following the agentic AI risk space closely. When we say agentic AI, what are we actually talking about? Adrian (01:38.414) So we’re talking about AI systems that don’t just answer questions. They pursue goals. They plan across multiple steps. They have tools, real tools to call APIs, write to databases, send emails, execute code, interact with cloud infrastructure. And critically, they do this continuously, loop engineering, often without a human in the loop to approve each action. The OWASP document uses a fairly crisp working definition. autonomously defining and pursuing goals, reasoning and planning, taking actions through external tools, and leveraging memory across sessions. That last part, memory across sessions, is where it gets interesting from a security perspective. Tova Dvorin (02:22.146) Right, because in this case the attack surface isn’t just the one interaction, it’s persistent. Sorry, it persists. Adrian (02:29.277) Exactly. If I poison the memory of a traditional application, I get one bad output. If I poison the memory of an agent that runs continuously for your finance team, approving purchase orders, managing vendor onboarding, handling exception requests, that poisoned context shapes every decision the agent makes until someone catches it, which might be a while because auditing agent behavior is genuinely hard right now. Tova Dvorin (02:56.58) Okay, so OWASP identified 10 core security risks for agentic systems. Adrian, walk me through the shape of this list. What does it cover in practice? Adrian (03:04.567) So the 10 are agentic AI tool misuse. Agent access control violation, agent cascading failures, agent orchestration and multi-agent exploitation, agent identity impersonation, agent memory and context manipulation, insecure agent critical systems interaction, agent supply chain and dependency risk, agent untraceability, and agent goal and instruction manipulation. And to be clear, OWASP isn’t ranking these one through 10 by severity. They’re listed in descending order of expert assessed severity, but the AIVSS scoring they do across all 10 puts most of them in the critical band, which tells you something. Tova Dvorin (03:50.54) Mm, what does it tell you? Adrian (03:52.385) It tells you that when you combine an autonomous system with broad tool access and a natural language interface, almost every known attack class becomes more dangerous. SQL injection in a reporting tool is a high. SQL injection in an agent that can read the results, interpret them, and autonomously send them to a third party, that’s a different problem. The underlying floor is the same. The blast radius is entirely different. Tova Dvorin (04:20.639) Right, you’re touching on the core concept in this new scoring model. It’s called the amplification principle. Let’s t let’s talk about that a little. Adrian (04:26.804) right over. OWASP calls it the force multiplier concept. The agent’s architecture, its ability to plan, chain tools, retain memory, doesn’t just create new risks. It fundamentally expands the blast radius of every underlying technical vulnerability. So they built a scoring system that reflects that. You start with your CVSS version four base score, which represents the technical severity of the underlying floor. Then you add what they call agentic uplift. a score based on 10 specific agent capabilities that determine how much worse the floor gets in an agentic context. Tova Dvorin (05:05.763) What are these ten amplification factors assessing exactly? Adrian (05:09.674) Execution autonomy. Can the agent take actions without a human approving each step? Breadth and privilege of external tool access. Reliance on natural language for control logic, because natural language is where prompt injection lives. Contextual awareness, meaning where the agent is pulling in broad environmental signals to drive decisions. Behavioral non-determinism, whether the same input consistently produces the same output. Opacity. How observable is the agent’s reasoning? How auditable are its actions? Persistent memory across sessions, dynamic identity, whether the agent can assume different roles at runtime, multi-agent coordination, and self-modification capability, whether the agent can alter its own goals, tools, or code. Each factor scored zero to one, summed, divided by 10. multiplied by the remaining headroom to the maximum score. Then you apply a threat multiplier and a mitigation factor. Tova Dvorin (06:10.399) Okay, as usual, this is a lot to unpack here, so let’s ground this in some of the actual scored examples, because the numbers themselves are striking. Let’s start with the one that scores a ten point Adrian (06:21.325) So that’s the agent orchestration and multi-agent exploitation. The scenario is a compromised central orchestrator, the agent that coordinates and delegates tasks to the other agents in the network. Underlying CVSS score on that scenario is 9.4, already critical. But the amplification factors are almost all maxed out. The orchestrator has full autonomy, broad tool access, natural language driving its orchestration logic, long-term memory, dynamic identity delegation to subagents and it sits at the heart of multi-agent coordination. Factors sum of 9.5 out of 10, the math pushes it to 10. And that’s not a hypothetical stretch. If you’ve deployed an orchestration layer, that’s your risk profile. Tova Dvorin (07:08.213) Mm-hmm. Now here’s what I find more striking. Show me an example where the underlying C VSS score is low, but the AI VSS score is high, because that’s where the model is doing something genuinely different from traditional vulnerability scoring. Adrian (07:21.463) So Tova, the best example is something that we’ve referred to before in a previous podcast. It’s documented by OWASP in their document. It’s the agent goal and instruction manipulation. Incremental prompt injection. An attacker over multiple sessions subtly shifts what the agent thinks its goal is without triggering safety filters, gradually steering it towards providing inaccurate or harmful outputs. The underlying CVSS score for that scenario is 2.1, low in the traditional application. 2.1 CVSS is basically noise. You deprioritise it immediately. Tova Dvorin (08:04.333) But this isn’t traditional and here the AI V S S score is not two point one. Adrian (08:09.322) Exactly, the AIVSS score is 7.1 high. The uplift is almost five points and it comes almost entirely from the agentic factors. Natural language is the entire attack surface. The agent has long-term memory that the attacker is conditioning across sessions. The goal drift is invisible to monitoring because the agent appears to be functioning normally. And the agent can modify its own goal state through the conditioning process. That’s the amplification. A 2.1 vulnerability is the wrong agent. With the wrong capability profile is a high severity finding that you shouldn’t be ignoring. I’ll redo that last sentence. A 2.1 vulnerability in the wrong agent with the wrong capability profile is a high severity finding that you shouldn’t be ignoring. Tova Dvorin (08:59.563) Adrian, what’s the operational implications of that score and that disparity of scores for a security team in practice? Adrian (09:06.84) So OWOS makes this explicit. When the AIVSS uplift significantly exceeds the CVSS base score, the agentic deployment context is the primary risk driver, not the technical flaw. Patching the underlying vulnerability without constraining the agent’s capabilities does not materially reduce your risk. We all need to move on from patch and proceed. You need to address the amplification factors directly. constrain autonomy scope, restrict tool access, enforce shorter memory retention, increase human oversight checkpoints. The agent architecture is the remediation target, not the code. Tova Dvorin (09:48.92) Let’s talk through the ten risks named here more substantively. Sub sorry, let’s talk through the ten risks more substantively. You mentioned tool misuse is first on the list. What does tool misuse actually cover? Adrian (10:01.496) So tool misuse is broad to over. It’s anything that goes wrong in how an agent selects, invokes or interprets the output of its tools. The OWASP document breaks it down into tool selection, tool usage and tool oversight. On selection, tool squatting, where an attacker registers a malicious tool under a name that mimics a legitimate one. So the agent invokes it and sends data to the attacker. Insecure tool interfaces, use of outdated tools with known CVEs. On usage, insecure invocation where inputs from untrusted sources reach tool calls without validation. Compromised tool usage, a legitimate benign tool used in a way that produces harmful side effects. Tool output misinterpretation, where the agent’s parsing logic is wrong and it makes bad downstream decisions. And on oversight, no monitoring, no kill switch, no authoritative inventory of what tools the agent can even call. Tova Dvorin (11:00.343) The kill switch point really stands out. That’s a physical world concern as much as a digital one. Adrian (11:05.496) So the document again cites a specific scenario, a financial trading agent that misinterprets an operational prompt, starts executing unauthorized high risk trades, then ignores software shutdown commands. With no independent kill switch, the response teams have to manually disconnect network access. Avoidable losses, and that’s a relatively contained example. The document is explicit that in safety critical deployments, autonomous vehicles, medical systems, infrastructure management, current detection and containment approaches may be genuinely insufficient against a cascade event. That’s not hyperbole. That’s OWASP saying we don’t have the tools yet. Tova Dvorin (11:49.444) Access control violation that’s second on the list and the survey data in the appendix puts it as the highest severity risk in practitioner perception. What are the specific failure modes? Adrian (12:00.248) So the failure modes are numerous and some are specific to agentic systems in ways that don’t translate cleanly from traditional application security. Permission escalation and role inheritance exploitation, where an agent picks up elevated permissions it shouldn’t have, often through misconfigured role assignments. Credential and token mismanagement. An agent is manipulated into revealing API keys during operation. Control flow hijacking. Attackers manipulate the metadata that guides an agent’s action sequence to redirect it. Memory-based data leakage. Poor memory isolation means context from one secure session bleeds into another. And the confused deputy pattern, which is a classic from OS security, an agent without permission to access certain data asks a more privileged agent to retrieve it on its behalf, effectively bypassing the control. The real world example of this site is a 2025 vulnerability in Microsoft 365 co-pilot called Echo Leak, a zero click attack where a malicious email manipulates co-pilot into accessing and exfiltrating confidential internal data. That’s not theoretical. Tova Dvorin (13:13.035) Right. Echo leak here is a good example because this is something happening right now. We often talk about a genetic AI as if it’s in the future, but this shipped already last year. Adrian (13:22.978) They’re shipping now Tova, and they’re finding real targets. GitHub’s MCP integration, Langsmith, several other platforms of all disclosed vulnerabilities in the last 12 months that map cleanly into these risk categories. The OWASP documents sites research from invariant labs, Pillar Security, Noma Security. This is a live active vulnerability class, not a theoretical threat landscape. Tova Dvorin (13:49.271) Cascading failures is the third risk, and this is the one that worries me from a systemic perspective. Let’s dive into it a little. Adrian (13:55.886) It should worry everyone over cascading failures is what happens when a compromise in one agent propagates across the network. It’s a property of multi-agent systems that a single point of compromise can have exponential impact, not linear. The underlying scenario they score on this one is a 7.1 CVSS, but the AIVSS comes out at 9.4 because the multi-agent factor and the non-determinism factor both amplify it significantly. The specific mechanisms include cross system exploitation via trust relationships. One compromised agent leverages implicit trust to pivot to connected systems, SAS to SAS pivoting through pre-authorized integrations, and hallucination propagation, where one agent generates incorrect output that downstream agents treat as ground truth. OWASP flags explicitly. that as standardised protocols like MCP and A2A mature and become ubiquitous, the blast radius of a single cascade event will expand. Tova Dvorin (15:01.675) Right, and that’s because standardization means more agents will trust each other by design and then these things can cascade throughout a chain of agents. Adrian (15:09.822) More agents trust in each other by design on a shared protocol stack. Yes, the document uses the phrase market-based multi-agent systems as an emerging cascade attack surface that isn’t well understood yet. Systems where agents bid competitively for tasks or resources. Economic feedback loops as an attack surface. This is genuinely new territory. Tova Dvorin (15:36.215) Let’s cover memory and context manipulation because this is the one I think most organizations aren’t thinking about at all yet. Adrian (15:42.798) So memory and context manipulation is the attack class where an adversary exploits how an agent stores and retrieves context, either within a session or across sessions in long-term memory stores like vector databases. The attack patterns range from long-term memory poisoning, where you feed an agent a false rule during a conversation and it stores it for future use, to rag data poisoning, where you inject malicious content into the retrieval database, the agent queries for context. The OWOS document highlights a particularly concerning pattern, encoded persistent conditionally triggered payloads embedded in memory stores that remain dormant. and only activate under specific runtime conditions. You’re essentially planting a live time bomb in the agent’s memory that fires when a specific condition is met. Current monitoring approaches are not designed to catch this. Tova Dvorin (16:38.303) Yikes. And also the memory and context manipulation risk is also the one with the biggest disp sorry, it’s also the one with the biggest discrepancy between C VSS and AI VSS after goal manipulation. The C VSS is 5.8, but the AI VSS is 8.9. And that’s driven by persistent memory and opacity. Adrian (16:52.056) Those speakers are on. Those speakers are on. Correct, the underlying technical flaw is medium severity. The agentic context makes it high almost critical because persistence means a successful attack doesn’t just affect one session. It shapes every future decision the agent makes until someone specifically audits the memory store and opacity means auditing it is non-trivial. Tova Dvorin (17:21.517) Supply chain risk is interesting because it bridges to a threat landscape that enterprises are already very familiar with. That’s the solar winds, XC UTILs, all the classic software supply chain incidents. But this document argues a gentic supply chain is different. Adrian (17:35.916) It is different over in a few different ways. Traditional supply chain attacks compromise code. A genetic supply chain attacks can compromise code, models, training data, retrieval pipelines, runtime APIs, and tool registries, all of which feed into how the agent reasons and act. The document highlights a specific failure mode called capability creep. Where a vendor you approved two years ago as a passive SaaS application has since deployed autonomous agents that inherited the broad OAuth scopes you granted to the original tool. They pushed an agentic capability update, your existing permissions cover it, you had no new security review triggered, and now you have an agent with tenant-wide access that nobody explicitly authorized. That’s a real and widespread exposure right now. Tova Dvorin (18:24.779) Right, because in the procurement process, you approved the application, not the agents that came along with it. Adrian (18:32.011) because the procurement process approved the application and not the agent exactly. And the traditional third party risk management flow, which is front loaded at procurement, doesn’t catch a vendor adding agent capabilities 12 months after sign off. The document flags package hallucinations as another specific supply chain risk. LLM generated code that references non-existent packages, which attackers can then register under those names as typo squatting back doors. Safebreed has done work in this space mapping these patterns to monitor attack and the technique coverage gaps are in the current playbook as they’re real. Tova Dvorin (19:10.143) A agent and traceability, this is the one that keeps forensic teams up at night. Adrian (19:14.431) Untraceability is the inability to reconstruct what an agent did, when, on whose authority and why. The document calls it a forensic black hole, not just missing logs, but the structural difficulty of correlating actions across multiple agents, multiple identities, multiple cloud and SAS systems, when agents are acting ephemerally and inheriting permissions from multiple sources. The attack scenarios include direct forensic evasion, an agent using its legitimate capabilities to selectively delete logs covering a breach, through to XAI layer poisoning, where an attacker manipulates sharp or lime outputs to produce misleadingly plausible explanations of what the agent did, even though the explanations are false. To base truth tover, you can’t investigate what you can’t trace. Tova Dvorin (20:03.843) So let’s come back to brass tacks. Let’s talk about the practical implications. An enterprise security team is listening to this. They have AI deployments in flight or planned. I think we’ve covered this in this episode. If you’re listening carefully, what we’re saying and what OWASP is saying is that all of the ways we traditionally think about vulnerabilities in all of our infrastructure and systems have changed because of the impact that agents can have, period, on a very, very high level. But specifically, what does OWASP’s AI VSS framework tell them they should be doing differently, not just in their mode of thinking? Adrian (20:36.75) First, know your amplification factor profile for every agent you’re running or planning to run. The 10 factors in AIVSS aren’t just scoring inputs, they’re a capability checklist that tells you where your blast radius lives. An agent with full autonomy, broad tool access, persistent memory and dynamic identity is a fundamentally different risk object than a chatbot. Treat them differently at procurement, architecture review, and that runtime. Tova Dvorin (21:08.525) And what are the governance structures that this document recommends? Adrian (21:12.246) An AI governance board, senior level, CISO, GRC, legal risk business, an AI risk classification committee that does use case level risk classification before deployment and at major changes. Something the big consultancy companies are very big on with the three P’s, principles, policy and practice. AI principles, AI policy, AI practice. There can be no AI gaps. They all must segue into each other. and feed into each other, otherwise, no matter how nice they are, they’re useless. Explicit release gates in your SDLC where agentic systems above a certain AIVSS risk tier require approval before hitting production. The document is quite explicit that assessments should be triggered by architecture changes and threat landscape shifts, not just done at procurement and forgotten. That’s the life cycle integration piece. Tova Dvorin (22:06.625) And where ultimately do we see adversarial exposure validation fit in? Because of course, you and I know that’s the conversation we are constantly having on this show, besides for cyber resilience. You can’t manage what you can’t measure, you can’t measure what you don’t test, and as we just added, you can’t investigate what you can’t trace. Adrian (22:23.724) The document aligns precisely with that over the NIST AIRMF integration section positions AIVSS scoring as an input to the measure functions TEVV activities, test, evaluation, verification and validation. The implication is direct. You need to be running adversarial controls on all your detection. You need to be running adversarial controls or your detection stack. The risk categories in AIVSS are simulatable. Tool misuse scenarios, an agent being manipulated into invoking malicious tool, can be emulated. Goal injection attacks against a specific agentic system can be red-teamed. Memory poisoning attempts can be validated. The question is whether your security program treats an agent as part of the attack surface or something that sits outside of the security testing perimeter. Most programs right now are treating agents as outside scope. The AI VSS framework is an argument for why that’s the wrong call. Tova Dvorin (23:29.057) Now, Adrian, as you know, we at Safe Breach have been working on agentic AI security validation. And actually, at the time this episode is released, listeners who are listening to the Safe Breach radio dial go and check out our website because we’ll have more coverage about it there. But let’s give our listeners a little bit of a preview. What does our new agentic AI security validation coverage look like in practice? Adrian (23:49.934) So the honest answer, and you should be looking to get the same answer from anybody as a vendor in this space right now, is that this category is young and the tooling is maturing. What exists today, and now let’s talk specifically about SafeBreach, what we’re developing, is the ability to map the OOSPRISQ categories to specific simulation scenarios. What does a tool squatting attack against your agentic system look like in execution? Does your monitoring catch it? Does your response engage? What does a memory poisoning attempt against your right pipeline look like in terms of observable telemetry? The hackers playbook already covers significant portions of the attack surface that feeds into these scenarios. The initial access and lateral movement techniques, the setup agent compromise, the agentic specific scenarios are the extension and that’s active work for everybody at the moment. The point is that AIVSS gives you the risk taxonomy and the severity scoring. Adversarial validation gives you the evidence that your controls actually address the risk. One without the other is incomplete. Tova Dvorin (24:57.141) One thing I want to flag for listeners who are going to read the full OWASP document. The framework is explicitly a living document. At the time of this recording, we are discussing version zero point eight. OWASP is inviting community contributions, and the risk categories will evolve as this threat landscape evolves. The agenda KI threat surface is moving faster than most security frameworks can track. Adrian (25:17.622) Which is itself a governance point, Tovi. If your risk register has a line item for agentic AI risk today, it probably doesn’t reflect what the risk looks like in six months time. The speed of capability deployment in this space is outpacing the speed of security framework development. OWASP AI VSS is the most rigorous attempt I’ve seen to build a durable scoring methodology that doesn’t go stale. because the amplification factors are structural properties of agent architecture, not specific techniques. That makes the framework more durable than a techniques list would be. But the specific attack scenarios will grow. Watch the appendices, the contributives survey findings in Appendix D and the crosswalk to OWASP’s agentic AI top 10 for 2026 in Appendix B. Give you a sense of where the practitioner community thinks the highest risk gaps are right now. Tova Dvorin (26:12.023) Final question, Adrian. If you had to identify the single most important thing CISO should take away from the AI VSS framework right now, what is it? Adrian (26:20.258) that your CVE scanner is not giving you the right number. A 2.1 CVSS finding in the wrong agent is a 7.1 AI VSS finding and it should be on your board’s radar. The methodology shift OWASP is proposing treating the agent architecture itself as a risk amplifier, not just a container for vulnerabilities is the right framing for this problem. Agentic AI systems require a security program that assesses them on their own terms. AIVSS is that program. It’s version 0.8, it will get sharper, but the principles it’s built on, that an autonomous agent’s capabilities are inseparable from the severity of any flaw within it, that’s the right principle and the sooner security seams are working from it, the better. Tova Dvorin (27:08.291) We’ll link the full OWASP AI VSS document in the show notes. It’s available at AIVSS.owasp.org. And it’s worth reading end to end. The scored examples in part two are particularly useful if you’re trying to operationalize this. In the meantime, if you want more information on what Safebreach is doing for OWASP coverage, keep a close eye on our website around the time that this episode is released. We’d be happy to fill you in on all the details. It’s very exciting. And in the meantime, Adrian, thank you so much as always for providing your expertise and your time on this episode. Adrian (27:37.771) It’s a pleasure, Tova. Tova Dvorin (27:40.183) Thank you. And for our listeners, until next time, stay safe. Stay safe with safe breach.