AI changed what you ship. It also changed what you have to secure.

Two years ago, your teams shipped software. Today they ship two different things. They ship software that AI mostly wrote. And they ship AI systems they built themselves: models, agents, features that reason and act. Most security programs are still scoped for the first and blind to the second.

That gap is not a tooling problem. It is a category problem. And the way the industry is drawing the categories is making it worse.

The market is slicing the problem the wrong way

Open any vendor page, and AI security is organized by where the AI lives. AI in the editor. AI in the pipeline. AI in the model layer. AI in the SOC. Each slice gets its own product, its own acronym, its own pitch.

The trouble is that AI now lives everywhere. When the organizing principle is location, and the thing you are organizing is in every location, the categories overlap and the tools end up arguing over the same surface. It looks like coverage. It is actually confusion. A buyer cannot tell where one product ends and the next begins, because the line was drawn around the technology instead of around the risk.

There is a cleaner cut.

Stop asking where the AI is. Ask what you are protecting.

Reframe the question around the object of protection, and the noise collapses into two answers. Only two.

You are protecting the software you ship. And you are protecting the AI you build. Different objects, different failure modes, different buyers inside the same company, and one independent layer over both.

Object one: the software you ship (including AI-generated code)

AI writes a growing share of it now. The risk, though, is still the application. A vulnerability is a vulnerability whether a human typed it or a model generated it. Exploitable code, unsafe dependencies, license exposure, architectural weakness: the risk class has not changed. What changed is the volume and the speed.

The numbers are striking: by mid-2025, AI-generated code was adding more than 10,000 new security findings per month across the repositories studied, a 10x increase from just six months earlier. CVSS 7.0+ vulnerabilities appeared 2.5x more often in AI-generated code than in human-written code. AI didn’t invent a new kind of flaw. It industrialized the old kind.

This is application security, scaled to the agentic era, and the two arguments from the earlier pieces in this series apply directly. The system that wrote the code cannot be trusted to certify it, so verification has to come from a layer the generator does not own. And that verification has to run continuously across the entire estate, not just last week’s AI-written commits, because most enterprise risk lives in years of accumulated code that no single model wrote and no single team still owns.

This object is well understood. The market has a name for it. What is new is the pressure AI puts on it.

Object two: securing the AI you build

The second object is new, and most security programs have no coverage for it at all.

Your teams are now shipping AI systems. A support agent with tool access. A model tuned on proprietary data. A feature that takes an instruction and acts on it. These are products in their own right, and scanning their source code tells you almost nothing about whether they are safe.

The failure modes are different in kind. Prompt injection, now ranked #1 on the OWASP Top 19 for LLM Applications, jailbreaks that bypass the system’s own guardrails, training-data and model poisoning, tool use that does something it should not, agents that behave perfectly in testing and break under adversarial pressure. You do not find these by reading the code. You find them by attacking the AI system itself, the way an adversary would, before the adversary does.

Indirect prompt injection attacks now account for over 55% of LLM attacks, with success rates ranging from 50% to 84% depending on model configuration. Only 24% of enterprises have a dedicated AI security governance team, meaning the vast majority of AI systems in production are being shipped without structured adversarial testing.

Independence bites harder here than anywhere. An AI system cannot red-team itself with any credibility, for the same reason it cannot grade its own output. The foundation-model lab cannot do it for you either, because it built the model, not your specific deployment, and it is not pointing its own offensive capability at your agent in your environment. The only trustworthy answer is adversarial testing from outside the system being tested.

Two objects, one independent security layer

The temptation is to treat these as two separate problems and buy two separate tools. That is the location mistake again, one level up.

They are not two products. They are one mission applied to two objects worth protecting. The independence argument is the same on both. The economics argument is the same on both. The reason a frontier model cannot be both the generator and the trusted auditor is the same reason it cannot be both the AI system and its own red team. What unifies the layer is not the technology it inspects. It is the stance: independent, neutral across whatever built the thing, and trusted precisely because it sits outside.

That is the whole point of an independent layer. It does not care who wrote the code or which lab trained the model. It verifies both, because verification is the job, and the job does not change with the tool that created the risk.

The bottom line

AI changed what your teams ship. It changed what you have to secure right behind it. The companies that stay clear-headed about this will not be the ones with the most AI-flavored products. They will be the ones that can answer a simple question without flinching: what are we actually protecting, and who do we trust to verify it?

Two answers. We secure the software you ship. And we secure the AI you build. One independent layer, over both.

The next pieces in this series get specific about how.