Two security stacks, one application layer. The split is false.

Most enterprises are now funding two security programs to watch the same running processes.

On one side, the application security tools you already own: static analysis, dependency scanning, secrets detection, container scanning, posture management, application detection and response. On the other, the set you are being asked to add: AI posture management, AI bills of materials, agent inventory, model governance, AI gateways, AI red teaming.

Two budgets. Two vendor lists. Two review processes. Often two teams, reporting to the same CISO, answering overlapping questions about the same workloads.

I argued in Forbes that this split is false. Not inefficient. False. It describes how the market sells, not how the technology divides.

The split was drawn along procurement lines, not technical ones

An agent is a process running in the same memory as the code around it, under the same identity, in the same network position, with the same blast radius. Take one apart and you find application security objects wearing new names.

The tools an agent invokes are functions in a repository or capabilities inside a framework. A model binding is an application connecting to a model. A guardrail is a rule about what is permitted. A workflow is a sequence of steps. Every one of these is a thing security teams have asked the same three questions about for a decade: is it present, is it reachable, and who owns it.

The split does not survive contact with the runtime. It was not drawn where the technology divides. It was drawn where the purchase orders divide.

That matters because fragmentation has a cost the industry already paid once. Application security spent a decade untangling itself from a tool-per-problem sprawl that produced more findings and less clarity. The AI security market is busy rebuilding that same shape, one category at a time, on top of the layer you already own.

A cancelled project is a budget event, not a runtime event

Gartner has predicted that more than 40% of agentic AI projects will be cancelled by the end of 2027. Treat that as the interesting number it is, rather than a reason to wait.

Cancellation removes funding. It does not remove code. The orchestrator stays embedded in the service it was added to. The tool registry stays connected. Credentials keep working. Model bindings keep resolving. Pulling a deprecated capability out of a running application is engineering work, and a cancelled project is precisely the one with no engineer left to do it.

So the governance programme inventories the AI that was announced, while the AI that was abandoned keeps running with no owner, no review date and no renewal conversation that would surface it.

A separate AI governance stack makes this worse rather than better, because most of those tools track what was registered. The risk lives in what was deployed and then forgotten. A stalled agent programme does not reduce the problem. It moves the problem from the roadmap to the runtime, which is the harder place to find it.

One layer means one set of evidence

If AI and the rest of the application run in the same process, then the honest inventory comes from the same place. This is the part that makes the argument more than a slogan, so it is worth being concrete about the mechanism.

Reading what is actually loaded in a running workload answers both sets of questions at once. Which packages and functions are loaded. Which agents exist, and which have never executed. What tools those agents can reach. Whether a model is served locally and therefore never crosses the boundary an AI gateway is watching. Whether a safety filter visible in a vendor console is present in the running process at all.

One read. One mechanism. The same runtime intelligence that tells you a vulnerable function in a dependency never executes also tells you an agent is wired to a tool nobody reviewed. It is not that Kodem does AI security in addition to application security. It is that the evidence does not distinguish between them, because the process does not either.

Worth stating the limit plainly, since a claim this broad invites the question. This replaces AI posture and inventory tooling, the dependency and code scanners, and the posture layer above them. It does not replace an AI gateway, and it is not red teaming. Those are different jobs at different points in the stack.

The question to carry into every vendor conversation is simple. Do the AI answers and the application security answers come from the same observation, or will someone on your team be reconciling two systems that disagree, in a spreadsheet, at quarter end?

The organizing question was never whether something is AI

Underneath all of this sits a question that has not changed in ten years. What is loaded, what can it reach, and can you prove the answer rather than assert it?

That question predates agents and will outlive whatever the category is called in three years. It is the question behind agentic AI security, behind reachability, behind every inventory an auditor has ever asked for. Teams that treat AI as a separate category keep rediscovering components after an incident, because the thing that found the component was the incident.

The organisations that come out of the next few years well will stop sorting their environment by whether something is AI, and start sorting it by whether they can see it run. Two companion pieces go deeper on what that looks like in practice: why a guardrail you cannot verify is only an attestation, and how ordinary delegation between agents becomes unauthorized access. For the full map, our researcher's guide to AI application security covers the stack end to end.

You do not have two security problems. You have one application layer, and two invoices.

Frequently Asked Questions