Least Privilege Principles Applied to AI Agents

How agents end up with far more access than they need

The most common origin story for an over-privileged agent is almost embarrassingly mundane: someone deploys one using their own service account, or grabs a convenient IAM role that already exists. The access was scoped for a human doing a job. The agent inherits it wholesale and then executes at a speed and scale no human ever would. Nobody made a bad decision — just a fast one.

This is not an edge case. Per KPMG's Cybersecurity Considerations 2026 report, machine identities in the average enterprise grew from roughly 50,000 in 2021 to 250,000 in 2025, with the ratio of machine to human identities now exceeding 80:1 in cloud-native environments. The 2026 NHI Reality Report sharpens the point: 97% of non-human identities carry excessive privileges beyond what their function requires. Over-provisioning is the default state. Tight scoping is the exception.

What compounds the problem for agents is runtime acquisition. An agent granted access to a development repository discovers mid-task that it needs a production configuration file, a Slack webhook, and a payment API. In permissive environments, it requests or receives that access without triggering an alert. The privilege documented in policy and the privilege actually exercised diverge — and that gap is wider for agents than for any prior identity class.

Only 28% of organizations, per the same NHI Reality Report, have full visibility into their non-human identities. You cannot scope what you cannot see, and right now most teams are working half-blind.

Why prompt injection turns over-privilege into a direct attack path

OWASP designated prompt injection LLM01:2025, the top vulnerability in its Top 10 for LLM Applications. It is not a bug that gets patched in a future release. Rather, it is a structural property of how language models process input: they cannot reliably distinguish between instructions from a trusted principal and instructions embedded in untrusted content they are asked to reason about. This is worth sitting with for a moment, because the security industry spent decades building controls premised on the assumption that you can separate instructions from data. Agents dissolve that boundary — the dangerous payload arrives inside something the system was designed to open.

Two incidents from 2025 make the attack path concrete. In the first, a malicious prompt embedded in a public GitHub issue manipulated a coding assistant into exfiltrating repository data via a broad-scoped personal access token. In the second, EchoLeak (CVE-2025-32711, CVSS 9.3) used a single crafted email to trigger zero-click data exfiltration from Microsoft 365 Copilot, with no user interaction required. Neither attack required malware. Both required only that the agent had more standing privilege than its task needed.

The implication is uncomfortable: no fully reliable technical defense against prompt injection exists at the model level. The durable mitigation is architectural. A successfully injected agent limited to its current task has a blast radius bounded by that task's scope. An injected agent with inherited human-scale permissions has a blast radius measured in whatever that person can reach across the entire organization. Over-privilege is not a background risk; it is the mechanism that converts a successful injection into actual damage.

The confused deputy problem and what it means for authorization

When an agent executes an action, authorization is evaluated against the agent's IAM identity, not the identity of the human who initiated the workflow. This creates an inversion that traditional access control has no answer for.

The concrete case: a developer with read-only S3 access triggers an agent whose role permits write and delete on the same bucket. The agent's action is technically authorized. The human initiating it would have been denied that action outright. The agent is acting as a more privileged deputy than the principal it serves, and there is no enforcement mechanism to close the gap. This is the confused deputy problem, a concept well-established in security theory since the 1980s, now manifesting at scale across enterprise agent deployments. Old problem, new urgency.

The problem does not stop at single-hop authorization. Agents chain tools, spawn sub-agents, write and execute code, and call external APIs. Each individual step passes authorization checks. The sequence, however, produces de facto administrative access that no static policy ever anticipated. Per Entro Security's research, just 0.01% of machine identities control 80% of cloud resources. A single privilege escalation to one of those credentials produces a blast radius that is genuinely catastrophic. Traditional IAM was designed for predictable, human-paced sessions, not for autonomous execution graphs that nobody fully specified in advance.

How privilege escalation compounds across multi-agent systems

