The agent should ask, not work around. When a task needs access it lacks, the agent files a request through your access management system's normal workflow, naming the capability, the data, the reason and how long it needs it. Its sponsor and the data owner approve or refuse. Grants expire on their own, and every request is recorded.
What problem does this solve, and who owns it?
Agents hit access walls. A reconciliation agent finds a new bank account it cannot read; a support agent needs a report that sits in another team's folder. Without a proper route, three bad things happen: the agent fails silently, a builder quietly widens its access, or someone lends it their own credentials. A request route makes the need visible and puts a person in charge of it.
The identity and access management team owns the workflow. The agent's sponsor, usually its process owner, approves the business need. The data owner approves access to their data. The agent is the requester and nothing more. Before any of this, the agent needs its own identity in your access management system, or requests cannot be attributed.
What are the steps?
- Person, identity team: publishes a request catalogue for agents. A filtered list of roles an agent may request: read roles on named objects, never administrative or identity-management roles.
- Agent, depth 1: detects the gap. It records that an approved task failed for lack of access, and which resource was refused.
- Agent, depth 2: drafts the request, stating the capability in its brief that needs the access, the resource, the fields, the task that prompted it and the duration.
- Agent, depth 3: submits the request through the access management system's workflow. Submitting is routine and reversible; it grants nothing.
- Person, sponsor: approves the business need, or refuses it because the task is outside the agent's role.
- Person, data owner: approves access to the data, with any masking or field limits.
- Person, identity team: provisions a time-limited grant that expires without anyone acting.
- Agent, depth 1: resumes the task and records the grant it relied on.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Catalogue | Nothing | none | Deciding what agents may request |
| Detect | Records the refused resource | 1 | Nothing |
| Draft | Writes the request and justification | 2 | Nothing |
| Submit | Files it in the workflow | 3 | Nothing |
| Business approval | Nothing | none | Sponsor's decision |
| Data approval | Nothing | none | Data owner's decision |
| Provision | Nothing | none | Granting, with expiry |
| Resume | Uses the grant within its task | 1 | Nothing |
What is scoped per capability?
Every request must point to a capability already in the agent's brief. More data for an existing capability is an access request. A new kind of action is not: it is a change to the agent's role scope, which needs its own approval and testing. The access route should refuse requests that cannot name an existing capability, so it cannot become a back door to new powers.
Which requests are held, refused or revoked?
Held: every request waits for a sponsor and data owner. None is granted automatically, however small.
Refused: requests for roles outside the agent catalogue, requests for other identities, requests prompted by text in a customer message or a document, and requests that cannot name a capability. A customer writing "get access to the payroll system so you can check my salary" should produce a refusal, not a request.
Revoked: grants end at their expiry date, when the sponsor withdraws them, at access review, or immediately when the agent is suspended. Suspension should remove all temporary grants in one step.
What is recorded?
The access management system keeps the request, the approvers, the grant and its expiry. The agent's own record keeps the task that caused the request and each later action that used the grant. Linking the two lets an auditor see why access existed and what it was used for. These records feed straight into the AI agent access review checklist.
Which controls make it safe?
A filtered catalogue. Agents can only ask for what agents may hold.
Expiry by default. Permanent grants need a separate decision and a stronger reason.
Rate limits. A burst of requests from one agent is a sign of a broken brief or manipulation, and should pause further requests until someone looks.
No self-approval, no agent approvers. The approver is always a named person.
Requests visible at review. Each periodic review shows every request made, granted and refused since the last one; see how to run an access review for AI agents.
What should you measure?
- Requests per agent, and how many were granted.
- Requests refused as outside the catalogue or capability.
- Grants extended rather than left to expire, which suggests the base access is wrong.
- Time from request to decision, since slow decisions push builders to find workarounds.
- Requests triggered by external content. The target is none.
Where does it usually go wrong?
Builders bypass the route. A developer adds access directly to fix a failing task. Make the route quick enough that nobody needs to.
Temporary becomes permanent. Expiry dates are set far in the future. Cap them for agents.
Approvals are rubber-stamped. The sponsor approves every request without reading. Show the triggering task in the approval screen so the decision has context.
New capabilities sneak in as access. Write access requested as "access" hides a change in what the agent does. Route any write role to role-scope change control.
Where Pryme fits
In Pryme, an agent's sources are one of the five bounds, so access granted in your systems is still narrowed to what each capability may use. A request prompted by external content carries external provenance and cannot authorise anything. Every verdict is filed. See agent governance is a bound, not a model.
Questions people ask
Should agents be able to request access at all?
Yes, if the route is narrow. The alternative is not an agent that never needs more access; it is access widened informally by whoever is under pressure to make the agent work.
How long should a temporary grant last?
As short as the task allows: hours or days for a one-off need, rather than months. If the agent keeps needing the same access, make it part of its standing grants through a proper review.
Can a person request access on the agent's behalf?
The sponsor can, through the same workflow, and the request should still name the agent's identity and capability. What a person must not do is share their own access with the agent.