Agent Permissions: Least Privilege for Software That Acts

What this article gives you

By the end, you will have a concrete permission model for a first production agent: how to scope credentials, what a safe starting allowlist looks like, how to reason about blast radius, and how to expand access deliberately as the agent proves itself. This is the permissions layer of getting your first agent live, the part that determines whether a bad day is a recoverable incident or a permanent data loss event.

Why agent permissions are not just user permissions with a different name

When you grant a user broad access, that user reads, thinks, and acts in a sequence measured in minutes. When you grant an agent the same access, it acts in a sequence measured in milliseconds, across potentially thousands of steps per hour, in combinations no human reviewer anticipated when the access was approved.

The agent inherits whatever you give it and spends it freely. It does not have professional intuition that says “this seems wrong, I should check first.” It has a goal and a set of available tools, and it will use both to completion. That is the property that makes agents useful, and it is exactly the property that makes over-permissioning dangerous.

Consider what Spotify built with Honk, an internal coding agent running in Kubernetes pods. Engineers mention the agent in Slack mid-conversation and it autonomously works on problems before returning pull requests. That workflow is productive precisely because the agent’s tool access is bounded: trusted tools, a scoped CI/CD surface, and nothing outside the defined boundary. The autonomy is safe because the permission envelope is small.

The 31% of enterprises that had at least one agent in production by Q1 2026 mostly started by scoping a narrow task first. The ones that skipped that step are the majority inside the 88% of agent pilots that fail to reach production. Permission sprawl is one of the cleaner reasons a pilot stalls: something goes wrong that should not have been possible, and confidence in the whole program collapses.

This is also why picking the right first use case matters so much before you ever think about credentials. The use case determines the minimum permission set you need, and a well-chosen first task keeps that set small.

The least-privilege starting posture

flowchart TD
    A[Define task scope] --> B[List required tools only]
    B --> C[Create scoped service account]
    C --> D[Read-only access first]
    D --> E{Needs to write?}
    E -- No --> F[Deploy with read access]
    E -- Yes --> G[Add write to specific resources only]
    G --> H[Log every write action]
    H --> I[Review after first 100 tasks]
    I --> J{Error rate acceptable?}
    J -- Yes --> K[Maintain or expand scope]
    J -- No --> L[Narrow scope further]

Start with three concrete constraints before the agent runs its first production task.

Narrow tool allowlists. List every tool the agent needs to complete its defined task. Anything not on that list is not available, regardless of what the underlying API technically exposes. If the agent is summarising support tickets, it needs read access to the ticket system. It does not need the ability to close tickets, reassign them, or modify billing records, even if those actions are available on the same API key.

Scoped credentials per task type. One credential per task category, not one credential per agent. An agent that handles both ticket summarisation and order refunds should carry two separate credentials, each with access only to its own domain. When the refund workflow misbehaves, you revoke one credential without touching the summarisation workflow.

Read before write graduation. Deploy with read-only access and observe. Add write access only after you have confirmed the agent is reading the right things and forming correct intentions. Rakuten’s Claude Code deployment achieved 99.9% accuracy on complex code modifications and cut time-to-market from 24 days to 5 days, but that confidence came after controlled observation periods, not before them.

Blast radius thinking

The question to ask before every permission grant is not “does the agent need this?” but “what is the worst action the agent could take with this access, and is that survivable?”

A survivable worst case is one you can reverse within minutes: a mis-filed document, a wrongly labelled tag, a test email sent to a sandbox. An unsurvivable worst case is one that propagates before you can stop it: bulk deletions, mass customer communications, financial transactions above a threshold, or changes to infrastructure that other systems depend on.

Map your permission grants to that scale. If the worst-case action is unsurvivable, the access should either be removed or gated behind a human approval step. This is not pessimism about the agent’s capabilities. It is a recognition that even a 99% accurate agent, running 1,000 tasks per day, produces 10 errors per day, and one of those errors can be catastrophic if the permission envelope allows it.

For Zapier’s 800-plus internal agents, 89% AI adoption across all employees was achieved without the kind of incident that would have ended the program. That outcome is partly a function of the permission model applied at scale, not just the quality of the underlying model.

You can read more about how runtime governance and pre-deployment review interact when you are designing this layer, and the AI agent governance fundamentals that underpin it.

Service accounts versus user impersonation

Use a dedicated service account for every agent in production. Do not let the agent impersonate a named employee.

The practical reason is audit integrity. When something goes wrong, you need to know immediately whether the action was taken by a human or an agent. An audit log that shows “alice@company.com deleted 4,000 records” cannot tell you which of those deletions were Alice and which were the agent running as Alice. A log that shows “agent-support-tier1 deleted 4,000 records” is immediately actionable.

The second reason is lifecycle independence. When Alice changes roles, her permissions change. If the agent is running as Alice, your agent’s permissions change too, in whichever direction Alice’s new role takes them, without any deliberate decision on your part. A service account changes only when you change it.

Name the service account after the agent’s function: agent-ticket-summariser, agent-refund-processor. That naming convention makes permission audits readable and connects to AI governance best practices that your security team will recognise.

Expanding access as the agent earns trust

flowchart TD
    A[Agent live with minimal permissions] --> B[Collect task completion data]
    B --> C{Error rate below threshold\nfor 4 to 6 weeks?}
    C -- No --> D[Investigate failure patterns]
    D --> B
    C -- Yes --> E[Identify next permission candidate]
    E --> F[Add to allowlist in staging]
    F --> G[Observe in staging for 1 week]
    G --> H{Staging error rate\nacceptable?}
    H -- No --> D
    H -- Yes --> I[Promote to production]
    I --> B

Permission expansion is a deliberate process, not a default. The agent starts narrow and moves outward only when evidence supports it. Track task completions, flag every unexpected action, and set a numeric threshold before you start, such as fewer than 0.5% unintended actions over 500 task completions, before a new action type is eligible for promotion.

Tie this process to your evaluation framework. If you are not yet measuring what your agent actually does in production, the agent evaluation fundamentals and the broader question of how to know your agents are doing their job are prerequisites to meaningful permission expansion. You cannot expand access responsibly without the signal to justify it.

Tools like Prefactor sit in this category, providing the permission boundary and observability layer that makes evidence-based expansion possible, though any approach that gives you per-action logging against a defined allowlist will serve the same function.

Permission boundaries are the cheapest safety mechanism available to you. They require no model changes, no retraining, and no external vendor. They are a configuration decision you can make today, before the agent runs its first task, and they bound every failure mode the agent can produce.

Where to start

Audit the credential you were planning to give your first agent and answer the blast radius question honestly: what is the worst action this agent could take, and can you recover from it in under an hour? If the answer is no, narrow the credential before deployment. Take the agent readiness assessment to work through the full readiness checklist, including the permission layer, before your first agent goes live.