I once spent three hours comparing the prices of two identical high-performance blender models across fourteen different tabs, only to realize I was comparing a listing with a spec sheet that looked exactly the same but had a completely different motor housing.
I felt brilliant for finding a thirty-dollar price gap until I realized I was looking at two different realities masquerading as the same product. It was a classic obsession with the sticker instead of the substance. I see this same hallucination happening in enterprise AI right now, but instead of thirty dollars, the stakes are the entire risk profile of the organization.
The Illusion of Authoritative Approval
Priya has the November assessment open on one monitor and the change log on the other. The assessment runs thirty-one pages and carries three signatures from people who likely haven’t spoken to each other since the holiday party. It is a beautiful document. It has charts. It has a “Low Risk” stamp that looks authoritative and final. On the other screen, the change log shows one hundred and forty-six entries since those signatures were dry.
The decay of relevance: Three signatures carry no weight against 146 undocumented system updates.
She is scrolling for the specific entry that would invalidate the approval, aware that if she finds it-and she will-she has to walk into a Thursday meeting and tell six people that the thing they approved no longer exists in the form they approved.
The “Low Risk” stamp was for a version of the agent that didn’t have access to the customer’s internal knowledge base. Entry sixty-four changed that. Entry eighty-two added a tool for direct database querying. Entry one hundred and nine updated the system prompt to be “more helpful,” which in the world of LLMs is often code for “more likely to ignore previous safety constraints.”
The Chimney Problem
The whole industry is currently reviewing AI on a calendar the software stopped respecting years ago. We are applying the rhythms of the physical world-where a chimney needs an inspection once a year because bricks and soot move slowly-to a digital entity that can undergo a total personality transplant during a coffee break.
“A chimney doesn’t just spontaneously decide to be dangerous on a Tuesday. The mortar erodes at a predictable rate; the creosote builds up over a specific number of fires.”
– Laura Y., Chimney Inspector
An annual check works because the object being checked is governed by the laws of physics and slow decay. You can certify a chimney for a season because the chimney cannot download a new update that suddenly makes it combustible in a way it wasn’t on Monday.
Software used to be a bit like Laura’s chimneys. We had release cycles. We had “Gold Master” disks. We had version numbers that stayed static for . When an auditor looked at a system in March, they were reasonably certain the system would be the same in September. If there was a patch, it was a documented event. But AI agents aren’t static builds; they are living, breathing loops of instructions, model weights, and tool access.
The failure isn’t that we are slow; it’s that we treat a review as an event at all. An assessment answers the question “did this behave acceptably on the day we looked?” It gets filed, and is then read for the rest of the year as if it had answered “what will this do?” We have inherited an annual cadence not out of technical necessity, but out of bureaucratic convenience. We check on a schedule that suits the checker, then behave as though the finding holds until the next visit.
The Simulation of Safety
It’s a dangerous form of comfort. We passed the review in March. By April, the model version changed from a stable release to a “preview” build. By May, two new tools were added to the agent’s belt. The system prompt was edited four times by a well-meaning developer trying to reduce latency. Yet, nobody wants to reopen the review. Reopening the review means going back to the end of a queue that took the first time.
So the organization moves forward, clutching the March document like a talisman against a disaster that the document no longer covers. It is a simulation of safety. We are essentially running a high-speed train on tracks that were inspected when they were still a horse-drawn path, pretending the speed hasn’t changed the physics of the turn.
If you look at the way CompFly AI approaches this, you start to see the alternative. They don’t treat the assessment as a finish line. They treat it as a baseline that must be constantly defended.
In an environment where an agent’s “Autonomy Envelope” can be breached by a single paragraph of new instructions, you can’t rely on a signature from four months ago. You need a system that notices the change in real-time, tests it against the original safety boundaries, and creates a new trail of evidence before the agent is allowed to execute its next task.
This is the shift from “Trust, but Verify” to
“Verify, then Allow, Constantly.”
Instantaneous Decay
When we talk about “legacy debt,” we usually mean old code that is hard to maintain. But the most expensive legacy debt in the age of AI is the legacy mindset of the periodic audit. Every day that passes after an assessment is signed, the “truth” of that document decays.
In traditional software, that decay was slow-a few security patches, maybe a minor feature update. In agentic AI, the decay is nearly instantaneous. The moment the agent interacts with a new data source or receives a refined prompt, the old assessment is effectively a work of historical fiction.
I keep thinking about those two blenders. I was so focused on the model number that I ignored the fact that the internal components had been swapped out. Organizations are doing the same with their AI pilots. They look at the name of the project-“The Customer Support Agent”-and assume that because the name is the same as it was in the March audit, the risks are the same too.
But “The Customer Support Agent” is now a different creature. It has more power, more data, and less supervision than the version that was approved.
The Cost of Futility
The cost of this isn’t just the risk of a headline-grabbing failure. The cost is the paralysis of the entire enterprise. Because everyone knows, deep down, that the March document is a lie, the people in charge of risk become more and more conservative. They slow down the approvals even further, thinking that a more “thorough” eleven-week review will somehow compensate for the fact that the review will be obsolete in twelve weeks.
It is a feedback loop of futility. We spend more time certifying the snapshot because we are afraid of the motion.
We need to stop asking if the agent was safe on Tuesday. We need to start building the infrastructure that asks if the agent is safe now, at , given the specific tool it is about to call and the specific data it just ingested. This isn’t just a technical challenge; it’s a cultural one. It requires admitting that our spreadsheets and our annual “Low Risk” stamps are no longer the source of truth.
A static collection of past approvals.
Real-time controls for current risks.
The truth is in the trace. The truth is in the live observability of the intent and the identity of the agent. If we can’t prove what the agent is doing at this exact moment, then the approval we got six months ago isn’t an asset; it’s a liability. It’s a false sense of security that prevents us from building the actual controls we need to let these agents run wild.
Priya finally finds the entry. It’s number ninety-two. A developer added a “temporary” bypass for a legacy authentication check to speed up testing and forgot to remove it. It’s been live for . She looks at the three signatures on the November assessment. They look like relics from a different century.
She closes the PDF, picks up her phone, and prepares to tell the committee that their “Low Risk” agent has been an open door for twenty-one days.
The meeting will be painful. There will be talk of “process failure” and “compliance gaps.” But the real failure isn’t Priya’s, and it isn’t the developer’s. It’s the belief that a piece of paper can ever be fast enough to catch a ghost in the machine.