Quick answer: Least privilege for AI agents means each agent gets exactly the services it needs — not all the services its API key allows. Implement it with a credential broker: vault storage, per-agent scoping, full audit logs, and revocation at the agent level rather than the key level.
What is least privilege?
Least privilege is a security principle: any actor should have access to exactly what it needs to do its job, and nothing more. In human IAM, this means role-based access control — a developer who needs to read S3 gets S3 read access, not EC2 admin rights. In AI agent IAM, it means the same thing: a Cursor agent doing Stripe webhook configuration should have webhook access, not customer data access.
The principle predates AI entirely — it appears in the 1975 Saltzer and Schroeder paper on protection mechanisms in computer systems. What's changed is the scale and autonomy of the actors. When the actors are humans, you implement least privilege once per role and revisit occasionally. When the actors are AI agents spun up and torn down for individual tasks, the enforcement has to be continuous and automated.
Why is least privilege harder with AI agents than with humans?
Human IAM has decades of tooling — AWS IAM, Google Cloud IAM, Okta, Active Directory. These systems model human roles and assign permissions to those roles. AI agents don't map neatly onto human role models: they're ephemeral (created and destroyed per task), multi-service (they might call Stripe, GitHub, and Vercel in a single task), and autonomous (they make access decisions without human approval on each call).
Most service providers (Stripe, GitHub, Vercel) offer API keys but not per-agent scoping. The service doesn't know whether the key is being used by a human, a CI system, or an AI agent — it grants access based on the key's permissions, period. So the scoping layer has to live in front of the service, not inside it.
The other challenge is behavioral unpredictability. A developer with database admin access will typically use it as needed and stop. An AI agent with database admin access might, in the course of completing a task, read tables it didn't need to, generate queries that reveal data incidentally, or make calls its operator didn't intend. Least privilege constrains what the agent can reach — which limits the consequences of both bugs and compromise.
What happens without it
Consider a realistic scenario: your team gives a Cursor agent a .env file with your company's full Stripe API key. The agent's task is to debug a webhook failure. To do this, it doesn't need customer data access — it only needs to call Stripe's webhook endpoint inspection and retry APIs.
But the key it has grants full Stripe access: reading customer payment methods, retrieving sensitive financial data, creating charges. The agent isn't malicious — it's completing the task it was given. But:
- If the agent has a bug that causes unexpected API calls, it could inadvertently expose customer data
- If the agent's context is exfiltrated (through a prompt injection in fetched data, for example), the attacker gets a full-access Stripe key
- If you need to revoke this agent's access — because it misbehaved, or the contractor running it left — you have to rotate the Stripe key, breaking every other system that depends on it
None of this happens because someone made a security mistake. It happens because the default — sharing the same key across all actors — is the path of least resistance.
What a least-privilege AI agent looks like in practice
A least-privilege AI agent has a named identity — an access profile that defines exactly which services it can access. It retrieves credentials at runtime from a broker, not from environment variables. Every credential retrieval is logged. And its access can be revoked at the agent level, independently of any other agent or system.
Concretely: a Cursor agent working on billing has Stripe access scoped to webhook configuration. It does not have Stripe customer data access. It does not have GitHub access unless that's part of its task. Its Gazebo access profile is the source of truth for what it can reach — and the audit log is the record of what it actually did.
The three dimensions of agent access scoping
Meaningful least privilege for AI agents requires scoping across three dimensions — most implementations only address the first one.
Service-level scoping restricts which services an agent can reach at all. A billing agent can reach Stripe and nothing else. A deployment agent can reach Vercel and GitHub. This is the coarsest level of control and the easiest to implement.
Method-level scoping restricts what operations the agent can perform within a service. Within Stripe, the difference between GET (reading data) and POST/DELETE (modifying data) is significant. A read-only agent should only be allowed GET requests. A webhook configuration agent should be limited to the webhook-specific endpoints. Method-level scoping is what turns "can reach Stripe" into "can only inspect webhooks."
Resource-level scoping restricts which specific resources the agent can touch. Within GitHub, can the agent push to any repository, or only to a specific one? Within a database, can it query any table, or only the ones relevant to its task? Resource-level scoping is the most granular and the hardest to implement without a broker, because it requires the broker to evaluate the actual API request before deciding whether to allow it.
Most teams operating with raw API keys only achieve service-level scoping at best — they might give different agents different keys, but each key grants the full scope the service allows for that credential type.
How do you implement least privilege for AI agents?
The implementation has five steps:
-
Inventory your credentials — map every API key and token your agents use. Most teams find they have far fewer credentials than they expected, but each one is shared much more broadly than intended.
-
Create a named identity per agent — an access profile that specifies which services the agent needs. Cursor gets a cursor profile. Claude Code gets a claude-code profile. Your n8n billing workflow gets an n8n-billing profile.
-
Route credential retrieval through a broker — agents call
get_credentialvia MCP instead of reading from.env. The broker enforces the profile policy and logs every access. -
Set expiry on profiles — agent profiles should have a defined lifetime. A profile for a sprint should expire at sprint end. A profile for a contractor engagement should expire when the contract ends.
-
Audit regularly — review the credential access log. If a profile is accessing services it shouldn't need, narrow the scope. If a profile hasn't been used in 30 days, delete it.
Common least privilege mistakes
Scope creep over time. A profile is created with the minimum necessary access. Six months later it has been expanded three times to accommodate new tasks. No one remembers why each expansion happened or whether it's still needed. The fix is regular access reviews — not just auditing which agents exist, but auditing whether each profile's scope still matches the agent's actual work.
Treating service-level scoping as sufficient. Giving one agent its own Stripe key is better than sharing a key across ten agents, but if that key grants full Stripe access, you've improved revocation granularity without improving the blast radius of a compromise. Scope at the method and resource level too.
Skipping least privilege for "trusted" agents. Internal agents — the ones your own engineers built — often get full access because the assumption is that they're safe. They're not inherently safer than external agents: they can have bugs, their prompts can be injected, and their operators can make mistakes. Apply the same scoping discipline.
No expiry on long-running profiles. An agent profile created for a specific project that runs indefinitely is an access control that can never be cleaned up without action. Build expiry into every profile at creation time.
Least privilege and compliance
For teams working toward SOC 2, ISO 27001, or similar certifications, least privilege isn't just a security recommendation — it's a control requirement. Auditors want to see that access is scoped to what's necessary, that access is reviewed periodically, and that there's a record of what was accessed and by whom.
AI agents create a new challenge for these audits: they're not humans and they don't appear in traditional IAM systems. A credential broker that enforces per-agent access profiles and maintains audit logs gives compliance teams something to point to — a record of which agent was authorized to do what, and what it actually did.
What's the difference between key rotation and profile revocation?
Key rotation means generating a new API key for a service and updating every system that uses it. It's disruptive, error-prone, and often avoided — which means compromised keys stay active for too long. Profile revocation means deleting an agent's access profile in the broker. The underlying service key is unchanged. Every other agent using the same service continues working. The revoked agent gets a permission denied response on its next credential request.
Profile revocation is the reason to use a credential broker. It makes revocation cheap enough to actually do — so you do it routinely rather than only in a crisis.
For the full credential lifecycle — provisioning, scoping, auditing, and revoking — see AI agent credential management. For how to think about the specific permission dimensions within each profile, see AI agent permissions.