Admin rights let an agent do anything the system can do, which means its bounds exist only on paper. If an agent holds an administrator role, no limit you write can be enforced at the system it touches. Grant named capabilities instead, each at a set depth, so every action is checked, decided and recorded before it happens.
Why do agents end up with admin rights in the first place?
Usually by accident and under time pressure. A team builds a pilot, the agent needs to read records, create notes and update a status field, and the quickest way to make all three work is a service account with full rights. The demo runs. Nobody goes back to narrow the account before the pilot becomes production.
The integration itself pushes in the same direction. Many business systems expose coarse roles: viewer, editor, administrator. If the agent needs one action that only editors or administrators can perform, the whole role comes with it. A team connecting an agent to a case management system may find that the only role allowed to attach documents is also allowed to delete cases, reassign them and change retention settings.
There is also a belief that the agent's instructions will keep it in line. The prompt says it only updates status fields, so why worry about what the account could do? That belief is the root of the problem.
What actually goes wrong when an agent holds admin rights?
The agent's bounds stop meaning anything. You may have decided that the agent drafts case notes for a person to approve, at depth 2. But if its account can write directly to the case record, the only thing holding it at depth 2 is the agent choosing not to go further. That is a preference, not a control.
Three failure modes follow. The first is error: the agent misreads an instruction and takes an action its role never included, such as closing a case instead of annotating it. The second is manipulation: text inside a document the agent reads tells it to do something else, and the account lets it. Excessive agency of this kind is one of the risks the OWASP Top 10 for LLM Applications lists. The third is drift: over months, people ask the agent to do slightly more, it can, and its real scope moves away from the scope anyone approved.
In all three, the record is weak too. If the agent acted through a broad role, the system's own audit log shows an administrator made a change. It does not show which capability the agent was using or whether that capability was ever granted.
Why is a role the wrong unit for agent authority?
A role bundles many actions together because that is convenient for administering people. A person with an editor role is trusted to use judgement about which of those actions to take. An agent's authority should not rest on that kind of judgement. It should rest on a specific grant for a specific action, and a depth the agent has proven on evidence.
The right unit is a capability: read a case, attach a document, draft a note, change a status, close a case. Each capability needs its own depth. An agent might read cases freely, draft notes for a person to send, update status fields on its own within set rules, and have no grant at all to close or delete.
| Capability | Admin role grants | Named grant gives |
|---|---|---|
| Read case | Yes | Depth 1 |
| Draft case note | Yes, and writes it directly | Depth 2, a person sends |
| Update status field | Yes, any field | Depth 3, named fields only, within rules |
| Close case | Yes | Not granted |
| Delete case or change retention | Yes | Not granted |
The left column is what the account can do. The right column is what the business decided. Only the right column can be checked at the moment of action.
How do you move an agent from admin rights to named capabilities?
Start by listing what the agent actually does. Not what its role allows, but what it has done over a few weeks of work. Most agents use a small fraction of their rights. That list becomes the first draft of the capability grant.
Next, set the agent's depth based on evidence, not on what the agent currently does. If it has been writing directly to case records but nobody has scored those writes, the honest depth is 2 until the evidence exists. That will feel like a step backwards. It is a step towards authority you can defend.
Then narrow the account itself. Where the connected system supports fine-grained permissions, give the agent's identity only the actions it needs. Where it does not, put a layer between the agent and the system that checks each call against the capability grant and refuses anything outside it. For agents that build case files in a case management system, this usually means separate grants for reading, attaching and drafting, with filing left to a person.
What does it cost to give up the admin role?
More integration work, at least at first. Someone has to map capabilities, configure narrower permissions or build the checking layer, and handle the cases where the agent now gets refused because a capability was never granted. Those refusals are useful, because they show where the grant is too narrow or where the agent is being asked to do the wrong work, but they take time to work through.
There is also an operating cost. Each new capability needs its own decision and its own evidence before it is granted. Teams used to switching things on will find this slower.
The trade is worth making because the alternative fails quietly. An agent with admin rights works perfectly until the day it does something nobody approved, and then the record cannot even say which capability it thought it was using. Most of an agent's work is routine; as we argue in the uneventful case is the common one, the controls exist for the rare day that is not.
What should you check in your own estate this week?
Look for agent accounts with administrator, owner or superuser roles in any system. Look for agents that share an account with a person or with each other. Look for any agent whose grant you cannot describe as a list of named capabilities with a depth against each. Each of these is a place where your bounds are not enforced, whatever your policy says.
The principle underneath is the one in our guide to agent governance as a bound, not a model: a limit counts only if it is checked when the agent acts. Admin rights make that check impossible.
Where Pryme fits
Pryme grants authority per agent, per customer, at a depth set by evidence from Attest and capped by the role's ceiling. Every call an agent makes to a connected system is checked against role scope, certificate, sources, the customer's limits and the platform guardrails before it runs. An action with no grant is refused, and the verdict and the deciding bound are filed.
Questions people ask
Is read-only admin access acceptable for an agent?
It is safer than full admin access but still broader than needed. Read access to everything exposes data the agent's job does not require, which raises privacy and confidentiality risks. Grant read access to the records and fields the capability needs.
What if the connected system only offers an admin role for the action we need?
Put a checking layer between the agent and the system that allows only the named action and refuses everything else, and record each call. Raise the gap with the system's owner as well, because a person given that role would carry the same excess.
Can an agent request more rights when it needs them?
It can flag that a task needs a capability it does not hold, and that should create a held item for a person. It should never be able to grant itself the right, because an agent that changes its own permissions has no bounds at all.