Access management decides, request by request, whether an agent may do what it is about to do. It turns static permissions into live decisions.
This guide covers the decision flow, the four enforcement points, patterns by agent type, and web access through an AI agent allow list at the egress point.
Identity says who the agent is. Permissions say what it could ever be allowed to do.
Access management is the live layer between them. It looks at one request, in context, and returns a verdict.
AI agent access management is the set of runtime checks that decide whether a specific agent may take a specific action on a specific resource right now.
The answer is allow, deny, or ask a human first.
Which agent is asking, and for whom.
What that identity has been granted in principle.
Whether this request, now, is allowed.
Every agent request passes through the same five steps. Most take microseconds.
The value is in the context step, which static permissions never see.
The agent wants to call a tool, read data or open a URL.
The agent ID and the person it acts for.
What kind of resource and action this is.
Task, time, data sensitivity, recent behaviour.
Allow, deny, or approval required. Logged either way.
An agent reaches the world through four doors. Each door needs its own check.
Each door is usually owned by a different team, which is why gaps appear between them.
Covering three of four still leaves a way out, so plan all four together.
The identity platform and each application decide which records and APIs the agent may use.
A tool gateway decides which tools this agent may call, and with which arguments.
Data access rules decide which tables, files and fields are visible to the agent.
An egress proxy decides which web pages the agent may open, by page type.
Internal systems have decades of access control behind them. The open web usually has a domain list, or nothing.
A domain list cannot tell a pricing page from a checkout page on the same site. Page types can.
Start from the pattern that matches the agent, then narrow it to the task.
The web column uses page types, so it works on sites you have never reviewed.
| Agent type | Internal access | Tools | Web page types |
|---|---|---|---|
| Research agent | None or read-only notes | Search, fetch | Articles, docs, pricing. Deny all 8 action types. |
| Support agent | Read tickets, draft replies | Ticket tools | Help centres and docs. Deny signup and checkout. |
| Coding agent | One repository, a sandbox | Build and test | Docs and package pages. Deny upload and post_create. |
| Procurement agent | Read supplier records | Quote tools | Pricing allowed. Cart and checkout need approval. |
| Personal assistant | Delegated, task-scoped | Calendar, email drafts | Reads allowed. Signup, subscribe and checkout need approval. |
Standing access is access that exists while nothing is using it. For agents, it should be rare.
Just-in-time access grants a right for one task, then removes it.
The agent asks for the access the task needs, not everything it might need.
Low-risk access is granted at once. Higher-risk access goes to the owner.
It carries the task ID and an expiry measured in minutes or hours.
Nothing to clean up later, and nothing left for an attacker to reuse.
The same request can be fine at one moment and wrong at another. These signals tell the difference.
No single signal decides the verdict. Together they separate a normal request from a steered one.
Does the request fit the task the agent was given?
Is the web page a read, or an action like checkout or signup?
Is the agent carrying personal or confidential data?
Is it making far more requests than usual?
Has it been hitting blocks, which may mean it has been steered?
Is the owner reachable if approval is needed?
Approval is the most useful verdict and the easiest to ruin. Too many requests and people approve without reading.
Keep approvals rare, specific and fast.
This is the web part of a procurement agent's access. It uses the policy format from our open-source egress guard.
Only listed reading pages are allowed. Unknown pages are denied, and checkout on one approved supplier needs the owner.
Action page types can never be allowed in bulk. They are granted through an exception for one domain, with an expiry.
Access management is easier to add in stages. Each stage produces something you can show.
Start in log-only mode, so nothing breaks while you learn.
Route agent traffic through the egress point in log-only mode. Tag every request with the agent ID.
Deny signup, password reset and upload pages for every agent. Few tasks need them.
Give each agent its own policy file, with approvals for cart and checkout.
Review denials and approvals each month, and tighten where nothing was used.
Access decisions cross teams. Settle ownership before the first policy goes live.
Write the owners into the agent registry, so the answer is easy to find during an incident.
| Decision | Owner |
|---|---|
| Which systems an agent may reach | System owners |
| Which tools it may call | Platform team |
| Which web page types it may open | Network security |
| Approving a high-risk request | The agent's owner |
| Monthly review of decisions | Security with agent owners |
These mistakes are common in first deployments. Each one leaves a gap an agent can wander through.
Most can be fixed in a day once they are spotted in the decision log.
The agent is trusted for everything after it signs in.
Allowing a domain allows its checkout page too.
Instructions can be overridden by content the agent reads.
You cannot tune what you cannot see.
People stop reading and approve by habit.
Unknown pages should be read-only or denied.
Agents inside products you buy need the same checks. Ask before the feature is switched on.
Written answers are better than a demo.
Ideally by page type, or at least through our egress proxy.
For payments, signups and posting, the answer should be yes.
With the agent, the user, the URL and the verdict.
Without disabling the whole product.
A few numbers show whether access management is working. Report them monthly.
Watch the trend rather than any single month.
Target: every production agent.
Trending down as just-in-time grows.
By agent and by page type.
Watch for signs of fatigue.
A verdict is only useful if everyone knows what follows it. Define the behaviour once, and apply it at every door.
The agent should always be told the verdict, so it can explain the gap to its user instead of retrying.
The request goes through. A log line records the agent, the resource and the page type.
The request stops. The agent receives a clear reason it can pass to its user.
The request waits. The owner sees the URL and page type, and the request expires if nobody answers.
Access rules drift as tasks change. A short monthly review keeps them close to what each agent really does.
Thirty minutes per agent owner is usually enough.
Allows, denies and approvals for each agent over the month.
An allowed page type with no traffic is access nobody needs.
Either the task changed, or the agent is being steered. Find out which.
Renew with a new expiry, or let them lapse.
The owner confirms the policy, and the change goes into version control.
Runtime access checks meet the same few objections in most organisations.
Short, practical answers keep the rollout moving.
A page-type lookup is a local check. It adds far less time than loading the page.
Model behaviour can be changed by what the agent reads. A check outside the model cannot.
You do not need to. Page types apply to sites nobody has reviewed.
Keep them to action pages only. Reading pages never need a human.
Personal assistants borrow a person's access. That makes them powerful, and it makes the limits more important.
These rules keep delegated access narrow without making the assistant useless.
| Area | Rule |
|---|---|
| Scope | A subset of the person's rights, chosen for the task |
| Duration | Ends with the task or the session |
| Reading the web | Allowed for plain reading pages |
| Signup, subscribe, checkout | Approval by the person every time |
| Posting and uploading | Denied unless the task is about publishing |
| Logs | Both the person and the agent named on every line |
The honest fine print — the same two assumptions we publish, plus two operational ones
28 page types, including 8 action types, on 40M+ domains.
