August 31, 2026
Cequence Security and Enterprise Management Associates published a report on August 31, 2026, called "Agents Without Guardrails: The Agentic AI Governance Gap in the Enterprise," and the headline numbers are worth sitting with. According to the joint research covered by GlobeNewswire, 94% of enterprise IT and security leaders surveyed said they're confident their AI agents don't have more access than they actually need. Only 33% actually provision those agents with least-privilege access. The other two-thirds are running agents on broad standing permissions that get reviewed periodically, rarely, or never at all. That's not a rounding error. That's most of the enterprise market believing something about their AI agents that, by their own admission, they haven't actually verified.
The same research found that 65% of surveyed organizations have already experienced an AI agent take an action outside its intended scope. Nearly a third -- 29% -- experienced that with measurable business impact: data exposure, financial loss, and operational disruption. This isn't a theoretical governance debate about what could go wrong someday. It's a survey of enterprises telling researchers it already went wrong, at scale, in ways that showed up on a balance sheet or a breach report. We've written before about how an AI agent buying the wrong shirt or agents losing trust right where they need it most makes for a good headline but points to something structural. This EMA and Cequence data is the structural version, quantified across a real enterprise sample instead of a single anecdote.
Here's our read on why 94% confidence coexists with 33% enforcement, and it isn't that IT leaders are careless or lying to survey-takers. It's that most enterprise AI agents get deployed the same way: bolted onto an existing system, with default or broad permissions set by a vendor, and then trusted rather than actively scoped by the team actually using the thing. Nobody sat down and decided the agent should be able to touch every customer record or every finance table. A default configuration made that decision, months or years before the agent was ever pointed at real data, and it stuck around because reviewing it takes effort nobody budgeted for. That's a structurally different starting point than building the specific internal tool a team actually needs. When you build a workflow yourself -- say, an inventory and reorder-alert app or a client approval workflow -- defining what data it touches and what actions it's allowed to take isn't an afterthought bolted onto someone else's agent. It's a decision your team makes explicitly, because there's no default permission model sitting there for you to inherit and trust. You have to specify it, because otherwise nothing gets built at all.
We want to be precise here rather than overstate the case. Building your own tool doesn't automatically solve least-privilege enforcement. A team can absolutely build something overly permissive -- give a workflow broad database access because it's easier than scoping it narrowly, then never revisit that decision either. The EMA and Cequence finding that two-thirds of organizations trust but don't verify is fundamentally a discipline problem, and discipline problems don't respect the boundary between AI agents and any other kind of software. You can under-govern a custom-built app just as easily as a vendor's agent. The narrower, more honest point is this: the survey's core problem is a confidence-without-verification gap, and that gap is easiest to create when permissions come from a system you didn't build and can't fully see into. That describes most AI agents bolted onto SaaS tools today. It describes close to the opposite of what building a specific, visible internal tool requires a team to do, because visibility into what the thing can access is a byproduct of having built it rather than something you'd need to go audit separately.
If you're evaluating AI agents for enterprise workflows, the EMA and Cequence numbers are a reasonable prompt to ask a blunt question before you deploy anything: who defined this agent's permissions, and when was the last time anyone actually checked them against what the agent does today rather than what it was scoped to do at rollout? If the honest answer is "the vendor did, at setup, and nobody's looked since," you're statistically likely to be in the 67% rather than the 33%. This is part of why we think the buy vs. build vs. ViibeStack decision is worth taking seriously even for workflows that seem small. It's not an argument that no-code building is inherently more secure -- it's an argument that the act of building forces the scoping conversation that bolted-on agents let you skip. If you want to see how we think about access and data handling more broadly, our Trust Center and security page lay out the specifics rather than asking you to just take our word for it -- which, per this research, is exactly the habit worth breaking.
Sources