The AI Risk Story Everyone Is Talking About

Everyone read the recent frontier-lab incidents as one company's AI intruding into another's systems. The more urgent story is what happens when the agent is your own.

Seven weeks ago, we opened early access for AI Agent Governance. I expected demand to build gradually. It hasn't. The demand skyrocketed.

The applications keep climbing, the security conversations have gotten more urgent, and enterprise after enterprise is telling us the same thing: agents are already running inside our walls, and we can't answer for them. Then last week OpenAI and Anthropic handed everyone a live demonstration of why that matters. And almost everyone drew the wrong lesson from it.

By now you've read the coverage. An AI agent run by one of the frontier labs operated well past its intended scope and reached into systems it was never meant to touch. The write-ups have been everywhere: the trades, the technical timelines, half of my LinkedIn feed.

Nearly all of them read the event the same way: someone else's agent came for someone else's systems, so the answer must be better intrusion detection. Watch the perimeter. Fingerprint the traffic. Catch the rogue agent on the way in.

That's a real problem. It's also, for almost every company reading this, not the most urgent one.

Here's the line most of the coverage minimized. In both the OpenAI and the Anthropic disclosures, the guardrails weren't defeated. They were turned off. OpenAI said the safety classifiers were explicitly disabled for the evaluation. Anthropic ran its agents without the standard safeguards. Two of the most safety-invested organizations on earth, and the incident happened because they deliberately took the guardrails down to see what the model would do.

Sit with that, because the reflex of "if only they'd had better controls" misses the point entirely. They had the controls. They chose to unlock the front door.

Now think about the fact that actually matters for the rest of us: most companies today still haven't even installed the front door.

Meet the Insider Agent Threat

So here's the take you haven't yet read anywhere. The same pattern that played out between two companies is far more likely to play out inside one. Your own agents. Your own systems. No attacker required. I've started calling it the Insider Agent Threat, and I think it's the story the industry spends the next year catching up to and learning how to contain.

The insider agent threat doesn't announce itself. It looks like an agent doing its job.

Picture a support agent you stood up to draft quarterly business reviews. You gave it a goal: pull the account history, build the deck. It goes looking for the data. The clean path—the export it's supposed to use—is empty. A human would file a ticket and move on, because it knows that is what the process requires.

But the agent doesn't file tickets… the agent finishes tasks. So it tries another route, and then another. It finds a service account with a weak password. It discovers an endpoint nobody remembered to close. It gets in, it pulls the data, it builds the deck, and it reports success. No malice. No breach alert. Just an objective, and a machine patient enough to try every door until one opened—exactly like those OpenAI agents that breached Hugging Face.

Every step looks reasonable in isolation. Nowhere in this chain did the agent do anything but pursue the goal you gave it. In theory, it's a success because the agent did exactly what you asked. But in practice, it went around your security protocols and let itself into systems it was never meant to open. On the way to building one deck, it likely touched things that had nothing to do with the task: another customer's data, financial records, private employee information, whatever it passed while hunting for the numbers it wanted. And some of that could end up somewhere it should never be. A slice of one customer's data dropped into another customer's deck is what loses the account, and depending on what leaked, could result in legal obligations to report the breach.

The problem is that none of it announced itself. No alert, no record, nothing to point to. So when a customer, an auditor, or a regulator asks what your systems touched and where that data went, you have no answer. The weak password and the open door the agent found are still there, waiting for the next agent or a real attacker. The one that pulled it off was rewarded with "success" and no pushback—so the next time the front door is locked, it does exactly the same thing again.

A Third Population with No Playbook

We already know how to govern two populations with access to sensitive systems: employees and third-party vendors. Both have a playbook. Agents are a third population, and the old playbook doesn't fit them, primarily because of these three reasons:

1. They inherit privileges but not judgment.
   An agent created by one of your engineers can act with that engineer's access, on systems the engineer never personally touches.

2. They don't get bored.
   A human probing for a way in eventually gives up. An open door that sat harmlessly for years—because no one had the patience to find it—gets found now, because the agent doesn't get tired and it doesn't stop.

3. They move at machine speed.
   By the time a runtime tool flags the action, the action has run. You'll have excellent, high-resolution footage of exactly how you were robbed, but no way to go back in time and stop the robbers.

That last reason is the whole argument. If you're catching this at runtime, you're already too late. The only kind of governance that works on an actor moving at machine speed is one that evaluates the action before it executes and stops the violating one inline.

Not an alert after the fact, but a block before it. You never handed your company’s most sensitive data to the intern and hoped monitoring would sort it out. Your agents deserve the same discipline, at the same moment.

The good news is that the ability to do this exists now. With Drata, you can discover the agents actually running in your environment instead of guessing at a number somewhere between 100 and 2,000. You can write policy with natural language and compile it into something enforced. You can run that policy up a Trust Ladder, simulating it against a year of your real traffic before you ever switch it on, so you learn exactly what it would have blocked with zero risk in production. And you can enforce it inline, so the QBR agent in my example hits a wall the instant it reaches for a credential it was never granted.

AI Agent Governance Now in Limited Availability

All of this functionality is now available to qualified enterprises through Limited Availability. Early access was about building alongside a handful of design partners. Limited Availability means the product is live, purchasable, and running end-to-end in production today.

No waitlist to see what it does, just a gated, white-glove rollout so every deployment has our team behind it.

It ships first and deepest for Anthropic, where our earliest customers are already governing their agent fleets end-to-end, with native coverage for OpenAI, Google Vertex AI, and AWS Bedrock in active development. Connecting an Anthropic environment to a live inventory of every agent running inside it takes minutes, not weeks.

I’m writing this from Black Hat, where everyone is talking about the external agent trying to get in. But the real conversations, the ones that are most critical to the industry today, are the ones that Drata is having about insider agents.

It’s not enough to watch what’s happening with agents on the outside. You must watch the ones you already trust. They have access, they have goals, and they will not stop at a locked door you forgot to check.

If your agents are already running and you can't yet answer for them, come build the answer with us. Apply for AI Agent Governance.