I have spent a lot of my career opening systems I was told were working fine.

The pattern repeats. Someone hands you the documentation, describes the intended behavior, and points to a clean report. Then you look at the raw activity underneath, and the real story diverges sharply from the paper version.

That gap between what a system is supposed to do and what it actually does is where most security failures live. Right now, that gap has a new occupant: the AI agents running inside your environment with credentials you gave them.

This Looks Like Log4j, and That Comparison Is Earned

When Log4Shell hit, the crisis was not that a vulnerability existed. The crisis was that organizations could not see where the vulnerable component lived. You cannot patch what you cannot locate.

The numbers made that plain. Long after fixes were available, 72 percent of organizations remained vulnerable, and one federal cabinet department burned 33,000 hours on response alone. The tooling could not answer a basic question about the organization's own footprint.

We are watching the same visibility failure repeat with AI, and the scale matches. AI-related attacks climbed nearly 490 percent year over year while AI spread across thousands of SaaS applications, frequently without clear ownership or control.

The difference this time is important. The asset with authorized access is autonomous, and it moves faster than any human operator you have ever tried to track.

The Threat Isn't a Break-In

Most of the security industry is still framing AI risk as an intrusion story. That framing points you at the wrong door.

The AI is not forcing entry. It walks through the front with a valid badge and reaches whatever the systems it connects to allow it to reach. AI tools inherit the access of the applications they plug into, often without restriction.

That inheritance is where the damage lives. Around 80 percent of AI-related incidents involve regulated or sensitive data. The most significant risks come from data exposure, OAuth abuse, shadow AI, and non-human identity sprawl. Those are access problems. They have very little to do with the model itself.

💡 If you follow the access instead of the intent, the AI security problem stops looking like a new category of threat and starts looking like a very old one nobody funded the tooling to solve.

Why "Not Exploitable" Stopped Being Enough

For years, the working definition of a secure system was a system that could not be exploited. Pass the scan, close the known holes, and the report looks clean.

That definition was always a convenient metric. It counted the thing that was cheap to measure. It quietly stopped counting the thing that actually matters, which is what your authorized systems reach when they operate exactly as designed.

This is the same blind spot that makes insider activity so hard to catch. An insider uses authorized access to perform tasks inside the scope of their job. Accessing critical systems, viewing sensitive files, moving data, all of it appears legitimate in the logs. Without context, the security team has nothing suspicious to flag until the damage is done.

An AI agent behaves the exact same way. Authorized access that looks legitimate at the authentication layer, doing something that could be catastrophic at the application layer.

⚠️ "Not exploitable" does not describe your real threat surface anymore. A system can be perfectly hardened against intrusion and still hand a capable agent everything it needs to cause harm.

The Blind Spot Predates AI

None of this started with AI. The telemetry gap was already there.

Consider that 72 percent of organizations lack full visibility into how their own employees interact with sensitive data. Only 28 percent report effective data classification and discovery. Half describe their data protection tooling as fragmented.

If you cannot see what your humans are reaching, you have no chance of seeing what your AI agents are reaching. AI did not create the exposure. It inherited it, then made it catastrophic by operating at machine speed and machine scale.

This Is a Data Engineering Failure, Not a Policy Failure

Here is where I part ways with most of the conversation.

The dominant response to AI risk is governance. Write access rules. Build approval workflows. Publish a responsible-use policy. Those documents describe what should happen.

They observe nothing. Policy is a description of intent. It has no ability to record what an agent actually reached at 2 a.m. when it operated with legitimate credentials and the workflow looked normal.

The real question your security program has to answer is narrow and concrete. What was accessed, how was it accessed, by whom, and from where. When an agent operates with valid credentials, a faithful trace of what it reached and how is the only meaningful evidence you have.

Producing that trace is a data-capture problem. You need application-level telemetry. You need OpenTelemetry injection at the layer where intent and reach actually happen. You need tracing data that records the questions asked of your systems and the specific records those questions touched.

Your existing monitoring stack was never architected to do this. It was built to watch authentication and network events, not to capture intent and reach at the application layer across thousands of agents. Asking it to trace AI behavior at scale is asking it a question it was never designed to answer.

What Actually Fixes This

The work is not glamorous, and I would be suspicious of anyone who tells you it is. This is well-understood engineering that nobody wanted to pay for until the bill came due.

The path forward has a clear shape:

• Instrument the application layer. Capture what questions get asked of your systems and which records those questions touch. That is the layer where authorized reach turns into real exposure.
• Inject tracing where agents operate. OpenTelemetry gives you a vendor-neutral way to record intent and reach without betting your visibility on a single stack you will outgrow.
• Build for trace-scale capture. Autonomous agents generate volume no human-oriented monitoring stack was sized for. Treat the pipeline as a data engineering problem with real throughput requirements, not a logging afterthought.
• Stop discarding evidence upstream. Valuable telemetry gets filtered out early for cost reasons, and its absence gets noticed at the exact moment it was needed. Decide what you keep before an incident forces the question.

I have watched teams throw away the exact records that would have told the whole story, discarded upstream to save on storage, and then feel that absence precisely when an investigation needed them. That loss is preventable. It is a design decision, made ahead of time, about what your systems record.

The Uncomfortable Part

A 2026 enterprise survey found that 88 percent of organizations experienced a confirmed or suspected AI agent security incident in the prior year.

Most organizations have already been touched. They do not know the details, because they never built the instrumentation to record them. The event happened, the agent used its badge, and there is no trace to reconstruct what it reached.

That is the real position most security teams are in. Not exposed to some future threat, but already operating blind to something that has already occurred.

Log4j taught us that visibility into your own footprint is the whole game. The organizations that could not see where the component lived could not defend it.

The AI in your environment has a valid badge. The only thing that tells you where it walked is instrumentation you have to build now, at the application layer, before the next investigation asks a question your stack was never designed to answer.