---
title: "Agent access control and least-privilege patterns: why IAM was not built for this"
date: 2026-04-16
author: david
excerpt: "Non-human identities outnumber human identities 50:1 in the average enterprise environment. That ratio is projected to reach 80:1 within two years. Yet only 10% of organizations have strategies for managing non-human and agentic identities. Most AI agents deployed in production run with the same permissions as the user or service account that launched them, including filesystem write access, network egress, code execution and database admin credentials. IAM systems enforce permissions based on human identity. When actions are executed by an AI agent, traditional authorization breaks down."
category: security
tags:
  - agent governance
  - access control
  - least privilege
  - IAM
  - security
  - OAuth
  - credentials
  - zero trust
draft: false
tldr: "Traditional IAM was designed for human users with persistent roles. AI agents break every assumption it was built on: they operate in persistent sessions, inherit credentials from their invoking context, escalate scope through tool use and chain access across systems. This guide covers why agent permissions differ from human permissions, five agent-specific access control patterns (time-bounded tokens, task-scoped permissions, just-in-time access, zero standing privilege, delegated authorization), OAuth limitations for agent permission models, credential management for long-running agents, access revocation at decommissioning and an agent permission matrix template."
seo:
  title: "AI agent access control: least-privilege patterns and permission models"
  description: "A security guide to AI agent access control covering least-privilege patterns, time-bounded tokens, task-scoped permissions, just-in-time access, OAuth limitations, credential rotation, decommissioning access revocation and an agent permission matrix template."
faqs:
  - question: "Why does traditional IAM fail for AI agents?"
    answer: "IAM systems enforce permissions based on human identity: a person authenticates, receives role-based access and acts within those permissions. AI agents break this model in four ways. They operate in persistent sessions that outlive any human interaction. They inherit credentials from the user or service account that launched them, often receiving far more access than needed. They escalate scope through tool use, gaining access to systems not in their original permission set. And they chain access across systems, creating cross-boundary data flows that no single IAM policy governs."
  - question: "What is zero standing privilege for AI agents?"
    answer: "Zero standing privilege (ZSP) means the agent has no persistent permissions. Access is provisioned dynamically when needed, scoped to a specific task and revoked automatically when the task completes. Instead of granting an agent permanent read access to a database, ZSP issues a 5-minute read-only token for a specific table when the agent needs it. This approach reduces the attack surface by ensuring that privileged permissions do not exist until the moment they are required."
  - question: "How should credentials be managed for long-running AI agents?"
    answer: "Long-running agents should never use static API keys or long-lived tokens. Best practices include: OAuth client credentials flows with short-lived access tokens (15-30 minute expiry), refresh token rotation where new tokens are issued with each refresh and old ones immediately invalidated, workload identity federation that derives credentials from the agent's runtime environment rather than pre-shared secrets and vault-managed dynamic secrets with automated rotation. Each agent should have a unique registered identity with tightly scoped roles."
  - question: "What happens to agent access when an agent is decommissioned?"
    answer: "Agent decommissioning must include systematic access revocation: revoking all active tokens and API keys, removing the agent's identity from all connected systems, auditing access logs to verify no residual access exists, revoking OAuth grants and deleting client credentials, removing the agent from service account groups and role assignments and documenting the decommissioning in the agent registry. Access that persists after decommissioning is a standing vulnerability."
  - question: "What is the agent permission matrix and how do I use it?"
    answer: "The agent permission matrix maps each agent to its required access across four dimensions: data sources (what can it read), actions (what can it do), systems (where can it operate) and time constraints (when and for how long). For each cell, define the minimum permission required rather than the maximum available. Review the matrix quarterly and after any agent configuration change. Permissions not in the matrix should not exist."
---

A DevOps team deployed an AI agent to automate infrastructure provisioning. The agent needed read access to the configuration management database and write access to the cloud provisioning API. The team created a service account for the agent and, following standard practice, granted the service account the same IAM role used by the senior infrastructure engineers. The agent received permissions to create and destroy virtual machines, modify network configurations, access production databases and manage DNS records across every environment.

The agent needed two specific permissions. It received forty-seven.

For six months, the agent operated within its intended scope. Then a prompt injection through a malformed configuration template caused the agent to execute a cleanup routine against production resources. The agent had the permissions to do it. No approval was required. No alert fired until the first service went down.

The incident did not expose a vulnerability in the agent's code. It exposed a vulnerability in how the organization granted access. The agent had been running with full infrastructure engineer permissions because the IAM system had no concept of "agent-appropriate" access.

## Why agent permissions differ from human permissions

IAM systems were designed for a specific actor: a human who authenticates, receives role-based access and operates within those permissions during a bounded session. AI agents break every assumption in that model.

