An agent's permissions decide the worst thing it can do on a bad day. Managing them well means granting little, granting late and taking back fast.
This page covers the five kinds of permission agents hold, how to scope each one, and why web page permissions from an AI agent allow list belong on the list.
A classic service account does the same thing every time, so its permissions can be generous without much risk. An agent decides what to do next.
Every permission it holds is a permission it may use in a way nobody predicted. That makes least privilege far more important.
An agent may use a permission for a task it was never meant to do.
Injected instructions can direct it to use what it holds.
New tools arrive weekly, each with new permissions.
Web access is a permission too, often forgotten.
Permission reviews often cover only the first two. The last three cause many real incidents.
List all five for every agent, even when the answer is "none".
Scope by task, not by agent. The same agent needs different permissions for different jobs.
The right-sized column is usually enough for the task and far smaller than what agents are given by default.
| Permission type | Too broad | Right-sized |
|---|---|---|
| System access | Admin role in the CRM | Read contacts in one region |
| Data access | All customer data | Company names and public fields |
| Tool access | Every tool on a server | Search and read tools only |
| Web access | Any website | Pricing, documentation and about pages |
| Action rights | May sign up and buy anywhere | No actions; one checkout exception with approval |
Web access and action rights are expressed as page types. An AI agent allow list classifies 28 page types on 40M+ domains, so "pricing pages only" becomes an enforceable rule.
Permissions should move through a clear lifecycle, with a record at each step.
Skipping step 3 is how agents collect permissions nobody remembers giving.
The owner asks for a permission and names the task that needs it.
Grant the smallest scope, with an end date or a short lifetime.
Every 90 days, and after any tool or model change, confirm each permission is still used and still needed.
Remove unused permissions, and everything at retirement, on one date.
Standing permissions are always available, including to an agent that has gone wrong. Just-in-time permissions exist only during the task.
Most identity platforms can issue short-lived, task-scoped tokens today. The work is deciding the scopes, not building new systems.
Identity reviews check what an agent can reach inside. They rarely check what it can do outside, on other people's websites.
Add a web permission field to every permission review: which read page types, and which action exceptions, if any.
Drift is permissions growing faster than tasks. These signals show it early.
Most of them can be found automatically from the identity platform and proxy logs.
Permissions not used in 30 days.
Grants with no end date.
New tools added without a review.
One key used by several agents.
An agent running under a person's account.
No page-type limits at all.
Different permission types sit in different systems. Name an approver for each.
The agent owner always requests. The owner of the system being accessed always approves.
| Permission type | Requested by | Approved by | Stored in |
|---|---|---|---|
| System access | Agent owner | System owner | Identity platform |
| Data access | Agent owner | Data owner | Data access layer |
| Tool access | Agent owner | AI platform team | MCP gateway |
| Web access | Agent owner | Network security | Agent policy file |
| Action rights | Agent owner | Security and budget owner | Policy exceptions |
A composite example of what a real review finds.
Each finding took minutes to fix once it was visible.
CRM write access unused for 90 days. Reduced to read-only.
Still needs company fields only. No change.
Two tools added last month without review. One removed, one approved.
No page-type limits. Restricted to pricing, documentation and about pages.
No exceptions needed. Signup and checkout stay denied.
Four of five permission types changed. That is normal for a first review.
Vendor agents often inherit the permissions of the user who switched them on. That is usually far too much.
Check this before switching any vendor agent on for a whole team.
Does it act with the user's full rights, or its own?
Scope OAuth grants to the minimum and set expiry.
Browser-based vendor agents pass your proxy's page policy.
Include vendor agents in the 90-day review.
Each one removes access agents almost never need.
None of them requires new software, only decisions and settings.
Signup, checkout, upload and posting pages, for every agent.
Anything unused for 30 days.
To every exception and temporary grant.
One identity per agent.
Move agents off people's accounts.
Report these monthly for every agent and every owner.
Rising unused permissions or falling web scope coverage are early warnings of drift.
Should fall after each review.
Share of grants that expire automatically.
Agents with page-type limits in place.
Agents reviewed within 90 days.
Short definitions for readers new to agent permissions.
Use them in requests and reviews, so approvers and owners mean the same thing.
Only the access a task needs, nothing more.
Access that exists only while a task runs.
Access that is always available.
Permissions growing faster than tasks.
Permission to sign up, buy, post, upload or send.
What a URL is on its site, such as pricing or checkout.
Use these as defaults, then narrow further for your own tasks.
Every row keeps action rights at "none" except where a named exception exists, which is the safest starting point.
| Agent | Systems | Data | Tools | Web | Actions |
|---|---|---|---|---|---|
| Research | None | Public | Search, browse | Pricing, docs, blog, press | None |
| Support answers | Help desk read | Internal | Help desk, browse | Help centre, status, docs | None |
| Procurement | ERP read | Supplier contracts | ERP, browse | Pricing, legal, security | Checkout on one supplier, with approval |
| Coding | Dev repository | Source code | Repo, tests, docs fetch | Documentation | None |
| Sales research | CRM read | Company fields | CRM, browse | About, leadership, press | None |
| Operations | Monitoring read | Metrics | Runbooks, tickets | Status pages | Ticket creation, internal only |
Tight permissions can feel like friction. These answers usually help.
Share the permission sprawl example with builders. It shows why narrow grants are a favour to their own future selves.
It needs flexibility in how it reasons, not in what it can touch.
Task templates with pre-approved scopes make most requests instant.
Start narrow, log denials, and widen where denials show a real need.
Until the day it does something admin rights allow and nobody wanted.
Retired agents keep working keys more often than anyone expects. One retirement checklist prevents it.
Run it on the retirement date itself, not "soon after" or "next sprint".
In the identity platform, so no new tokens are issued.
API keys, OAuth grants and database users.
In the MCP gateway and tool allowlists.
The proxy denies all traffic from the retired agent ID.
A week later, confirm nothing ran under the old identity.
Keep these ready for every agent, in one place.
If any item is missing, the permission cannot be shown to be under control.
All five types, in one view.
Who asked, who approved, when, and why.
Dates, findings and changes.
Proof that denied permissions were really enforced.
Assistants that act for one person are a special case. They borrow that person's rights, which are usually far wider than any single task needs.
Treat delegation as a narrow loan, not a copy of the person's access.
Delegate only the systems and data the task touches.
The person approves each kind of access, not "everything".
A delegated agent should not sign up or buy in the person's name without asking.
Delegations end when the task ends, or within hours.
For leadership, reduce the five types to three numbers.
All three should be zero, and staying there is the goal.
Admin-level rights anywhere. Target: zero.
Able to sign up, buy or post anywhere. Target: zero.
Agents past their 90-day review. Target: zero.
A composite example of how permissions grow when nobody reviews them.
No single change looked dangerous. Together they turned a read-only helper into an agent that could act anywhere.
Read access to one system, a search tool, pricing pages.
Write access added "temporarily" for a data clean-up. Never removed.
A third-party server added for enrichment, with its own broad token.
Page limits removed to "fix" a blocked research task.
The agent can now write data, call unreviewed tools and sign up anywhere.
Each change would have been caught within a quarter, with an end date attached.
No single tool holds all five. Link them by agent ID so a review can see everything at once.
Without that link, a review sees five partial pictures and misses the combination that makes an agent dangerous.
System access and credential lifetimes.
Data classes and masking.
Tool and server approvals.
Web page types and action exceptions.
The single place that points to all four.
The honest fine print — the same two assumptions we publish, plus two operational ones
Page types for 40M+ domains, enforced before each request.
