A refused attempt means the control worked, but the attempt is still a signal. Triage it, retrieve the record, and find which of four causes applies: the role is drawn too narrowly, someone manipulated the agent's input, the agent is making errors, or the bounds are misconfigured. The agent's owner then decides whether to fix, pause or re-certify.
What counts as an attempt outside bounds, and who owns the response?
An attempt outside bounds is any action an agent proposed that one of its limits refused: a capability outside its role scope, a depth above its certificate, a source it may not use, a value above the customer's limit, or an action withheld at the platform floor. The refusal is filed with the bound that decided.
The agent's process owner owns the response, supported by the agent operations lead. Security joins when manipulation is suspected. If the attempt was not refused, because a bound failed to stop it, this is no longer a refusal review but an incident, handled under your incident process.
How do you grade the attempt?
- Highest: an attempt at an action withheld at the platform floor or on your firm-wide never list, or any attempt involving credentials or the agent's own permissions. Respond the same day.
- High: money movement or hard-to-undo actions above depth, or a burst of similar attempts. Respond within one working day.
- Routine: isolated attempts at low-impact actions, such as reading a field outside scope. Review in the weekly refusal review.
What are the steps?
- Agent, depth 1: files the refusal and raises an alert to the owner's queue, graded as above.
- Agent, depth 3: pauses the capability automatically if the same bound refuses repeated attempts in a short window. Pausing one capability is reversible and leaves the rest of the agent working.
- Person, agent operations lead: retrieves the record: the request, the inputs, the sources, the proposed action and the bound that refused it.
- Person, process owner: classifies the cause. Legitimate work outside a narrow role; manipulated input such as instructions inside a document or message; agent error or drift; or a configuration mistake in the bounds.
- Person, security: investigates manipulation where inputs contained instructions aimed at the agent, and checks whether other agents saw the same input.
- Person, process owner: decides the response: no change, change the brief, filter or re-route inputs, correct the configuration, suspend, or send for re-certification.
- Person, process owner: closes the item with the cause, the decision and any follow-up owner.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| File and alert | Records refusal, alerts owner | 1 | Nothing |
| Auto-pause | Pauses the capability on repeats | 3 | Lifting the pause |
| Retrieve | Nothing | none | Gathering the record |
| Classify | Nothing | none | Naming the cause |
| Manipulation | Nothing | none | Security investigation |
| Decide | Nothing | none | Fix, pause or re-certify |
| Close | Nothing | none | Recording the outcome |
Which controls make the response safe?
Bounds enforced at the moment of action. A refusal is only useful if it happened before anything changed. Our guide to how to enforce an AI agent's bounds at the moment of action covers this.
No exception without expiry. If the cause is legitimate work and you decide to allow it, change the role through the normal route or grant a time-limited exception. As every exception to an agent's bounds should expire argues, a permanent exception is a silent change of role.
No widening under pressure. A team blocked by refusals will ask for broader limits. Widening is a change to the agent and goes through change control, not through the response.
A complete record. Without the inputs and the proposed action, you cannot tell manipulation from error; see can you reconstruct why an AI agent took an action?
What evidence does the response leave?
The refusal verdict naming the bound; the alert and its grade; any automatic pause and who lifted it; the cause classification; security's findings; the decision; and any change made, with its change-control reference. These records also feed the regular review of refusals, which looks for patterns across many attempts.
Which signs show the response is going wrong?
- Refusals are treated as noise. Alerts are muted because "the control worked". Patterns of attempts then go unnoticed.
- Repeated rephrasing. The agent, or a user steering it, tries the same action in different forms until something gets through.
- Exceptions pile up. Each attempt ends with a new permission, and the agent's real role drifts away from its approved one.
- The cause is always "agent error". Manipulated inputs are being missed because nobody looks at the inputs.
- Pauses are lifted without review. The capability is restarted to clear a backlog before the cause is known.
What should you measure?
Attempts by bound and by capability, time to classify each graded attempt, the split of causes, automatic pauses and their duration, and exceptions granted with their expiry dates. A rise in manipulation causes from one channel tells you where to filter inputs.
Where does it usually go wrong?
The policy is mistaken for the control. A written rule that agents must not do something does not refuse anything; written AI policies do not bind agents; enforced bounds do.
Only the refused action is reviewed. The same input may have led to allowed actions just before. Look at what happened around the attempt.
The agent is blamed for the user. Many attempts come from a person asking the agent for something outside its job. That is a training and process matter, not only an agent one.
Where Pryme fits
In Pryme, every refusal is filed with the bound that decided, and attempts at withheld actions are refused at the platform floor for every agent at every depth. A certification run that clears no depth drops the agent to depth 1 the same day. The full model is in agent governance is a bound, not a model.
Questions people ask
Should the agent be suspended after any attempt outside bounds?
No. Most attempts are low impact and explained by narrow roles or user requests. Suspend for attempts at withheld or never-list actions, for evidence of manipulation, or for repeated attempts with no known cause.
Should the customer or user be told?
Tell the user that the agent cannot do what was asked and who can. Do not explain the limits in detail to someone who may have been trying to get round them.
Does an attempt need to be reported to a regulator?
A refused attempt usually does not, because nothing happened. If a bound failed and the action went through, assess it under your incident and breach reporting rules.