No. The deciding factor is separation: whoever acts must not be whoever grants the authority to act. An agent that can widen its own permissions has, in effect, no permissions at all. It may request a change, with evidence, but the change is made by people, through change control, and recorded against their names.
Why is this a hard line rather than a judgement call?
Every other control assumes the bounds are fixed while the agent works. Role scope, depth, the customer's limits and the certificate all describe what the agent may do. If the agent can edit any of them, each becomes a suggestion it can revise when it meets an obstacle.
This is not about whether a given model would misuse the ability. A model can be manipulated by content it reads, can misjudge a situation, or can follow an instruction that looked legitimate. Relying on the model to decline is relying on its own restraint, which is why a model's own guardrails cannot govern an AI agent.
What are the indirect ways an agent could change its permissions?
Direct edits to an access system are the obvious route and the easiest to block. The indirect routes are where most gaps sit.
| Route | Example | Control |
|---|---|---|
| Write access to its own configuration | Agent can edit the file or store that holds its scope or limits | Configuration is read-only to the agent's identity |
| Access-request workflows | Agent raises a ticket that auto-provisions access on submission | Requests from agent identities always need human approval |
| Shared credentials | Agent uses a service account that also has admin rights | Each agent has its own identity with only its own rights |
| Another agent | Agent asks an orchestrator or admin agent to grant access | No agent holds rights over another agent's permissions |
| Its own brief or instructions | Agent can rewrite the instructions that describe its role | Brief changes go through change control |
Our guide on how to give an AI agent its own identity in your access management system covers the identity side of this table in detail.
What may the agent do, and what stays with people?
| The agent may | Stays with people |
|---|---|
| Notice that it lacks access for a task and say so | Deciding whether the access is appropriate |
| Draft a change request with the refused cases as evidence | Approving the change |
| Stop or hold work it cannot do within current bounds | Making the change in the access system |
| Report when it holds access it does not seem to use | Removing unused access |
The last row is worth adopting. An agent is well placed to notice that it has write access to a system it only reads. Reporting that is useful; removing it itself is still a change and still belongs with people.
What does this look like in practice?
Take a bank's operations team running an agent that reconciles card settlement files at depth 3. A new settlement file format arrives, and the agent cannot read one field because it sits in a system it has no access to. Its work on those items is refused, filed with the reason "outside role scope".
The agent drafts a change request: which system, which field, read-only, why, and the twenty cases refused for lack of it. The process owner reviews and agrees. Security grants read access to that one field for the agent's own identity, with a review date. The change is recorded in the change log, and because a new source has been added, the capability is re-tested on real cases before the agent resumes those items at depth 3.
Which controls make the answer hold?
- Own identity per agent, with no rights over any access system, configuration store or other agent.
- Human approval on every access request raised by or for an agent identity.
- Permissions that expire, so even a correctly granted right does not outlive its purpose; see why an AI agent's permissions should expire.
- A change log recording who requested, who approved, what changed and when; the AI agent change log template gives a format.
- Periodic access review comparing each agent's rights with its capability list.
Where Pryme fits
In Pryme, an agent's depth and certificate are set by people and by Attest evidence, not by the agent, and the agent's role sets a ceiling. Role scope, the customer's limits and the platform guardrails sit outside the agent's reach. Each verdict is filed in an append-only record, so a refusal for lack of access is visible evidence for a change request. More in our guide to agent governance.
Questions people ask
Can an agent lower its own permissions?
It can choose not to act and hold work for a person, which is always allowed. Changing the permission record itself, even downwards, is still a change made by people.
What about orchestrator agents that assign work?
An orchestrator coordinates within the bounds each agent already has. It can route work but cannot grant another agent rights it does not hold.
Does a failed certification change permissions automatically?
It should drop the agent's depth automatically, without anyone's approval. Tightening triggered by evidence is safe to automate; widening never is.