94% trust their AI agents' access. 33% enforce it.

Ninety-four percent of enterprise IT and security leaders are confident their AI agents do not have more access than they need. Thirty-three percent actually provision those agents with least-privilege access. That 61-point gap is the finding worth your attention this week, and it is not an enterprise problem — it is a default-settings problem, and small shops inherit the same defaults.

What actually happened

Enterprise Management Associates surveyed 202 CIOs, CTOs, CISOs and IT directors at organizations with 1,000-plus employees that are deploying or evaluating agentic AI. The report, Agents Without Guardrails, was published at the end of August. It was sponsored by Cequence Security, which sells agent and API security — worth knowing before you read the conclusions, though the numbers themselves are specific enough to be useful.

The findings reported by Infosecurity Magazine:

• 65% have had an AI agent act outside its intended scope — 29% with measurable organizational impact, 36% a near-miss caught in time
• 54.5% both require and enforce a unique identity for every agent; the rest require it inconsistently or let agents inherit user and service account credentials
• 34.2% evaluate an agent's authorization at execution time, rather than only at provisioning
• 46% are already running agentic AI across multiple departments in production

Read those together and the picture is coherent. Most teams have written the policy. A third are enforcing it.

Why the AI agent access gap matters for your business

You do not have 1,000 employees, so here is the translation. The enterprise failure mode is a governance gap. Yours is simpler and worse: your agent is probably running as you.

That is how almost every small-team agent setup we open up is wired. The automation authenticates with the owner's Google account, the owner's Stripe key, the owner's admin login to the CMS. Nobody decided that. It is what the quickstart said to do, and it worked, so it shipped. The result is an agent with the union of every permission its author has ever accumulated, no separate audit trail, and no way to revoke it without locking a human out of their own tools.

The 29% who reported measurable impact did not get there through exotic prompt injection. An agent with too much reach did something ordinary and wrong at scale.

Three things fix most of this, and none of them require a platform purchase:

Give the agent its own account. A service identity, not a human's session. This alone gives you a revocation switch and a log line that says which actor did what.

Scope the credential to the job. If the agent drafts replies, it does not need send. If it reads orders, it does not need refunds. Write the smallest permission set that lets the task complete, then run it and see what breaks. What breaks is your actual requirement.

Put a human gate on anything that spends, sends or deletes. Not on everything — that defeats the point. On the irreversible actions specifically.

The runtime authorization number, 34.2%, is the one we would watch over time. Provisioning-time checks answer "what could this agent do in January." Execution-time checks answer "should this agent do this, now." As agents start chaining tools, only the second question is the useful one.

Sources: GlobeNewswire — Cequence & EMA research, Infosecurity Magazine.