Aviv Mussinger is CEO & co-founder of Kodem, building application security on runtime truth: what actually runs, not what looks risky.
Most enterprises I speak with are now funding two security programs for one set of running processes.
On one side sits the application security stack they already own: static analysis, dependency scanning, secrets detection, container scanning, posture management, and application detection and response. On the other sits a list they are being asked to add this year: AI posture management, AI bills of materials, agent inventory, model governance, AI gateways and AI red teaming.
Two budgets, two vendor lists, two review processes and often two teams reporting to the same CISO, answering different halves of the same question.
Application security spent a decade consolidating exactly this kind of fragmentation. We are rebuilding it in about 24 months, and this time we are calling it progress.
The split was drawn along a procurement boundary, not a technical one.
An agent is not an external system that arrived from somewhere else. It is a process. It runs in the same memory as the code around it, under the same identity, in the same network position and with the same blast radius.
Look at what an agent is actually made of. A tool it can invoke is a function in someone’s repository, or a capability that shipped inside a framework nobody at the company wrote, or a connection opened at runtime that no code review ever saw. A model binding is the connection between an application and the model it uses. A guardrail is a rule that controls what the application or model is allowed to do. A workflow is simply the sequence of steps the application follows.
Every one of those is an application security object with a newer name. The properties security teams care about are unchanged: what is present, what it can reach, whether it is reachable itself and who owns it.
That is why 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.
Cancellation is a budget event, not a runtime event.
Gartner expects more than 40% of agentic AI projects to be canceled by the end of 2027. Most people read that as a reason to slow down on AI. I read it as an inventory problem that almost nobody is planning for.
Consider what actually happens when one of these projects is canceled. Funding stops. The team gets reassigned. The road map slide comes down. The launch blog post gets quietly unpublished.
Here is what does not happen. The orchestrator does not get removed from the service it was embedded in. The tool registry does not get unwired. The credential does not get revoked. The model binding does not disappear from the process. Deprecating a capability is engineering work, and engineering work is exactly what a canceled project no longer has anyone to do.
So the governance program gets built around the AI that was announced, while a meaningful share of the AI still loaded in production is the part that was abandoned. It has no owner, no review, no renewal date and no line in the inventory.
A separate AI governance stack makes this worse rather than better, because most of these tools inventory what somebody registered: a connector that was configured, a platform that was onboarded or a model that went through an approval. A dead project registers nothing. It just keeps running.
This is the pattern I keep running into. The AI components that are hardest for a team to account for are almost never the flagship ones. They are the ones that were wired in, never fired and forgotten.
One layer means one set of evidence.
If the AI and the application run in the same process, then the honest inventory comes from the same place for both.
Reading what is actually loaded in a running workload answers both the application security and AI questions at once: which packages are loaded and which functions have run, which agents exist and which have never fired, what tools they can reach, which model is bound and whether it is served locally (where no gateway will ever see it), and whether the safety filter that appears in the vendor console is actually present in the process.
That is one mechanism, not two. And it is the test worth applying to every vendor conversation this year. Ask whether the AI answer and the application security answer come from the same observation, or whether they come from two systems that a person then has to reconcile in a spreadsheet. A single reconciled inventory is a deliverable. Two inventories that disagree is a project.
None of this means the new tools have no job. A gateway does real work at the boundary, and adversarial testing finds things no inventory will. The argument is narrower and, I think, harder to dodge: The layer where agents actually run is a layer most enterprises already own, already staff and already pay to secure.
The organizing question was never ‘Is it AI?’
The useful question has not changed in a decade. 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 we are calling this in three years. Teams that treat AI as a new category will keep buying a second stack, a second console and a second reconciliation problem, and will keep discovering the components nobody registered after something has already gone wrong.
The teams that I believe will handle the next wave well are the ones that stop sorting their environment by whether something is AI and start sorting it by whether they can see it run.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?