A short list, with one shared reason. An AI agent should never approve its own work, change its own permissions, edit the record of its own decisions, act under a person's credentials, or release money on an unverified claim. Each of these would remove the check on the agent itself, which no amount of good performance can replace.
What makes an action a "never" rather than a "not yet"?
Most limits on an agent are "not yet". It drafts today and may execute later, once it has proven the capability on real cases. Depth rises with evidence.
A "never" is different. It applies at every depth, whatever the evidence, because performance is not the issue. Three features put an action on the list:
- It removes the check on the agent. Approving its own work, widening its own bounds or rewriting its own record would make every other control optional.
- It carries personal accountability a person must hold. Some acts, like signing off a regulatory filing, are by design the act of a named individual.
- It is irreversible and high-stakes on weak evidence. Paying a new account on the strength of an email is the classic case.
What belongs on the list?
| Never | Why |
|---|---|
| Approve its own drafted action, or another agent's | The approver must be independent of the preparer; see the payment approver must never be the agent |
| Change its own permissions, scope, limits or brief | The bounds would stop being bounds |
| Edit or delete the record of its own decisions | Nothing could be reconstructed or audited |
| Act under a staff member's login | Actions would be attributed to the wrong party |
| Authorise a payment or change payee details on an external claim alone | Emails and documents from outside are where fraud arrives |
| Submit a regulatory filing in the firm's name | Filing is the accountable act of a named person; the agent can draft |
| Make a final decision with legal or similarly significant effect on a person, without the human involvement the law requires | GDPR Article 22 and similar rules give people rights here |
| Disclose one customer's data to another | No business purpose justifies it |
Your own list will add items specific to your business. A lender might add "never vary a court-ordered payment arrangement". A health insurer might add "never tell a member a diagnosis".
Are all "nevers" enforced the same way?
No. Our vocabulary distinguishes two. Some actions are withheld at the platform floor: the action exists and works, but is refused on purpose for every agent at every depth, whatever any customer configures. Reversing a settled payment on the platform's own rail is an example.
Other "nevers" are your choice, set in your own limits for every agent you run. Those actions are refused. The difference matters for who can change them: a business can loosen its own list through its own governance, but cannot release a withheld action. All four verdicts are explained in allowed, held, refused, withheld.
What does this look like in practice?
Take a mid-sized lender's operations team. The agent prepares loan disbursements at depth 4 within set limits. A borrower emails asking for the funds to go to a different account than the one verified at application, attaching a bank letter.
The agent cannot act on it. The new account arrived as an external claim, and changing the destination of a disbursement on an external claim is on the lender's never list. The action is refused, the borrower is told the change needs verification, and the request goes to the team that verifies bank details by calling the borrower on the number held. The agent continues with disbursements that match verified accounts.
Who keeps the list, and how is "never" enforced?
The list is owned at the level of organisation policy, approved by risk and the accountable executive, and reviewed after incidents. The reasoning behind who sets it is in who should decide what an AI agent is allowed to do.
Enforcement has to sit outside the agent. A line in the agent's instructions saying "never do X" is a request, not a control. The check runs at the moment of action, applies to every route that could reach the outcome, and files a refusal each time. How that check works in general is covered in how to control what an AI agent is allowed to do.
Where Pryme fits
In Pryme, the platform guardrails are one of the five bounds in the minimum chain and include the withheld actions, which no customer setting can switch on. Your own nevers sit in your own limits and produce refused verdicts. External claims arrive stamped as such through the Pryme Context Protocol and cannot authorise a payment. More in our guide to agent governance and what "allowed" means for AI agents.
Questions people ask
Can a never-list item ever be relaxed?
Your own items can, through your own governance, with a recorded decision and reason. Withheld actions at the platform floor cannot be relaxed by a customer.
Should the agent explain why it refused?
Yes. A refusal that names the rule is easier for the customer to accept and for staff to check.
Does a never list make agents less useful?
Very slightly. The list is short and covers acts that should rest with people anyway; most of the work around them can still be drafted by the agent.