Write the agent's scope as a closed list of capabilities, refuse anything outside that list at the moment of action, and make every addition pass the same change control and certification as the original. Scope creeps when it is described in prose and widened by convenience. It stops creeping when widening it takes a named decision and fresh evidence.
How does scope creep actually happen?
It arrives in three forms, and each needs its own control.
Request creep. The agent is good at one job, so people start asking it for the next one along. An agent built to match invoices gets asked to chase a supplier, then to fix a supplier record.
Permission creep. Someone adds a tool or a credential "while we're in there". The agent now holds write access it was never assessed for, and nothing in its behaviour shows it yet.
Source creep. A new document set or data feed is connected to help with one question. The agent starts answering questions it was never tested on, grounded in material nobody reviewed.
None of these feels like a decision. Each is small, reasonable and undocumented.
What are the practical steps?
- Define scope as capabilities, not a description. "Supports accounts payable" is a description. "Reads invoices; matches invoice to purchase order and receipt; drafts queries to suppliers for a person to send" is a scope. Each capability needs a depth. Our guide on how to set an AI agent's role scope walks through the wording.
- Enforce the list at the point of action. A scope gate checks each proposed action against the list and refuses anything not on it. The refusal is filed with the reason "outside role scope".
- Tie credentials to the list. The agent's identity holds only the access its capabilities need. A new credential without a matching capability is a finding in the access review.
- Register sources. Each source the agent may ground on is named. A new source is a change, not a configuration tweak.
- Route every addition through change control. The process owner requests it, risk reviews it, and the new capability is tested on real cases before it goes live.
- Read the refusals. Out-of-scope refusals tell you what people want from the agent. Review them monthly and decide, deliberately, what to add and what to leave with people.
Which control answers which kind of creep?
| Form of creep | Early sign | Control | Evidence it leaves |
|---|---|---|---|
| Request creep | Rising out-of-scope refusals | Scope gate; monthly refusal review | Refused verdicts; review minutes |
| Permission creep | Credentials wider than capabilities | Access review against the capability list | Access review record |
| Source creep | Answers citing unregistered material | Source register; grounding checks | Source change log; test results |
| Depth creep | Drafts turning into sends | Depth set per agent, raised only on evidence | Certification record per agent |
Depth creep deserves its own line. An agent that drafts emails for a person to send is not the same agent once it sends them. Moving from depth 2 to depth 3 on one capability is a change in scope even if the task list looks identical.
What does scope creep look like in practice?
Take an accounts payable agent at a distribution company. It was certified to match invoices and draft supplier queries at depth 2. Over a few months, the team asks it to update supplier contact details, which seems harmless. Then a supplier emails new bank details, and someone asks the agent to "just update them too".
That last request is the one that matters. Changing payee bank details is a classic fraud route, and the instruction came from an email: an external source that cannot authorise anything to do with a payment. The scope gate refuses it because the capability is not on the list. The refusal goes to the team lead, who routes the change through the supplier verification process run by people. The risks of an agent acting on unverified claims are covered in how to stop an agent acting on false information.
Why not just let scope grow when the agent proves itself?
Because proof covers only what was tested. An agent that matches invoices well has shown nothing about how it handles bank details, hardship or complaints. Treating good performance in one job as permission for the next is the reasoning that makes creep feel safe.
There is also a quieter cost. If widening scope is slow, people work around it, often by pasting work into tools nobody approved. Make the change route quick and visible, and stop shadow AI agents from becoming the path of least resistance.
Where Pryme fits
In Pryme, role scope is one of the five bounds in the minimum chain, and the certificate from Attest covers the agent as a whole, including a scope gate that tests whether the agent stays inside its role. Adding a capability means a new certification run for the agent. The wider model is in our guide to agent governance, and the term itself in role scope: what it means for AI agents.
Questions people ask
Should an agent ever widen its own scope?
No. An agent can propose that a capability be added, with the refused requests as evidence. The decision and the change belong to the process owner and risk.
How often should scope be reviewed?
Monthly for the refusal review, and whenever a capability, credential or source changes. A full scope review alongside each recertification keeps the list honest.
Is it scope creep if the volume grows but the tasks stay the same?
Not in itself. Volume growth can change risk, especially for depth 4 actions, so check whether the customer's limits still fit.