Agentic AI Runtime Governance: What 132 Enterprise Leaders Say Breaks First
- VentureBeat's Pulse Research surveyed 132 technology leaders at organizations with 100+ employees in May 2026. The sample is small and the publisher labels it directional, but the distribution is consistent enough to be useful.
- Asked where agent failures originate, 47% named the integration and governance gap, 37% named fragile stateless infrastructure, and only 17% named the model itself. The reasoning layer is not the bottleneck.
- 77% of respondents lose meaningful sprint capacity to infrastructure plumbing rather than agent logic, with 24% spending more than half of it there.
- On security, four mechanisms sit at rough parity: policy-as-code gates 30%, deterministic data masking 25%, least-privilege non-human identity 23%, and egress-locked sandboxing 22%. No dominant pattern has emerged.
- The observability tax is unevenly distributed: 42% name Microsoft's stack as requiring the most custom instrumentation to see inside agent failures, versus 12% for Anthropic's.
- What the survey does not ask is the question that precedes all four security mechanisms: which agents, MCP servers, and skills are actually running on your endpoints right now.
The interesting claim in VentureBeat's latest Pulse Research is not that enterprise AI agents are failing. It is where they fail. Asked directly whether agent failures trace back to the model's reasoning or to the infrastructure around it, 47% of respondents named the integration and governance gap, 37% named fragile stateless infrastructure, and only 17% named the model. Agentic AI runtime governance, in other words, is the constraint - not model capability. The survey covers 132 technology leaders at organizations with 100 or more employees, fielded in May 2026, and VentureBeat labels the data directional rather than definitive. Read that way, it is a useful map of what enterprises are actually hitting once agents leave the pilot phase, and where the security architecture is still unsettled.
What the survey measured, and what to discount
Worth stating the limits before the findings, because they change how much weight each number carries. The qualified sample is 132 respondents, filtered to organizations with 100+ employees: 35% at 10,000+ employees, 48% in the 500 to 9,999 range, and 17% between 100 and 499. Industry mix skews toward technology and software at 42%, with financial services at 20% and the remainder spread across professional services, healthcare, retail, and education. Roles run from software and ML engineers through directors and VPs to CIOs, CTOs, and CISOs.
At that sample size, a three-point gap between two adjacent options means very little. What survives the noise is the overall shape, and the shape here is consistent across nine separate questions. That consistency is the finding. It also lines up with what we described in agentic AI trends for 2026 and the visibility gap and with the practitioner picture in the state of enterprise AI security 2026.
The failure point is the runtime, not the reasoning
VentureBeat frames the question as brain versus spine: does an agent fail because the model reasoned badly, or because the runtime could not hold state, survive a restart, and coordinate execution? The answers split three ways rather than two.
| Reported failure point | Share | What respondents describe |
|---|---|---|
| Integration and governance gap | 47% | No standardized connective tissue - MCP being the obvious candidate - for safely governing data access between agents and enterprise systems. |
| Fragile stateless infrastructure | 37% | Python scripts, chains, and ad hoc orchestration that cannot survive container restarts, deployments, or transient glitches. |
| The model itself | 17% | Reasoning reliability degrades once a workflow exceeds roughly ten steps, and edge cases are not handled dependably. |
One respondent, a director of engineering at a financial services firm in the 10,000 to 49,999 employee band, put the majority position plainly: the models are smart enough, and the stateless infrastructure around them is not. The 17% who disagree are not a rounding error either. They are reporting a real ceiling, and the mechanism they describe - errors early in a chain compounding rather than cancelling - is the same reason a single poisoned input has outsized consequences in indirect prompt injection.
The 47% figure is the one security teams should sit with. The governance gap is not a request for more model safety. It is a request for a control layer between agents and enterprise systems, which is exactly the problem MCP server security exists to describe and an MCP server registry exists to solve. Enterprises are telling the market they lack the connective tissue to govern data access, and MCP is currently the only serious candidate for standardizing it.
The plumbing tax, and why it is also a security finding
Asked what share of weekly engineering capacity goes to building and maintaining custom plumbing - retries, state persistence, checkpointing - rather than agent logic, respondents distributed almost evenly across four bands. 24% spend more than half their capacity there. 27% spend 25 to 50%. 26% spend 10 to 25%, roughly a day a week. Only 23% spend under 10%. Adding the first three, 77% are losing meaningful capacity to infrastructure overhead.
The security reading of that number is not the wasted engineering hours. It is what hand-rolled plumbing means for evidence. A team writing its own retry logic and state handling is also, implicitly, writing its own audit trail - and an audit trail that is a side effect of someone's retry wrapper is not one you can answer a regulator with. This is the gap the AI agent audit trail and logging guide is written against, and it is why how to audit AI agent activity treats the record as a designed artifact rather than a byproduct. VentureBeat also notes that the 23% in the efficient band are not necessarily more mature; some are on managed platforms, and some simply have not yet reached the scale where stateless architectures fail.
What actually kills deployments
The ranking of primary technical obstacles shifted from earlier waves, and the new leader is economic rather than technical.
| Obstacle | Share | Failure mode |
|---|---|---|
| ROI ceiling | 29% | Token costs and infrastructure overhead exceed the project's total business value, so the sponsor kills it. |
| Hallucination propagation | 24% | Logic drift in an early reasoning step compounds into total failure by step ten or twelve. |
| Ghost failures | 20% | Silent API timeouts and state loss where the agent hangs with no traceback. |
| State amnesia | 17% | Context lost to container restarts, deployments, or transient glitches. |
| Latency and SLA breaches | 10% | Correct reasoning that arrives too late to meet a time-to-resolve commitment. |
Ghost failures at 20% deserve an asterisk: a failure mode defined by being invisible is almost certainly under-reported, since respondents can only count the ones they eventually noticed. The same logic applies to security. An agent that quietly exfiltrated a token and produced a plausible answer looks like a success in every metric a team is currently collecting, which is the structural point behind the lethal trifecta of AI agent data exfiltration.
The observability tax is not evenly distributed
Asked which vendor ecosystem demands the most custom telemetry and logging glue to get basic visibility into agent failures, respondents named Microsoft at 42% - GitHub Copilot Workspaces and the Agent Framework - followed by OpenAI at 30% (Codex and the Agents SDK), Google at 16%, and Anthropic at 12% (Claude Code and the Claude Agent SDK). Red Hat's Brian Gracely, quoted from a VentureBeat event in March, described building a control system entirely inside one provider's toolset as renting a cage.
There is a confound worth naming: Microsoft has the largest enterprise deployment footprint, so it also accumulates the most practitioners with an opinion. But a 30-point spread is wider than footprint alone explains. The actionable version of this finding is narrow and useful - observability cost is a real budget line, and a platform that is cheaper per API call can be more expensive per unit of visibility. If Copilot is your dominant surface, the governance specifics are in governing GitHub Copilot in the enterprise and Microsoft Agent 365 and Entra Agent ID governance. For Codex the equivalent is rolling out OpenAI Codex with fleet governance, and for Claude Code it is deploying Claude Code across a fleet.
The deeper problem shows up two findings later. 39% of respondents describe their architecture as deliberately polyglot, spanning model-native reasoning for planning and deterministic rules engines for mission-critical execution. When your architecture spans multiple orchestration layers and multiple providers by design, no single vendor's telemetry can give you the full picture. Mass General Brigham CTO Nallan Sriraman's call for a unified observability layer for AI is, in that light, a structural requirement rather than a preference. Provider-native tooling cannot see across a provider boundary, which is precisely the argument for inventorying at the endpoint instead, as laid out in the AI discovery buyer's guide.
The security mesh is being built from first principles
This is the finding most relevant to security teams, and its headline is the absence of a headline. Asked how they protect proprietary data from AI leakage and prompt-driven exfiltration, respondents split four ways within an eight-point band.
| Mechanism | Share | What it answers | Where it runs |
|---|---|---|---|
| Policy-as-code governance gates | 30% | Regardless of what the model decided, what hard stops exist? | The orchestration or enforcement layer, overriding model intent |
| Deterministic data masking | 25% | What must never reach the inference context? | Middleware that redacts before the prompt is sent |
| Least-privilege non-human identity | 23% | Who is this agent and what may it touch? | Short-lived scoped identities per agent thread |
| Egress-locked sandboxing | 22% | If model-generated code runs, where can it reach? | Isolated containers with controlled outbound access |
Rough parity across four mechanisms is what an unsettled market looks like. Compare that to identity management or network policy in traditional IT, where the dominant pattern was decided years ago. Here, the AI security layer is being assembled from scratch, and every team is making its own architecture call. Two of these are philosophically distinct in a way worth being deliberate about: non-human identity is identity-centric, asking who the agent is and what it may reach, which is the subject of non-human identity governance. Policy-as-code is rule-centric, asking what stops exist regardless of intent, which is least privilege for AI agents expressed as enforcement. Most mature programs need both. A later wave of the same research shows what happens when teams pick only one: per-agent identity adoption jumped 17 points in a month while isolation stalled at 18%, which is the containment gap.
Egress-locked sandboxing at 22% is the number that moved fastest, and VentureBeat flags it as the newest of the four. That tracks. Sandboxing is the most technically demanding option, but it is also the most direct answer to an agent that has been talked into running attacker-supplied code, and as agents acquire terminal-level access the cost-benefit shifts. The recurring practitioner question the survey records - how do you audit agentic tools with terminal access to proprietary repositories - is the question securing AI coding agents and CLIs exists to answer, and DLP for AI agents explains why the masking approach at 25% covers less than teams expect on its own.
Where the architectural bets are being placed
On the migration question, 32% are actively moving agent logic into durable orchestration layers for state persistence and auditability, 27% are evaluating durable runtimes specifically to enforce data boundaries and deterministic fallbacks, 21% are treating policy-as-code gates as their primary response, and 20% are staying stateless and trying to solve reliability through prompting and retries.
That last 20% is the cohort to watch. Some of them are on managed platforms that genuinely abstract state, and are fine. The rest are attempting to fix a structural durability problem with better wording, which is the same trap that turned a generation of RPA automations into unmaintainable rule stacks. The security version of the same mistake is more common than the reliability version: putting the guardrail in the system prompt. A prompt is a request the model may decline to honor under adversarial pressure. A hook that evaluates the call before it executes is not, which is the distinction drawn in how Claude Code hooks work and argued out in scan-time checks versus runtime governance.
On long-term architecture, 39% are making the polyglot bet, 28% are consolidating on a primary cloud provider's managed stack, 16% are betting a frontier lab will handle reasoning, state, and execution end to end, and 16% are adopting provider-agnostic durable runtimes for full data sovereignty. One respondent summarized the deadlock the fragmentation creates: enterprises trust no single provider enough to hand over full control, and lack the engineering capacity to build everything themselves. Framework-specific risks for the agnostic path are covered in securing AI agent frameworks.
The production gate is a human-trust metric
Asked which single metric determines whether an agent ships, 47% named user acceptance rate - the share of autonomous actions a human accepts as-is. 30% named context fidelity, defined as holding state across a 48-hour-plus execution window. 12% named tool selection accuracy, targeting above 99%. 11% named latency jitter, down from 25% in an earlier wave.
A human-trust measure leading the field tells you where deployments actually sit: human-in-the-loop, with review before execution. That is a rational response to hallucination propagation and ghost failures, and it is also a control that quietly degrades. Approval fatigue is real, and the moment a reviewer starts accepting by reflex, user acceptance rate stops measuring trustworthiness and starts measuring habituation. This is the failure mode behind every blanket allow rule we find in the field, documented in what we found scanning AI configs and in the specific case of Claude Code's dangerously-skip-permissions flag. Latency jitter collapsing from 25% to 11% is the healthier signal in this finding: correctness and durability have displaced raw speed as the primary anxiety.
The question the survey does not ask
Nine findings, and none of them asks respondents whether they know which AI agents, MCP servers, and skills are running across their estate. That omission is worth dwelling on, because all four security mechanisms in Finding 6 presuppose the answer. Policy-as-code needs to know which agents to bind rules to. Non-human identity needs an enumeration of agent threads to issue identities for. Egress-locked sandboxing needs to know what to put in the sandbox. Data masking needs to know which inference paths to sit in front of.
In practice, the enumeration is the part that is missing. Developers install MCP servers and skills without a ticket, the same way they installed browser extensions a decade ago, which is the dynamic we describe in AI agents are the new shadow IT and quantify in what is shadow AI. A governance org chart, a policy document, and a chosen mechanism can all be in place while the actual population of agents on endpoints remains unknown. That is the most plausible explanation for why four mechanisms sit at parity after two years of adoption: teams are choosing between enforcement philosophies before they have the inventory that any of them requires.
How Anomity fits the runtime control plane
Anomity addresses the layer the survey circles without naming: the endpoint where agents actually run. A lightweight, unprivileged Endpoint Sensor inventories eight AI artifact types per machine - agents, MCP servers, skills, extensions, plugins, hooks, CLIs, and secrets - which is the enumeration that policy-as-code and non-human identity both depend on. It is provider-agnostic by construction, which matters directly for the observability tax finding: an inventory taken at the endpoint sees a Copilot extension, a Codex CLI, and a Claude Code hook in the same view, without inheriting any one vendor's telemetry limits. Anomity transmits metadata only over HTTPS - never source code, never prompts - with secrets redacted on the endpoint before anything leaves.
On agents that expose a hook, such as Claude Code's PreToolUse, runtime governance returns allow, deny, or log on each tool call before it runs. That is the policy-as-code mechanism from Finding 6, placed at the one boundary the model cannot argue past. Every added, changed, and removed artifact lands in a queryable 90-day audit trail, which addresses the evidence problem created by hand-rolled plumbing, and violations route to your SIEM, Slack, email, and Jira through continuous policy evaluation. For teams mapping this to a formal framework, the AI governance framework for enterprises, ISO 42001 for AI agent governance, and the NIST AI RMF applied to agents cover the control mappings.
Being clear about the boundary: Anomity is not a durable execution runtime and does not solve the state amnesia and ghost failure problems the survey leads with. If context is lost on a container restart, Temporal, Restate, or LangGraph is the right tool, and this survey makes a reasonable case for adopting one. Anomity covers the adjacent gap - knowing what exists, deciding what may run, and being able to prove what happened. It complements Network, EDR, DLP, and GRC rather than replacing any of them.
Four security mechanisms at parity is not a market waiting for a winner. It is a market that has not yet built the inventory all four require.Anomity Research
What to do with this data
- Take the 47% integration and governance gap literally. If MCP is becoming your connective tissue, it needs a registry and an approval path, not ad hoc installs.
- Add observability cost to your build-versus-buy analysis as an explicit line item, given the 30-point spread respondents report between platform ecosystems.
- Pick both an identity-centric and a rule-centric control rather than choosing between them. Non-human identity answers who; policy-as-code answers what is stopped regardless.
- Audit your own position against the 20% stateless-commitment cohort, and check specifically whether any guardrail you rely on lives in a system prompt rather than at a tool-call boundary.
- Treat user acceptance rate as a decaying metric. Track approval-fatigue indicators alongside it, and review any blanket allow rules that accumulated to reduce prompts.
- Before selecting a security mechanism, establish the enumeration it needs: every agent, MCP server, and skill actually present on endpoints, reconciled against what was approved.
VentureBeat's conclusion is that the reckoning is runtime and economics rather than reasoning, and the data supports it. The security corollary is narrower and, for a security team, more actionable: the runtime is also where governance either exists or does not. A policy that was approved in a design review and a policy that is evaluated before a tool call executes are not the same artifact. To see which agents, MCP servers, and skills are running across your fleet today, and what runtime governance would have denied, book a 30-minute demo.
Frequently asked questions
What is agentic AI runtime governance?
Agentic AI runtime governance is the practice of controlling and recording what an AI agent does at the moment it acts, rather than approving it once at design or install time. It covers three things: knowing which agents, MCP servers, and skills exist across the fleet; evaluating each tool call against policy before it executes; and keeping a durable record of what was attempted and what was allowed. The distinction that matters is timing. A design review tells you what an agent was supposed to do. Runtime governance tells you what it did.
How reliable is a 132-respondent survey?
It is directional, and VentureBeat says so explicitly in the methodology note. With 132 responses, differences of a few percentage points between adjacent options carry little weight, and the industry mix skews toward technology and software at 42% of the sample. What is worth reading is the shape rather than the precision. When 77% of respondents land in some category of infrastructure overhead and only 17% point at the model, the direction of that split is more informative than any single figure inside it. Treat individual numbers as indicative and the overall pattern as the finding.
Why do only 17% of respondents blame the model?
Because for most production workloads the frontier models are already good enough at the reasoning step, and the failures teams actually encounter happen around the model rather than inside it. Context is lost on a container restart. An API call times out silently and the agent hangs without a traceback. Token cost overruns the business case. None of those are reasoning failures. The 17% who do name the model are reporting a narrower and real problem: reliability degrades once a workflow exceeds roughly ten reasoning steps, and errors early in a chain compound rather than cancel out.
What is the observability tax?
It is the engineering cost of achieving basic visibility into agent failures on a given platform - the custom telemetry, manual instrumentation, and logging glue you have to write yourself. In the survey, 42% of respondents named Microsoft's stack as imposing the highest such cost, followed by OpenAI at 30%, Google at 16%, and Anthropic at 12%. The practical implication is that observability cost belongs as a line item in any build-versus-buy analysis. A platform that looks cheaper at the API layer can be considerably more expensive at the telemetry layer.
What is policy-as-code for AI agents?
Policy-as-code means expressing allow and deny rules in the orchestration or enforcement layer, where they override whatever the model decided to do. It is rule-centric rather than identity-centric: regardless of the agent's intent, certain actions have hard stops at the infrastructure level. Thirty percent of survey respondents named it as their primary security mechanism, the largest single share. The reason it appeals is that it does not depend on the model cooperating. A system prompt asking an agent to avoid an action is advice; a rule evaluated before the tool call runs is a control.
How does Anomity relate to durable execution frameworks?
They solve adjacent problems and Anomity does not replace them. Durable execution frameworks such as Temporal, Restate, and LangGraph address state persistence and fault tolerance - the state amnesia and ghost failure problems in the survey. Anomity addresses the visibility and enforcement problem on the endpoint: inventorying eight AI artifact types per machine, returning allow, deny, or log on each tool call at agents that expose a hook, and keeping a queryable 90-day audit trail of every artifact change. A team could adopt Temporal for durability and still not know which MCP servers its developers installed last week.
What should a security team take from this survey?
Two things. First, the security architecture for agents is genuinely unsettled - four mechanisms sit within eight points of each other, which means there is no consensus pattern to copy and you will be making judgment calls. Second, all four of those mechanisms presuppose an inventory. Policy-as-code needs to know which agents to bind rules to. Non-human identity needs to know which agent threads exist. Egress sandboxing needs to know what to sandbox. The survey does not ask whether respondents have that inventory, which is the most likely reason the mechanisms remain at parity.
