Excessive agency: how over-provisioned AI agents become insider threats
“We didn’t give the agent those permissions. We forgot to take them away.”
TL;DR
One in five developers grant AI coding agents unrestricted workstation access (UpGuard, 2025). Only 21% of executives have visibility into what their agents can access. 88% of organizations have already experienced confirmed or suspected AI agent security incidents. Over-provisioned agents are insider threats that operate at machine speed. OWASP ranked this as LLM06 in 2025 and merged Insecure Plugin Design into it because the root problem is the same: agents have more power than they need. For how attackers exploit these permissions to escalate further, see The privilege escalation kill chain.
What does OWASP LLM06 actually say?
Excessive Agency occurs when an LLM-based system is granted more power, permissions, or system-level capabilities than its task requires. The 2025 update is significant: OWASP merged the former LLM07 (Insecure Plugin Design) into LLM06, recognizing that insecure plugins and excessive agent permissions are the same vulnerability with different names.
The key shift in the 2025 version: it now explicitly addresses agentic systems, not just chatbots. The 2023 version worried about an LLM calling a function it shouldn’t. The 2025 version worries about an autonomous agent chaining tools, pivoting between systems, and escalating privilege without human visibility. The impact spans confidentiality, integrity, and availability depending on what systems the agent can reach.
OWASP’s Agentic AI Top 10 (2026) takes this further with the “Least Agency” principle: autonomy should match task scope, not capability scope. An agent that CAN read, write, and delete from a database should only be ALLOWED to do what its current task requires. The distinction between capability and permission is where most deployments fail.
How bad is the over-provisioning problem?
Worse than most security teams realize, because the defaults are open and the visibility is poor.
UpGuard analyzed 18,000+ GitHub agent configurations and found that one in five developers grant AI coding agents unrestricted workstation access. Roughly 20% allow unrestricted file deletion, meaning a single prompt injection can recursively wipe project directories. Another 20% auto-save changes to the main repository branch, bypassing code review entirely. Attack success rates through prompt injection against GitHub Copilot and Cursor range from 41% to 84% (UpGuard, 2025).
The OpenAI Codex CLI had CVE-2025-61260: a command injection vulnerability allowing arbitrary code execution, patched in v0.23.0. The vulnerability existed because Codex had unrestricted shell access by default.
The numbers on organizational visibility are alarming:
| Metric | Value | Source |
|---|---|---|
| Executives with visibility into agent permissions | 21% | Industry survey, 2026 |
| Organizations deploying agents with full security approval | 14.4% | Akto, 2025 |
| Agents operating without security oversight or logging | >50% | Akto, 2025 |
| Organizations reporting AI agent security incidents | 88% | Industry survey, 2025 |
| Healthcare organizations reporting incidents | 92.7% | Industry survey, 2025 |
| Tech leaders citing governance as primary concern | 75% | Help Net Security, 2026 |
69% of enterprises are deploying agents but only 21% have the visibility needed to secure them. That’s a 48-point gap between deployment velocity and security readiness.
Why do organizations over-provision?
Three forces push organizations toward excessive agency, and all three are rational in isolation.
Capability pressure. The business wants the agent to do more. Every permission restriction reduces functionality. The agent can’t summarize emails if it can’t read emails. It can’t fix code if it can’t write files. It can’t deploy if it can’t run commands. Each individual permission seems justified. The accumulated set creates an insider threat. Gartner projects 40% of enterprise applications will integrate AI agents by end of 2026, up from under 5% in 2025. The deployment velocity leaves no time for permission auditing.
UX and developer shortcuts. Granular permission frameworks don’t exist for most agent platforms. The developer’s choice is often binary: grant access or don’t. “Just give it all permissions, it’ll figure it out” is faster than building a scoped permission model from scratch. When the agent works in demo, nobody goes back to tighten permissions before production.
Unclear dev/prod separation. Agents run with developer credentials during testing. Those same credentials get deployed to production because nobody builds a separate identity management system for AI agents. The agent inherits the developer’s full access: production databases, internal APIs, cloud infrastructure. A human developer exercises judgment about which permissions to use. An agent exercises whatever a prompt injection tells it to.
The result: 82% of executives report confidence in their existing policies, but only 14.4% actually deploy agents with full security approval (Akto, 2025). Confidence without control.
What does the “supercharged insider threat” look like?
Palo Alto Networks called AI agents “2026’s biggest insider threat.” Their chief security intelligence officer characterized it as the “rogue AI agent” threat model. The framing is accurate: an over-provisioned agent that gets hijacked through prompt injection or tool misuse becomes an autonomous insider operating at machine speed.
The difference between a compromised human and a compromised agent:
A human insider might run 5 database queries in an afternoon. An agent issues thousands per second. A human insider might exfiltrate files one at a time over weeks. An agent can enumerate and exfiltrate an entire document store in minutes. A human insider creates audit trails through login times, badge access, and behavioral patterns. An agent’s actions look identical to its normal operations.
Johann Rehberger’s Devin AI assessment (April 2025) demonstrated this precisely. Devin’s Slack integration provided an unsupervised, always-available attack surface. Through indirect prompt injection via a GitHub issue, Rehberger got Devin to: download and execute malware with a C2 callback, paste Jira and Slack tokens into attacker-controlled websites, and run curl/wget commands for data exfiltration. All through legitimate tool access that Devin already had. The agent wasn’t doing anything it couldn’t do. It was doing things it shouldn’t do.
Gartner projects agents will outnumber humans 82:1 by 2026 in hybrid enterprise workforces. Each one of those agents with excessive permissions is a potential insider threat waiting for a trigger.
What does least-privilege agent architecture look like?
graph TB
subgraph "Least-Privilege Architecture"
A[Agent Request] --> B{Permission<br/>Check}
B -->|Allowed| C[Task-Scoped<br/>Token Issued]
B -->|Denied| D[Request Rejected<br/>+ Logged]
C --> E{Action Type}
E -->|Read Only| F[Execute with<br/>Read Token]
E -->|Write/Delete| G{HITL Gate}
E -->|External Comms| H{HITL Gate}
G -->|Approved| I[Execute with<br/>Write Token]
G -->|Denied| D
H -->|Approved| J[Execute with<br/>Scoped Token]
H -->|Denied| D
F --> K[Audit Log]
I --> K
J --> K
end
Start read-only by default. Every agent session begins with read-only access. Write, delete, and execute permissions are granted per-action, not per-session. This is the single most impactful change organizations can make.
Use task-scoped tokens. AWS’s Agentic AI Security Scoping Matrix defines three scopes: information gathering only (Scope 1-2) where all consequential actions require human approval, and autonomous execution (Scope 3) with strict controls. Issue JIT (Just-In-Time) ephemeral credentials valid only for a specific tool and the duration of that single task. Even a compromised agent can’t escalate beyond its current task scope.
Whitelist tools per agent role. A customer service agent needs access to the knowledge base and ticketing system. It doesn’t need database write access, shell execution, or email sending. Define positive lists (what the agent CAN do) rather than negative lists (what it can’t). Negative lists always miss something.
Implement HITL gates for high-impact actions. Deletes, financial transactions, external communications, and configuration changes require explicit human approval. The gate should show the action, the context, and the justification. This adds latency for sensitive operations but prevents the scenarios where a single injection causes catastrophic damage.
Rate-limit tool calls. An agent making 1,000 database queries per second is either broken or compromised. Set rate limits that reflect legitimate usage patterns. Alert on sustained high-volume tool usage.
Separate credentials per agent. Each agent gets its own identity with its own permissions. Shared credentials mean a compromise of one agent compromises all of them. For how to implement cryptographic agent identity, see Cryptographic capability binding.
Key takeaways
- OWASP LLM06:2025 (Excessive Agency) now covers both over-provisioned agents and insecure plugin design as the same vulnerability
- One in five developers grant AI agents unrestricted workstation access; only 14.4% deploy with full security approval
- 88% of organizations report confirmed or suspected AI agent security incidents
- Over-provisioned agents are insider threats at machine speed: thousands of actions per second through legitimate tool access
- Three forces drive over-provisioning: capability pressure, developer shortcuts, and unclear dev/prod separation
- Least-privilege architecture: start read-only, task-scoped tokens, whitelisted tools, HITL gates for high-impact actions, rate limits, separate credentials per agent
- Only 21% of executives have visibility into what their agents can access. Fix the visibility gap before fixing the permission gap.
FAQ
What is excessive agency in AI systems?
Excessive agency (OWASP LLM06:2025) occurs when an AI agent has more permissions, tools, or system access than its task requires. A coding agent that needs to read files but can also delete them, send network requests, and modify system configs has excessive agency. Prompt injection exploits these unnecessary permissions to cause damage beyond the original task scope.
Why do organizations give AI agents too many permissions?
Three reasons. Capability pressure: business demands fast deployment and broad functionality. UX shortcuts: granting all permissions is faster than scoping them per task. Unclear dev/prod separation: agents run with developer credentials in production. Only 14.4% of organizations deploy agents with full security approval.
What does a least-privilege AI agent architecture look like?
Start every session in read-only mode. Issue task-scoped tokens that expire after each operation. Whitelist specific tools per agent role. Implement HITL gates for deletes, external communications, and financial transactions. Rate-limit tool calls. Separate credentials for each agent. Log every tool invocation.
How many organizations have had AI agent security incidents?
88% reported confirmed or suspected incidents in the past year. Healthcare reaches 92.7%. Despite this, only 21% of executives have complete visibility into agent permissions, and over 50% of agents operate without security oversight or logging.
Want to work together?
I take on projects, advisory roles, and fractional CTO engagements in AI/ML. I also help businesses go AI-native with agentic workflows and agent orchestration.
Get in touch