Drata Used to Help You Prove the Control Existed. Now It Wants to Enforce It Before the Agent Acts.

Drata's business, since it was founded, has been a specific and fairly narrow promise: point Drata at your systems, and when an auditor asks whether a control exists, Drata can show them evidence that it does. That evidence has always been retrospective by design. A screenshot, a log line, a signed off ticket, all pointing backward at something that already happened, collected continuously so nobody has to scramble for it the week before a SOC 2 audit.

On 4 August 2026, Drata opened Limited Availability of a product that does not fit that description. AI Agent Governance, and specifically the component Drata calls Mission Control, claims to sit between an agent and the action it is about to take, and decide, before that action executes, whether it is allowed to happen at all. I want to be precise about why that is the part of this announcement worth reading closely, because the headline version of this story, a compliance vendor adds an AI feature, tells you almost nothing.

What Drata says it built

Drata's own material describes AI Agent Governance as three components working together. A Sensor sits inline with the AI platforms an organization uses and registers each agent at the moment it is created, mapping it to an owner, an identity, its permissions and its scope. An MCP Proxy sits at the point every agent tool call actually passes through and evaluates each request against policy. Telemetry from that activity is reduced and masked on the device before it flows into what Drata calls a tamper evident evidence feed.

The component doing the enforcement work is Mission Control, which Drata's material also refers to as Inline Enforcement. The claim, in Drata's own language, is specific enough to be checked rather than merely admired: Mission Control evaluates every agent action against approved policy in real time and blocks violations inline, before they execute any action. Drata's own comparison for this is a fire suppression system that intervenes before damage happens, set against what it describes as the smoke detector model of most existing monitoring, which watches an agent, sounds an alarm once the action has already run, and depends on someone hearing it in time to matter.

Why the execution boundary is the part that caught my attention

Moona Intelligence has read this same architectural distinction before, from companies that do not compete with each other and do not appear to be coordinating. Fortinet's acquisition of Virtue AI bought a product built around blocking a malicious tool call before it fires, sold into security teams. Rubrik's Agent Identity mints a scoped credential only after a specific tool call has already cleared policy, sold into data protection teams. Guidelight's independent assessment of frontier AI developers draws a hard line between monitoring that happens after an action has already run and monitoring that evaluates a proposed action before it executes and can stop it, aimed at AI safety practice.

Drata is none of those things. It is a GRC platform, sold to compliance and security teams whose job has historically been proving what already happened, not deciding what happens next. When a vendor from that specific corner of the market describes its new product with the same architecture, evaluate before execution, block if it fails, that is a different kind of evidence than one more security company doing what security companies do. It suggests the execution boundary is not a feature one product category invented. It is a shape the problem itself is imposing on whoever tries to govern agents seriously, regardless of which market they walked in from.

Monitoring is not enough once the agent can act

Guidelight's Control standard names the distinction precisely: asynchronous monitoring scans activity after it happens and can flag a problem but cannot undo it, while what Guidelight calls semi synchronous monitoring evaluates a proposed action before it runs and can block it. Drata's own framing lands on the same side of that line, in its own words: a monitoring tool that watches and alarms after the fact is a smoke detector. A system that intervenes before the action completes is something else.

That distinction matters more for a compliance platform than it might for a security product, because compliance tooling has spent decades built almost entirely on the after the fact side of that line. An access review runs quarterly. An audit sample checks a period that already closed. A control test confirms a policy was followed, once the period is over. None of that architecture assumes it can stop the thing it is checking. It assumes the thing already happened and its job is to document it accurately. An agent that can act in seconds does not leave room for a quarterly review to matter before the consequence exists. If Drata's own read of its market is correct, and enough of the surrounding evidence in this ledger points the same direction that I take the read seriously, compliance tooling built entirely on the retrospective model has a real problem with autonomous agents, independent of anything Drata specifically ships to answer it.

Governance moving into the execution path is the actual story

Set Drata's specific product aside for a moment and look at what the move itself represents. A company whose entire prior product surface was evidence collection, the Trust Graph, the audit workflows, the framework mappings, has now built a component that sits inline with an agent's own tool calls and makes an allow or deny decision on each one, using policy the customer wrote. That is a categorically different kind of software than anything in Drata's product history before this. Evidence collection can be wrong and nothing breaks except a future audit finding. A policy engine that blocks a tool call sits directly between the agent and whatever it was trying to do, and a mistake in either direction, blocking something legitimate or missing something dangerous, has an immediate operational consequence.

Drata is not choosing to carry that risk for no reason. Compliance vendors do not usually volunteer for operational blast radius. The more plausible reading is that Drata's customers were already telling it that evidence of what an agent did, produced after the fact, was no longer the thing they needed most. They needed to know, before an agent with real system access did something, whether it was allowed to.

Why identity and authority are becoming the same question

