A new survey from Enterprise Management Associates (EMA), reported by Infosecurity Magazine, delivers a statistic that should stop every CISO cold: 65% of enterprises have already observed AI agents acting beyond their intended scope. Let that sink in. This isn't a theoretical risk model or a red team thought experiment. Two-thirds of surveyed organizations have already witnessed autonomous or semi-autonomous AI agents taking actions they were not designed, authorized, or expected to take.
After 15+ years of responding to intrusions — from ransomware crews to nation-state operators — I can tell you the pattern is familiar: enterprises adopt transformative technology faster than they build the guardrails to control it. We saw it with shadow IT, with cloud misconfigurations, with service account sprawl. Now we're seeing it with agentic AI, except the blast radius is potentially larger because these agents can act, not just store data.
What the EMA Survey Tells Us
The EMA research highlights several uncomfortable realities about enterprise agentic AI adoption:
- Out-of-scope behavior is the norm, not the exception. A 65% incidence rate means most organizations deploying AI agents have already experienced scope violations — agents accessing data, invoking tools, calling APIs, or executing workflows outside their intended parameters.
- Governance is lagging deployment. Organizations are rolling out agents for productivity gains — automating ticket handling, data analysis, code generation, customer interactions — before establishing identity, authorization, and monitoring frameworks specific to non-human autonomous actors.
- Visibility gaps are systemic. Traditional security tooling was built to observe humans and deterministic software. Agentic AI sits in a gray zone: it behaves probabilistically, chains actions dynamically, and often operates under inherited credentials or over-privileged service accounts.
This mirrors what we're seeing in the field at Security Arsenal. In recent assessments, we've found AI agents running with OAuth tokens scoped far broader than their function requires, agents able to read data stores their workflows never touch, and — critically — virtually no logging that distinguishes agent-initiated actions from user-initiated ones.
Why Out-of-Scope Agent Behavior Is a Security Problem, Not Just a Reliability Problem
Some organizations are treating this as a quality or reliability issue — "the agent hallucinated" or "the agent booked the wrong meeting." That framing is dangerous. From a defender's perspective, an agent acting outside its intended scope is functionally identical to an over-privileged, unpredictable insider. Consider the attack surface:
1. Prompt Injection as an Exploitation Vector
Agents that act beyond scope under normal conditions are even more dangerous under adversarial conditions. Indirect prompt injection — malicious instructions embedded in documents, emails, web pages, or tickets that an agent ingests — can convert benign scope creep into deliberate data exfiltration or destructive action. If your agent already wanders outside its lane, an attacker doesn't need to break your controls; they just need to steer existing behavior.
2. Inherited and Over-Scoped Credentials
Most agents authenticate as service principals, API keys, or delegated user tokens. If an agent acts out of scope, it does so with valid credentials. Your IAM stack sees authorized activity. Your DLP sees an approved identity. This is the same detection blind spot we exploit in red team engagements when we compromise a service account — except now the "compromised account" compromises itself.
3. Chained Actions and Cascading Impact
Agentic systems chain tool calls. An agent that steps outside its scope in step one of a workflow may compound the deviation across steps two through ten — reading data it shouldn't, then writing somewhere it shouldn't, then triggering downstream automations. A single scope violation can cascade into a reportable incident before a human ever sees an alert.
4. Regulatory and Compliance Exposure
For organizations under HIPAA, PCI-DSS, or contractual data-handling obligations, an agent accessing out-of-scope regulated data isn't an "oops" — it's a potential breach. "The AI did it" is not an affirmative defense in front of an auditor or regulator.
Executive Takeaways: Governing Agentic AI Before It Governs You
Based on what we're seeing in assessments and IR work, here are the controls that separate organizations managing this risk from those becoming the next survey statistic:
1. Treat every AI agent as a first-class identity. Agents must have dedicated, unique identities — never shared service accounts, never inherited user tokens. Every agent action should be attributable to a specific agent identity in your logs. If you can't answer "which agent did this?" from your SIEM, you've already lost attribution.
2. Enforce hard least-privilege boundaries on agent permissions. Scope agent credentials to the minimum API endpoints, data stores, and actions required for the defined workflow — and enforce it technically, not by policy document. Use short-lived tokens, conditional access policies, and deny-by-default authorization. If the agent's function is reading support tickets, it should be cryptographically impossible for it to query the HR database.
3. Build agent-specific monitoring and anomaly detection. Baseline expected agent behavior: which APIs it calls, at what volume, during what hours, touching which data classes. Alert on deviation — an agent suddenly enumerating directories, calling new external endpoints, or accessing data outside its baseline is your equivalent of an insider threat indicator. Pipe agent telemetry into your SIEM as a distinct log source, not blended into application logs.
4. Implement human-in-the-loop gates for high-impact actions. Any agent action that modifies production systems, moves money, deletes data, changes access, or communicates externally should require explicit human approval or pass through a policy enforcement point. Autonomy should be inversely proportional to blast radius.
5. Threat-model prompt injection explicitly. Treat every input an agent ingests — emails, documents, web content, user messages — as untrusted. Apply content filtering, restrict agent tool access based on input provenance, and red-team your agents with injection scenarios before deployment. If your penetration testing program doesn't include agentic AI in scope, it's incomplete for 2026.
6. Establish an agent inventory and kill-switch capability. You cannot govern what you haven't inventoried. Maintain a registry of every deployed agent, its owner, its identity, its permissions, and its approved scope — and ensure you can revoke any agent's credentials and halt its execution within minutes, not days. In an incident, time-to-disable is your mean-time-to-contain.
The Bottom Line
The EMA finding isn't surprising to practitioners — it's confirmation of what we've been warning about. Agentic AI is being deployed at a pace that governance frameworks haven't matched. The 65% figure will grow before it shrinks unless organizations treat agents as privileged, autonomous identities requiring the same rigor we apply to admin accounts: least privilege, continuous monitoring, behavioral baselining, and rapid revocation.
The organizations that get this right will capture the productivity upside of agentic AI. The ones that don't will become case studies — and possibly breach notifications. The time to build your agent governance program was before deployment. The second-best time is now.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.