### Persistent sessions

Human sessions have natural boundaries. A person logs in, works and logs out. Session timeouts enforce limits even when the person forgets. AI agents operate in persistent sessions that can run for hours, days or indefinitely. A long-running agent maintains its credentials and access for the entire duration of its operation. The session boundary that limits human access does not exist.

### Credential inheritance

When a human runs an agent, the agent typically inherits the human's credentials or operates under a service account with equivalent access. A data analyst who launches an agent to query customer records may grant that agent the analyst's full database permissions, including access to tables the agent does not need and the analyst rarely uses.

:::cite{name="Barak Turovsky" title="Operating Advisor, Bessemer Venture Partners" linkedin="https://www.linkedin.com/in/baraktur/"}
AI agents are autonomous, high-privilege actors that can reason, act and chain workflows across systems. The core risk is not vulnerability. It is unbounded capability.
:::

### Scope creep through tool use

Agents gain capabilities through tools. An agent with access to a code execution tool can install packages, make network requests and access the filesystem. An agent with access to a database tool can query any table the connection string permits. Each tool expands the agent's effective scope beyond its original permission set. Traditional IAM evaluates permissions at authentication time. Agent capabilities expand at runtime.

### Cross-system access chains

When an agent calls an API that triggers another agent that accesses a third system, the access chain extends across multiple security boundaries. Each hop may use different credentials, traverse different networks and access different data stores. No single IAM policy governs the full chain. The first agent's access control cannot constrain the downstream agents it invokes.

:::fact
Non-human identities outnumber human identities by 50:1 in the average enterprise environment. Analysts project that ratio will reach 80:1 within two years. Yet only 10% of organizations have well-developed strategies for managing non-human and agentic identities. The gap between agent proliferation and identity governance is a structural security risk.
:::

## Five access control patterns for agents

Traditional IAM offers roles, groups and policies. These constructs work for human access patterns. Agent access requires five patterns that IAM was not designed to provide.

### Pattern 1: time-bounded tokens

**The problem:** Agents that receive long-lived tokens maintain access indefinitely. A compromised token grants access until someone manually revokes it.

**The pattern:** Issue tokens that expire within a defined window, typically 15-30 minutes for active operations. The agent must re-authenticate to obtain a new token. If the agent is compromised, the attacker's access window is bounded by the token's remaining lifetime.

**Implementation:**
- Use OAuth 2.0 client credentials flows with short-lived access tokens
- Set token expiry proportional to the task duration, not the agent's lifetime
- Implement refresh token rotation: issue a new refresh token with every access token refresh and immediately invalidate the old one
- Monitor for token reuse after invalidation as a compromise indicator

**Where it applies:** Every agent that accesses external systems. Time-bounded tokens are the minimum viable access control for production agents.

### Pattern 2: task-scoped permissions

**The problem:** An agent that runs multiple tasks throughout the day maintains a permission set broad enough to cover all of them. At any given moment, it has access to resources it does not need for the current task.

**The pattern:** Issue task-scoped tokens valid only for the specific resource and duration required by the current task. Before an agent runs a billing reconciliation job, it requests a read-only token for the billing database table, scoped to a 5-minute window. When the task completes, the token is dropped.

**Implementation:**
- Define permission sets per task, not per agent
- Issue tokens at task initiation, not at agent startup
- Scope tokens to specific resources (tables, APIs, endpoints), not broad categories
- Automatically revoke tokens at task completion, not at session end

**Where it applies:** Agents that perform multiple distinct tasks with different data access requirements. Most production agents qualify.

### Pattern 3: just-in-time access

**The problem:** Agents with standing permissions maintain access to sensitive resources even when they are idle. Standing permissions create a persistent attack surface.

**The pattern:** Zero standing privilege (ZSP). The agent has no persistent permissions. Access is provisioned dynamically when needed, scoped to a specific task and revoked automatically when the task completes. Privileged permissions do not exist until the moment they are required.

:::cite{name="Mike Gozzo" title="Chief Product and Technology Officer, Ada" linkedin="https://ca.linkedin.com/in/mgozzo"}
AI agents are not tools. They are actors. They make decisions, take actions and interact with systems on behalf of your customers. Securing an actor is fundamentally different.
:::

**Implementation:**
- Provision ephemeral, scoped identities per session
- Use secure connection brokering without credential exposure
- Automatic teardown at end of task
- Full session trace: person who delegated, prompt that triggered, policy that authorized, actions that executed

**Where it applies:** Agents that access sensitive systems (production databases, customer data, financial systems). JIT access is the strongest pattern for high-risk agents.

### Pattern 4: approval workflows for privilege escalation