Multi-agent architectures introduce a different order of problem, and it is one the industry has been slow to reckon with. An orchestrator passes context, credentials, and tool access to sub-agents. Nothing prevents it from passing everything, regardless of what the sub-agent's task requires. MCP agents inherit their orchestrating application's full permission scope by default. Least privilege in this layer does not exist unless the developer explicitly builds it in — and in practice, most MCP deployments skip this step because nobody told them they needed to.

A sub-agent spawned for a narrowly scoped task receives capabilities far exceeding what its work requires, with no audit trail distinguishing what it used from what it merely had access to. That distinction matters enormously. Most current logging architectures do not capture it.

The escalation risk is compounded by implicit peer trust. Prompt injection can propagate across agent chains: one compromised agent passes malicious instructions downstream, escalating privilege through a system that looks internally consistent at each individual hop. The pipeline is unaware it has been compromised because no individual credential looks out of place. This is what makes peer trust between agents an architectural assumption that attackers can exploit with relative ease.

Where existing IAM frameworks stop working

Static role-based access control assumes predictable, human-paced workflows. An agent that switches tasks mid-execution, chains tools dynamically, or operates across multiple systems simultaneously violates every assumption that model was built on. The policy was scoped correctly. The execution graph was not. The gap between those two things is where the exposure lives, and RBAC has no mechanism to close it.

The legacy NHI strategy, which combines secrets scanning with vaulting and human IAM extensions, was built for static API keys. It was not built for identities that reason, plan, and take sequences of actions that were never individually anticipated at provisioning time. Using those tools to govern agents is like using a speed camera to enforce altitude limits.

The governance problem is equally intractable. A 2025 WEF analysis found 51% of organizations report no clear ownership of AI identities. Only 44% have implemented any policies to govern their AI agents, despite 92% agreeing it is critical to enterprise security. This is not an awareness problem — every practitioner knows agents need governance. The gap exists because the available controls were designed for a different identity class entirely, and no widely adopted substitute has emerged.

What current frameworks say enterprises should do

NIST's NCCoE launched the AI Agent Standards Initiative in February 2026, among the first U.S. government actions specifically targeting agentic AI security. Its concept paper on AI Agent Identity and Authorization identifies four minimum architecture requirements: identification, authorization, access delegation, and logging. These are not aspirational targets — the framework treats them as the baseline.

OWASP's Top 10 for Agentic Applications 2026 introduces "Least Agency" as the agentic equivalent of least privilege: minimum autonomy, minimum tool access, minimum credential scope, framed as a design requirement rather than a post-deployment security review comment. The three categories most directly tied to privilege abuse are Agent Goal Hijack (ASI01:2026), Tool Misuse and Exploitation (ASI02:2026), and Agent Identity and Privilege Abuse (ASI03:2026). Together they describe the majority of realistic attack paths against production agentic systems today.

The compliance trajectory is also worth attention. SOC 2, ISO 27001, PCI DSS, and NIST 800-53 all carry access governance requirements that apply in principle to non-human identities. Auditors are increasingly asking specific questions about machine identity governance. What NIST codifies in 2026 will appear in SOC 2 audits by 2027. Enterprises treating agentic security as a future problem are already accumulating audit exposure.

For practitioners navigating this before final standards arrive: NIST AI RMF sets the governance and control architecture, OWASP Agentic Top 10 provides the threat-modeling vocabulary. Together they define the minimum viable security posture for production agentic deployments right now.

The technical controls that make least privilege enforceable for agents

Zero Standing Privileges is the correct starting posture. No identity retains persistent access. Permissions are granted just-in-time, scoped to the specific task, and automatically revoked when the task completes. Standing access creates ungoverned execution paths by definition; every moment a dormant credential exists is a moment an attacker or injected agent can exploit it.

Just-in-time access operationalizes ZSP: permissions are blocked by default, the grant is triggered by a specific task event, and the credential expires automatically. This is a well-understood pattern that most teams have never applied to agents because agents were outside scope when the original IAM architecture was designed.

