Who can override an AI agent's refusal?

It depends on which bound refused. A refusal under your own limits or the agent's role can be overridden by a named person whose authority covers the action, usually by doing it themselves. A withheld action, refused at the platform floor, cannot be overridden by anyone at the business. Every override is filed with a name and reason.

Why does the source of the refusal matter?

Because each bound belongs to someone. An agent's refusal is not the agent's opinion; it is a bound doing its job. The person who may set that bound aside is the person, or role, who owns it.

Notice how often the answer is "a person does it themselves". Overriding a refusal rarely means handing the agent more authority for one case. It means a person with authority takes the action, under their own name, and the agent stays within its bounds.

When should an override give the agent authority instead?

Occasionally, for a defined category over a set period. A product recall might justify letting the agent issue refunds above its normal limit for that product for two weeks. That is an exception to its bounds, approved by someone who owns the limit, written down with an end date, and filed.

What should not happen is a supervisor telling the agent "just do it this time" in a chat. That is an override without a record, by someone whose authority nobody checked, through a channel the agent should treat as content rather than instruction.

What does this look like in practice?

Take a telecoms provider's support team. A caller asks the agent to read out the last three months of call records. The caller fails one of the security questions. The agent refuses, citing the verification rule, and offers to send the records to the email on the account.

The caller complains and asks for a supervisor. The supervisor cannot override the verification failure through the agent. What she can do is verify the caller herself by another approved method, which she does, then send the records herself. The agent's refusal stands on the record as correct; her action is filed under her name with the verification method used.

A week later the support lead reviews refusals of this type and sees many involve customers who changed phone numbers. That is a reason to change the verification procedure through governance, not to let supervisors override case by case.

What gets recorded?

The original refusal, with the bound that caused it. The override, if any: who, when, under what authority, and the reason. Any exception granted, with its scope and expiry. And whether the outcome was later judged right.

That record is what lets you review whether refusals are well placed. If one type is overridden often, either the bound is wrong or overrides are too easy. Our guide on why refusal is a gate, not a nice-to-have makes the case for keeping that discipline, and a refusal reasons library keeps the wording consistent.

Which controls keep overrides honest?

• Overrides only by named people whose authority covers the action.
• No override through the agent's conversation. Instructions in chat are not authority.
• Exceptions dated and scoped. They expire on their own.
• Override rates reviewed by refusal type, monthly.
• Refusals tested before go-live, so the agent refuses where it should and not elsewhere; see the refusal test cases template.

Where Pryme fits

In Pryme, a refused verdict names the bound that decided, so the right owner is clear. The business can narrow or widen its own limits through its own governance, but withheld actions sit at the platform floor and no customer setting changes them. Attest's refusal gate tests that agents refuse correctly on your own cases. More in our guide to agent governance.