**The problem:** Some tasks require elevated access that exceeds the agent's standard permissions. Without an approval mechanism, agents either lack the access to complete the task or receive pre-authorized elevated access permanently.

**The pattern:** Define escalation paths for each agent. When a task requires access beyond the agent's current scope, the agent requests escalation through a defined workflow. A human approver reviews the request, the purpose, the scope and the duration and grants or denies the escalation.

**Implementation:**
- Define escalation tiers: which permissions can the agent request, from whom and under what conditions
- Require justification for escalation requests (task description, data to be accessed, expected duration)
- Log all escalation requests and decisions for audit
- Set maximum escalation durations with automatic revocation

**Where it applies:** Agents that occasionally need access to production systems, administrative functions or sensitive data that should not be in their standing permission set.

### Pattern 5: delegated authorization

**The problem:** When a user invokes an agent, the agent should act with that user's authority, not with broader permissions. But credential inheritance typically grants the agent the user's full permission set, not the subset relevant to the current request.

**The pattern:** Delegated authorization constrains the agent to a subset of the invoking user's permissions. The agent can only do what the user could do, and only the specific actions the user authorized.

**Implementation:**
- Use OAuth token exchange to swap the user's broad token for a narrower, task-specific token
- Define delegation scopes that limit what the agent can do on the user's behalf
- Ensure the agent cannot escalate beyond the delegating user's permissions
- Log the delegation chain: which user authorized which agent for which actions

**Where it applies:** User-facing agents that perform actions on behalf of specific users (customer service agents, internal productivity agents, data retrieval agents).

## OAuth scopes vs agent permission models

OAuth scopes were designed for third-party applications accessing user data with user consent. They work well for that purpose. They are insufficient for agent permissions.

### Where OAuth works

OAuth scopes effectively constrain agent access when:
- The agent accesses a single API with well-defined scopes
- The access pattern is read-only or narrowly defined
- The agent acts on behalf of a specific user with clear delegation

### Where OAuth falls short

**Multi-hop delegation.** When Agent A calls Service B, which invokes Agent C, the OAuth delegation chain breaks down. Current OAuth standards do not account for multi-hop delegation where permissions must narrow at each hop. Enterprises are building custom implementations while waiting for IETF draft standards to mature.

**Dynamic scope requirements.** Agents determine which tools and resources they need at runtime based on the task. OAuth requires scopes to be requested at authorization time. An agent that discovers it needs database access mid-task cannot request additional scopes without re-initiating the authorization flow.

**Cross-system authorization.** An agent that accesses a CRM, a database and an email system may need three separate OAuth grants with three different scope models. There is no standard mechanism for expressing "this agent needs read access to the CRM, write access to the database and send access to email" in a single authorization request.

### Bridging the gap

Organizations deploying agents across multiple systems should:
- Use OAuth where it fits (single-API, user-delegated access)
- Supplement with task-scoped tokens for cross-system access
- Implement a policy engine that evaluates authorization in real time based on context (task, data sensitivity, agent risk level)
- Maintain a centralized [agent registry](/platform/agent-registry) that maps each agent's authorized access across all systems

## Credential management for long-running agents

Long-running agents, those that operate continuously for days or weeks, present a specific credential management challenge. Static credentials that persist for the agent's lifetime create a standing vulnerability. Dynamic credentials that expire too quickly interrupt operations.

### Static credentials: the standing risk

:::fact
48% of cybersecurity professionals identify agentic AI as the single most dangerous attack vector. Tool misuse and privilege escalation represent the most common reported agent security incidents. An agent running with static API keys holds credentials that can be exfiltrated, reused and exploited without detection until the key is manually rotated.
:::

Static API keys grant access based solely on possession. They provide no way to verify that the entity presenting the credential is authorized to use it. A compromised key grants full access until someone detects the compromise and revokes the key, which can take days or weeks.

### Dynamic credential patterns

**Vault-managed secrets.** Store credentials in a secrets vault (HashiCorp Vault, AWS Secrets Manager) that issues short-lived credentials on demand. The agent never holds a long-lived credential. The vault handles rotation automatically.

**Workload identity federation.** Derive the agent's identity from its runtime environment (Kubernetes service account, cloud instance metadata) rather than pre-shared secrets. The agent proves its identity through platform attestation, not credential presentation.

**Automatic rotation.** For systems that require persistent credentials (legacy APIs, third-party services without OAuth support), implement automated rotation on a schedule shorter than the estimated compromise detection window. If you expect to detect a credential compromise within 24 hours, rotate every 12 hours.

### Four questions for every agent in production

Security teams should be able to answer these questions for every agent:

- **Which credentials does it use?** Enumerate every credential, token, API key and service account the agent accesses.
- **What systems can it access?** Map the full scope of systems reachable through those credentials.
- **When were its privileges last reviewed?** Confirm that the current permission set reflects the agent's current task scope, not a historical accumulation.
- **How quickly can access be revoked?** Measure the time from revocation decision to effective access removal. If revocation takes hours, the exposure window is hours.

## Access revocation at decommissioning

Agent decommissioning is a governance event, not just an operational one. An agent that is shut down but retains active credentials, API keys or service account memberships is a dormant attack surface.

### The decommissioning access checklist

- **Revoke all active tokens:** every OAuth token, API key and session credential associated with the agent must be revoked (not just expired), because expiry waits for the clock while revocation is immediate
- **Remove the agent's identity:** delete the agent's service account, client credentials and any identity records from all connected systems
- **Audit access logs:** review the agent's access history during its final operating period to verify no anomalous access occurred
- **Revoke OAuth grants:** delete the agent's OAuth client registration and any stored consent grants
- **Remove group and role memberships:** the agent's identity should not persist in any IAM group, role assignment or access control list
- **Document the decommissioning:** record the decommissioning event in the [agent registry](/platform/agent-registry), including the date, the person who authorized it, all access that was revoked and confirmation that revocation was verified

For agents governed under the [8 pillars of AI agent governance](/blog/8-pillars-ai-agent-governance), decommissioning access revocation is a required governance control. The [risk classification](/blog/ai-agent-risk-classification) of the agent determines the rigor of the decommissioning process: high-risk agents require verified revocation with audit evidence, low-risk agents require documented revocation.

## The agent permission matrix

The permission matrix maps each agent to its required access across four dimensions. For each cell, define the minimum permission required, not the maximum available.

| Agent | Data sources | Actions | Systems | Time constraints |
|---|---|---|---|---|
| Customer service agent | Customer records (read), knowledge base (read) | Create tickets, send responses | CRM, help desk | Business hours, 30-min token TTL |
| Data pipeline agent | Raw data (read), staging tables (read/write) | Process, load, validate | Data warehouse, staging DB | Scheduled windows, 15-min token TTL |
| Code review agent | Repository (read), CI logs (read) | Comment, approve/request changes | Git platform, CI system | On-demand, task-scoped tokens |
| Monitoring agent | Metrics (read), logs (read), alerts (read/write) | Create alerts, send notifications | Observability platform, notification service | Continuous, 30-min rotating tokens |
| Provisioning agent | Config DB (read), cloud API (scoped write) | Create/modify resources in dev/staging only | Cloud platform, config management | Approval-gated, 5-min escalation tokens |

### Using the matrix

- **Populate the matrix for every production agent:** if an agent is not in the matrix, its permissions have not been reviewed
- **Validate against actual permissions:** compare matrix entries against actual IAM configurations, so permissions that exist in the system but not in the matrix become candidates for removal
- **Review quarterly:** agent capabilities change as new tools and data sources expand the effective permission set; quarterly review catches drift
- **Review after configuration changes:** when an agent gains a new tool or data source, update the matrix and validate that the new access follows least-privilege principles
- **Use the matrix for incident response:** when an agent incident occurs, the matrix provides the immediate answer to "what could this agent access" and the gap between the matrix and actual permissions is the first investigative lead

:::subscribe{title="AI governance, in your inbox" cta="Subscribe"}
Weekly analysis on AI agent governance, compliance and runtime risk. No fluff.
:::

## Enforcement through policy

Access control patterns are only effective when enforced. Documentation that describes least-privilege requirements but cannot prevent violations is governance in name only.

Runtime policy enforcement intercepts agent actions at execution time and evaluates them against the permission matrix. An agent that attempts to access a database table outside its authorized scope is blocked before the query executes. The attempt is logged, and the governance team is alerted.

An [observability platform](/platform/observer) that monitors agent actions in real time provides the enforcement layer that IAM cannot: continuous verification that agents operate within their authorized scope, with automated detection when they do not. For organizations building the governance case, the [ROI framework for agent governance](/blog/business-case-agent-governance-roi) maps the cost of access control failures against the investment in enforcement infrastructure.

The principle of least privilege is decades old. Applying it to AI agents requires new patterns because the old infrastructure was built for a different kind of actor. Agents are not users. They are not services. They are autonomous actors with expanding capabilities, persistent access and the ability to chain actions across systems at machine speed. The access control framework that governs them must account for what they are, not what IAM was designed for.

:::cta{title="See Roval in action" description="Book a 15-minute walkthrough of the agent registry, compliance certification and LLM monitoring." cta="Book a demo" href="/demo"}
:::