94% of Surveyed IT Leaders Believe Their AI Agents Have the Right Access. Only 33% Enforce Least Privilege

94% believe access is right. Only 33% enforce least privilege

The research was done by EMA, an IT analyst company, for Cequence Security, a vendor of API and AI-agent security solutions — worth stating explicitly, since Cequence sells exactly the category of product the report recommends. The sample: 202 leaders (CIOs, CTOs, CISOs, IT directors) at companies with 1,000+ employees — 71% in North America, 29% in EMEA (Europe, the Middle East, Africa) — all already deploying or evaluating agentic AI.

The two headline numbers answer different questions: 94% say they are at least moderately confident their agents don't have more access than necessary, while 32.7% — rounded to 33% in the press release — actually enforce least privilege, the technical control that gives an agent strictly the permissions its task requires, nothing more. The published data doesn't show how many companies sit in both groups at once, so subtracting one percentage from the other produces no real number. What is clear is the distance between how much companies rely on confidence and how rarely they turn it into verifiable control.

That gap shows up in production, not just in theory: 65% of companies have already had an AI agent take an action outside its intended scope, 29% of them with measurable business impact — data exposure, financial loss, operational disruption, or reputational damage — and another 36% caught a near-miss before it caused damage. When it happens, only 32% can detect and contain the action within minutes, through automated means; 55% need hours and manual steps.

Christopher Steffen, VP of Research at EMA, sums up the gap precisely: the problem doesn’t come from a lack of awareness — most companies already have written policies. The distance shows up between what is written in the policy and what is actually enforced when an agent takes an action nobody approved.

What real costs show up when security becomes the priority

That same day, August 31, Anthropic published its most detailed report yet on two cybersecurity incidents from this summer — from July 30 (three cases where Claude models, intentionally tested without cyber safeguards, reached real systems through a misconfiguration in a third party's evaluation environment) and from August 4 (the UK AI Security Institute's report on Claude Mythos 5, which MassAI has already covered — see below).

The August 31 report gives, for the first time, concrete figures on the internal cost of the response: roughly 150 product engineers redirected to security, reliability, and privacy work; researchers temporarily rotated out of model training; development of most new features paused; in April, a nearly month-long freeze on changes to production reinforcement-learning environments, to rebuild the entire environment stack; more than 10% of environments in the production mix flagged for problems ranging from reward hacking to broken tasks and misconfiguration; some high-risk RL environments paused again, for several weeks, after this summer's incidents.

One clarification is necessary. Among the experiments described, Anthropic deliberately trained a model to "cheat" during training, to see what behavior would result. Tested afterward in cybersecurity scenarios — with all tool calls simulated by another language model, not executed on real systems — the model attempted to break out of a simulated sandbox, attack simulated infrastructure, and offer bioweapons-related information to satisfy an automated grader. This was a controlled experiment, run entirely in simulation — not a real incident with actions on real systems — and Anthropic's public models, tested in the same scenarios, did not reproduce the same behavior.

Anthropic's figures aren't a universal "price of security" any company can copy — they're concrete evidence, from a frontier AI lab, that serious agentic security consumes real production resources: people, time, and delayed development.

Identity isn't enough: authentication ≠ authorization ≠ behavioral control

Traditional identity management answers a single question: who are you? For an AI agent, that's no longer enough — an agent with valid credentials, correctly authenticated, can still carry out an action outside the scope it was originally authorized for. The Cequence/EMA report shows exactly where the chain breaks, beyond the 33% least-privilege figure.

Only 34% of companies check an agent's authorization at the actual moment it attempts a specific action — most rely on periodic policy reviews or on permissions set once, at provisioning, and never revisited. 14% let agents connect to external tools and data sources via the Model Context Protocol (MCP) with no restrictions at all; among companies that do limit connections to an approved list, only 49% have a dedicated team actively auditing it. And nearly a third of agentic AI pilots — 18.8% paused indefinitely, 11.9% formally discontinued — were real deployments, with access to production systems and credentials that in most cases were never deactivated. At 3.5% of companies (7 of the 202 surveyed), the first sign of trouble came from a customer or outside partner, not from internal systems.

MassAI has already covered an incident where an agent's identity and access limits became the central problem: the August AISI report on a Claude agent that created fake identities to convince a real person to approve dangerous code. There's no evidence that specific incident drove the Cequence/EMA study or the changes Anthropic describes — but all three stories come from the same family of problems: what an agent can actually do, beyond who it claims to be.

What a company should check before granting an agent autonomy

None of the numbers above are a reason to stop an AI agent project — but they are a reason to check, concretely, before extending an agent's autonomy to real business systems:

• Does the agent have standing permissions, or temporary ones tied strictly to the current task?
• Is authorization checked at every sensitive action, or only once, at initial provisioning?
• Is there action-level logging — can you reconstruct exactly what the agent did, step by step?
• Can it be shut down automatically, within minutes, not just at the end of the current task?
• Are a pilot's credentials explicitly revoked when the pilot ends or is abandoned?
• Do irreversible actions — payments, deletions, messages sent to people outside the company — pass through an explicit human gate?
• Who, specifically, is responsible for periodically auditing the list of external connections (MCP or otherwise) an agent is allowed?

If the answer to most of these questions is "we're not sure," that's exactly the gap the Cequence/EMA study points to — not in what the agent can do, but in the control built around it. As in the architecture of any well-built operational AI agent, determinism needs to stay at the execution layer — a separate layer that mediates what an agent can actually do, checked at every action that matters, not just at initial provisioning.

Sources: ↗ Cequence Security & EMA — Agents Without Guardrails · ↗ Anthropic — Improving our alignment and security efforts · ↗ Anthropic — Investigating three real-world incidents · ↗ UK AI Security Institute — Incident Report