The part of Drata's architecture that connects most directly to evidence already in this ledger is the Sensor's registration step: mapping every agent, at the moment it is created, to an owner, an identity, its permissions and its scope. That is the same move Rubrik documents with Agent Identity, minting scoped access tied to a specific call rather than a standing grant, and the same question DataHub's approval gate raises about who controls the setting that decides whether an approval requirement applies at all. None of these companies compete with each other, and none of their architectures are identical. What they share is a premise: an authorization decision cannot be made sensibly without first answering who, or what, is asking. Mission Control's policy evaluation is only as meaningful as the identity, permissions and scope the Sensor attached to that agent in the first place, which is presumably why Drata built the two together rather than shipping enforcement on top of an unidentified actor.

What Drata's own market data actually shows, and does not

Three weeks before the Limited Availability launch, Drata published research it commissioned from Wakefield Research, surveying 300 United States IT and security professionals at companies of 1,000 to 20,000 employees, fielded in March 2026. The headline figures: 13 percent said they were fully confident they had complete visibility into the AI tools running inside their organization, leaving 87 percent without that confidence. 71 percent said an AI tool used for governance, risk or compliance work had contributed to a failed audit or a lapsed regulatory standard at least once.

I want to be exact about what that survey does and does not support, because it would be easy to read it as evidence for the Mission Control launch and it is not that. It measures visibility into AI tooling broadly and its history of contributing to audit failures. It says nothing about whether organizations want inline blocking specifically, whether they trust a policy engine to make that call correctly, or whether an approval workflow versus an automated block is the preferred design. It is also research Drata commissioned and published about the problem its own new product is positioned to solve, which is a normal thing for a vendor to do ahead of a launch and a real reason to read the numbers as evidence of a category Drata wants to exist rather than as neutral proof the market has already decided how to solve it. The genuinely useful fact underneath the marketing is narrower and still worth having: a meaningful share of the compliance professionals Wakefield surveyed say they cannot see what AI is doing inside their own organization, and that gap has already cost some of them an audit finding. That is evidence the visibility problem is real. It is not evidence that Drata's specific answer to it is the one the market will choose.

What changed for me, and what did not

Here is where I want to separate three different things rather than let them blur into one conclusion, because that blurring is exactly the failure mode this kind of announcement invites.

Moona Intelligence's own flagship reading of this market has argued that you cannot prompt your way out of agent authority, that instructions given to a model are not the same thing as authority checked at the moment an action runs. The fact in front of me is narrow: Drata says Mission Control evaluates an agent's action against policy and blocks it before execution if it violates that policy, and describes early access customers running this against Anthropic agents in production. That is Drata's own account, not something an auditor, a customer or Moona Intelligence has independently confirmed by watching it stop a real violation. Vendor demonstrations of access control mechanisms elsewhere in this ledger, including Rubrik's own worked example, have consistently turned out to be exactly that: illustrations of an intended design, not proof of behavior under adversarial pressure at scale.

The inference is broader and, I think, defensible: a compliance vendor building this specific architecture, evaluate before execution, block on failure, independently of the security vendors already doing the same thing, is evidence that the execution boundary is not one market's idea. It is where the problem is pushing anyone who tries to govern an agent seriously, regardless of which door they walked in through.

The thesis question is the one I want to be most careful about. One vendor's claim that it moved a control inline does not establish that inline enforcement is the winning architecture for this market, and I am not asserting that it does. What it does is add one more independent data point, from an adjacent market, to a pattern this ledger has already been tracking from security vendors and infrastructure providers. A pattern with a new, unrelated contributor is a stronger pattern than the same pattern with one more example from the same corner of the market. It is still not proof of an outcome.

My read by control surface

Moona Intelligence tracks a small set of control surfaces across every record in this ledger. Here is how I read this specific piece of evidence against each of the ones it touches, and I want to be equally clear about the one it does not.

What I would watch next

Whether coverage actually reaches OpenAI, Google Vertex AI and AWS Bedrock on the timeline Drata implies, since a control plane that only governs one model provider is a narrower claim than the framing around it suggests. Whether any customer, auditor or third party publishes an account of Mission Control blocking a real policy violation in production, rather than a vendor demonstration. Whether Drata or anyone else extends this kind of policy evaluation from a single action to several actions considered together. And whether other compliance and GRC vendors, the market Drata actually competes in, make the same move toward inline enforcement, which would be the independent convergence this ledger looks for before calling anything a market consensus rather than one company's roadmap.

What would change my mind

A documented case, from a customer or an independent party rather than from Drata, of Mission Control correctly blocking a genuine policy violation under real conditions would move the execution authority read from a vendor claim toward verified behavior. Evidence that the block can be bypassed by an agent retrying with a slightly different action, a limitation Guidelight's own standard names honestly as a real weakness of blocking architectures generally, would narrow the claim in the other direction. And if Drata's own coverage stalls at Anthropic only for an extended period, that would be worth reading as evidence that inline enforcement across multiple model providers is harder to generalize than the announcement implies.