Task-scoped credentials take this further. Rather than granting an agent a broad role, issue ephemeral credentials tied to what the current task actually requires. The blast radius of a compromise is bounded by what was needed for that execution, not by the agent's general capability. This is the single control with the most immediate impact on exposure, and the one most conspicuously absent from current deployments.

Tool-level access controls enforce permissions at the tool-call boundary, not just at credential issuance. An agent should not be able to invoke a tool whose output it has no legitimate need for in the current task, regardless of whether its credential technically permits the call.

Continuous authorization treats permission validation as an ongoing check at each action rather than a one-time gate at session start. The agent's permission state is evaluated against its current task context continuously. This is architecturally more expensive than static session authorization, but it is the only model that makes sense for non-deterministic execution — the cost is not optional.

Human-in-the-loop checkpoints are a hard boundary for high-impact or irreversible actions: the agent pauses and waits for explicit approval before proceeding, regardless of its technical authorization. This is a deliberate design decision about which actions should never be autonomous, not a fallback for when other controls fail.

Immutable audit logs tied to agent identity for every action taken are not just a forensics capability. They are the enforcement mechanism that makes every other control accountable.

What good visibility into agent behavior requires in practice

You cannot enforce least privilege for identities you have not discovered. The first requirement is a complete, current inventory of every agent running in the environment and the credentials each one holds. Most organizations lack that picture. The 28% visibility figure cited earlier is not a measure of immaturity; it includes security-conscious teams that have never had tooling designed for this problem.

Static inventory is insufficient for agents because they acquire new tool access and spawn sub-agents at runtime. The inventory must be continuous, not a quarterly point-in-time snapshot.

Behavioral baselining establishes what normal execution looks like for a given agent, enabling anomaly detection: unusual tool calls, access to resources outside the task context, unexpected external API calls. Without a baseline, these deviations pass silently because no individual action necessarily looks wrong in isolation. This is where many teams discover their logging architecture is less complete than they assumed.

The distinction between logging and monitoring is critical and frequently collapsed. A log records what happened. Runtime monitoring detects a policy violation while the action is still in progress and blocks it before damage is done. For agents operating at machine speed, the difference between those two capabilities is often the difference between an incident that gets caught and one that concludes before any human sees it.

Per the 2026 NHI Reality Report, organizations failing to scope AI access properly are 4.5 times more likely to experience a security incident, with properly scoped agents showing a 17% incident rate compared to 76% for over-privileged systems. The audit trail must capture not just what the agent did, but what it was authorized to do and what it was asked to do — the gap between those three data points is where most agentic security incidents live.

How to approach least privilege implementation as agents scale across the enterprise

Start with discovery. Before any policy can be enforced, map every agent, every credential it holds, and every system it can reach. This is the step most organizations skip because it is unglamorous and produces an uncomfortable picture. It is also non-negotiable.

Treat agent identity as a workload-identity problem rather than a user-proxy problem. The governance model, tooling, and review cadence are categorically different. Every team that treats agents as slightly unusual service accounts finds its access governance frameworks systematically inadequate — usually at the worst possible moment.

Prioritize the highest-privilege agents first. Given that 0.01% of machine identities control 80% of cloud resources, per Entro Security's research, scoping those correctly produces disproportionate impact on overall blast radius relative to the effort required.

Build least privilege into the agent development lifecycle rather than retrofitting it after deployment. OWASP's Least Agency principle frames the right question: what tools does this agent actually need, and can the task be completed with less? That question belongs in design reviews, not post-incident retrospectives.

Gartner predicts 33% of enterprise applications will include agentic AI by 2028, up from less than 1% in 2024. The governance architecture built now will either scale or become a liability as that deployment curve steepens. The organizations getting this right today are not being cautious; they are avoiding the far more expensive problem of retrofitting controls at scale, under pressure, after something has gone wrong. That scenario is predictable and entirely avoidable — which is what makes it frustrating to watch unfold.