Most of us in cybersecurity who have been focusing on AI security over the last couple of years have argued about models. This includes which model, which vendor, which benchmark to use, whether open-weight models have closed the gap on the frontier or not and whether any of the models can be trusted with organizational data or in production systems and workflows.
That said, OWASP’s latest 2026 Top 10 for LLM Applications recently dropped and the letter in the beginning of the publication from my friends and Project Leads Steve Wilson and Rock Lambros open up by telling the ready those arguments are basically missing the point. The below quote from the publication is something I want to cite:
That’s the entire thesis of the latest OWASP Top 10 summarized in the opening letter of the document and once you take that in, the remainder of the new document reads like a guide for practitioners in how to think about securing agentic AI and LLM deployments and the importance of the harness when it comes to being a security and trust boundary.
I’ve been making a version of this argument for several months and I discussed it in my prior article “Learning From the Frontier”, where I worked through AISI’s agent incident report, where the danger doesn’t live in the model weights but lives in the harness around the model, including Internet access and the ability to have autonomy, access tools and take actions. I also published a video on the incident.
In this article I want to walk through what the latest version of the LLM Top 10 changed, and some of the key takeaways for practitioners thinking about securing Agentic AI deployments in production environments.
Testing the Vote Against the Record
One of the aspects I thought was cool from the latest OWASP LLM Top 10 was that they used a methodology where they took the vote of practitioners, which they had done previously to determine the ranking, but they also leveraged real-world incident data to see how rankings contrasted against what practitioners voted on.
This included 7,714 real incidents from public vulnerability and AI harm databases, which in and of itself speaks to how commonplace incidents involving LLMs and agents is becoming, which was something the team also did with the OWASP State of Agentic AI Security & Governance Report, which I previously covered as well.
As they did the analysis comparing practitioners fears and rankings compared to the incident data they started to find some surprising differences. Most practitioners minds jump right to things such as Prompt Injection, ranking it the #1 risk but when it came to incident record data, OWASP said Prompt Injection would have fallen out of the Top 10 entirely.
However, they say it isn’t become prompt injection isn’t a relevant issue, but instead they call it a defense effect, arguing organizations have made efforts to mitigate injection, so fewer clean exploits that are directly attributable to prompt injection land in the public databases and incident counts.
Joshua Saxe who previously helped lead AI security and safety efforts at Meta made a different argument recently in a piece of his, titled “Where Are All The Prompt Injection Damages”, where he argued universal prompt injection is becoming less common with the latest leading models, due to improved defenses but also the fact attackers already have ample techniques that bear fruit. Below you can see him highlighting the lack of financial damages tied to prompt injection as a technique to compared to other attack technqiues.
This is a point echoed by Anthropic’s Boris Cherny recently in an interview with YC, where he argued "Anthropic’s Opus 5 model does not seem to be prompt injection anymore”, he goes on to discuss that when you combine a well aligned model with a prompt injection classifier for all traffic, coupled with an auto-mode classifier, it is very hard to demonstrate prompt injection. I have set the video below to begin at the 2:10 minute mark, which is where Boris discusses this:
That said, despite the lack of real-world financial damages, progress at the frontier labs, or real-world incident data as pointed out by OWASP themselves, prompt injection still holds the top spot on the LLM Top 10 due to the community vote carrying 75% of the vote.
This is something for organizations leveraging the Top 10 to keep in mind when it comes to allocating their time and resources, and ensuring it is tied to real-world impacts, not just popularity rankings.
There is also a third explanation for the ranking I want to throw out there, which is that injection rarely produces a cleanly attribute public record tied to incident because the impacts often surface downstream. This includes impacts such as stolen credentials, exfiltrated data or source code, poisoned build processes and so on, and gets counted as those, rather than prompt injection.
This actually can be visualized by leveraging a image from OWASP themselves in the LLM Top 10 doc. Below you can see prompt injection is an entry vector not an impact:
Viewing the OWASP LLM Top 10 As a Harness Document
Now that I’ve wrapped up my side rant about prompt injection, attribution, entry vectors and whether or not is solved by the frontier labs and how, we can start to look at the OWASP LLM Top 10 from the perspective of the harness, which is where the risks really lie.
As an aside, my teammate Diana Kelly from Noma recently had an excellent interview on the podcast Cloud Security Today, where she discusses the AI Harness in-depth.
As I showed in the image above, Excessive Agency jumped from #6 to #3 on the latest OWASP LLM Top 10 and OWASP called it the most significant move on the risk and it is directly tied to organizations ramping up agentic deployments and this being where the damage is landing. Other risks such as Unbounded Consumption and Improper Output Handling moved around the lost and others such as System Prompt Leakage became Hidden Context Exposure, speaking the importance of the context window.
All of these moves are properties of the software we build rather than the weights. For example, excessive agency is tools, permissions and autonomy. Unbounded consumption is rate limiting, quotas, and circuit breakers. Hidden Context Exposure is what your app loads into the context windows and you shouldn’t assume always stays private and none of these issues get fixed by swapping model vendors.
LLM01 - Prompt Injection makes the architectural version explicit cleanly summarizing why you can’t necessarily train away prompt injection, noting that:
“LLM’s make no architectural distinction between instructions and data (both are tokens on the same stream), so there is no clean equivalent to parameterized queries”.
This why when you listened to Boris above he mentioned the role of classifiers in addition to model alignment to try and mitigate albeit not entirely eliminate prompt injection.
LLM08 - Hidden Context Exposure goes further in the publication, telling practitioners to design on the assumption that t he hidden context is discoverable and that nothing in the context window should be treated as a secret. When we consider everything that goes into the context window, from our personal chats with the LLM, sensitive data, and so on, its easy to see why this reality is scary from both a security and privacy perspective.
Their mitigation guidance takes it further, stating that “critical controls such as privilege separation, authorization bound checks, and similar must not be delegated to the LLM”, whether through the system prompt or other mechanisms. I’ve been arguing that system prompts are not security controls, so it is useful to have an industry authority such as OWASP enforcing that point.
OWASP also plainly states the the distinction between the LLM Top 10 and the Agentic AI Top 10:
"One boundary matters more every year. This list owns the risk when the model is a component inside your application. The moment that model becomes an actor, with tools it can call, memory it carries between sessions, and consequences it sets in motion downstream, the risk moves to the OWASP Agentic Top 10."
That is OWASP directly stating that once the risk now long is directly tied to the model, it belongs to the Agentic AI Top 10 instead. I’ve served on the Distinguished Review Board for the OWASP Top 10 for Agentic Applications, so it was good to see the authors help clear up the delineation between the two, as many are becoming overwhelmed with the number of Top 10’s out there, with the latest example being the OWASP Agentic Skills Top 10, which I covered in a recent article titled “Dangerous Skills”.
So What Is a Harness?
So we’ve talked a ton about OWASP lists and specific risks such as prompt injection, and the industry has been talking about the importance of a “Harness” a lot lately, but what the hell is a harness exactly?
Databricks has had one of the easiest to understand explanations on this in a blog titled “What is an AI Agent Harness”. In it they state:
“An AI agent harness is the software infrastructure that wraps around a large language model (LLM) and enables it to act on tasks, not just respond to prompts. The model reasons through a problem and decides what to do next. The harness connects it to the tools, systems, memory and execution environments needed to carry out those actions.”
The components they mentioned above align with the OWASP LLM Top 10 fairly one, with things such as system prompts and context assembly aligning with LLM08, tools, permissions and autonomy with LLM03, memory and retrieval on LLM01 and LLM09, tool and model provenance on LLM04, output parsing on LLM10, and quotas and circuit breakers on LLM06.
Addy Osmani, who I follow, as do many others, had a great O’Reilly article on agent harness engineering and he argued that a decent model with a great harness beats a great model with a bad harness. Below is a useful visualization from that piece:
Dan McAteer also recently had an excellent blog on Latent.Space diving into the evolution of the agent harness. He described the harness as “everything besides the model weights that makes the agent work” and “the harness is like giving the mind of the model a body”.
This is a point made within security too, such as by teams such as AISLE, who argued the “most is the system, not the model” when it comes to using AI to find vulnerabilities.
Where the Capability Actually Went
This part of the blog discusses my changing thoughts on model selection and the conversations I’ve had on the podcast that played a part.
For example, I previously had Niels Provos on the show and he argued that you don’t need a frontier model to find zero days, and that vulnerability discovery is an orchestration problem rather than model problem. Neils discussed finite state machines that decompose vulnerability finding into stages, each with a fresh context and a tight prompt, getting reliable results from weaker models that would otherwise fall short.
I also chatted with Stanislav Fort of AISLE, who showed how their research team has small open models that are finding real vulnerabilities even in heavily audited code bases at roughly $.11 cents per million tokens.
The UK’s AI Security Institute published research in December 2025 that supports the importance of the harness as well. They found on software engineering tasks, agents with the best externally developed scaffolds reliably outperform the best base models. This shows the harness is key both for software engineering activities, as well as security ones, as Niels and Stanislav discussed above.
Fusion, Routing and the End of the Single Model Enterprise
Another trend unfolding for technical and economic reasons of the rise of organizations embracing many models, including a mix of frontier and open source. I’ve been watching this one heat up since earlier this year when Mythos 5 got banned/blocked, and GPT-5.6 got gated.
That coupled with the blowback from tokenmaxxing and the open source ecosystem closing the gap has led to many openly embracing open weight models, or a mix of models based on the task, rather than using the best tool for every job, regardless of how basic it is.
The harness is also absorbing the act of model selection. OpenRouter published results in June from their system they call “Fusion”, which routed prompts to a panel of models in parallel and had a judge model synthesize the answer. This sort of innovation is part of the story in why Stripe is buying OpenRouter for $7.5B.
Others such as a16z have reported survey results showing nearly half of CIO’s report using 5 or more models, which is up from 29% the year prior.
So the enterprise is increasingly becoming multi-model and the harness is playing a key role in routing etc.
This has security implications as well, with activities such as model risk assessment, provenance, and IR needing to account for environments with multiple models being used and the harness being a key part of how. Logs and telemetry now need to account for the router, rather than a single vendor or agreement and this ties to LLM04 Supply Chain as well, as the model inventory grows, each introducing its own unique security risks and considerations combining commercial frontier vendors and open source model offerings.
Another interesting aspect of this is OpenAI recently open sourced their harness for Codex, which is built on the open agent harness. Ken Huang recently had an excellent detailed blog breaking the harness down. This shows you that the frontier labs view the harness as something you give away, while model weights remain proprietary and organizations need to inherit, review, patch and inventory the harness components they use.
Where the Harness Actually Broke
None of the discussions around the security concerns of the harness are theoretical either. Several have written about the role of the harness in recent agent breakout stories from the labs and research institutes.
Additionally, various CVE’s are tied to vulnerabilities such as CamoLeak in October 2025, where a GitHub Copilot Chat flaw allowed invisible markdown comments to lead to exfiltration through GitHub’s own Camo image proxy. The issue lied in the rendering pipeline, not the model, which behaved as designed.
There are other examples such as Tenable finding CVE’s in Cursor, that were time-of-check to time-of-use flaws, where approved MCP configurations stay trusted because approval was bound to the MCP name rather than its contents, or teams such as Oligo producing findings in Anthropic’s own MCP inspector.
As I mentioned above, the various agent breakout stories are also riddled with issues tied to the sandboxes and build pipelines involved.
Then there are supply chain incidents, such as the Nx s1ngularity compromise, where leading models such as Claude, Gemini and others were prompted to enumerate filesystems before exfiltrating credentials such qas tokens, SSH keys and .env secrets and over 1,000 victim accounts.
There are plenty of other examples to point to but the key point is that none of them were a “model failure” and things such as model evals wouldn’t have surfaced the findings. The failures lied in the rendering, permission checking, transport, sandboxing and build integrity of the systems around the models.
So while the industry has spent the last 24 months hyper-focusing on model-centric security, agents expand the real risks to the harness around the models, and as you can see from above, the opportunities for vulnerabilities, misconfigurations and exploitation is vast due to the complexity of the environments these models are hosted in and interact with via agents and their autonomy.
These trust boundaries introduce risks, and I walked through them in a blog titled “Agents Have Boundary Issues”, where I cited a similar research paper on the topic.
While Boris mentioned some of the latest Anthropic models are resistant to prompt injection, the reality is that every organization and environment leveraging the models will have unique environments, configurations, permissions, etc. which leaves the door open for this sort of activity beyond the model itself.
That said, these incidents are likely to be attributable to other causes, rather than prompt injection, as pointed out in the OWASP LLM Top 10, as well as by Joshua Saxe in his article I cited above.
Closing Thoughts
The latest OWASP LLM Top 10 says it directly, the model is often not the thing we are defending, and it says so backed by evidence and real-world incident data as well. That said, the complexity of the disparate OWASP Top 10 publications coupled with the nuance laid out by Josh highlight the challenges of trying to measure this class of risk and rank it accordingly.
All of this to say it is time to stop treating model choice as the significant security decision and instead treat the harness as an asset class security needs to be deeply familiar with and own from a risk perspective.
It is where the capability lives, where incidents of the past year landed, and where the controls that hold under an adversary or even model alignment challenges are enforceable. This means it needs to be inventoried, assigned an owner, threat modeled as the privileged application it is and have boundaries enforced deterministically rather than hoping soft guardrails such as model alignment and system prompts hold.
What I will be keeping an eye on is how the industry answers this challenge, how we build this layer from a security perspective moving forward and how the continued evolution of the model and the systems around it contribute and complicate this reality.












"Critical controls must not be delegated to the LLM" is the line I'd hand to an executive. Ask a team who owns an agent and you get a real name maybe half the time. Ask who owns the harness and there's usually no name at all, because it got stitched together from a framework somebody picked and whatever the MCP server does. Excessive Agency jumping from #6 to #3 tracks with that. Would the inventory you're describing cover the harness pieces a team inherited, or only the ones they wrote?