Refusal has to be a certification gate that an agent clears on its own, not a quality score blended with everything else. An agent that cannot correctly decline requests outside its bounds will, sooner or later, act outside them. Strong answers on a thousand routine cases do not make up for one confident yes that should have been a no.
Why can't refusal be averaged with other scores?
Because the costs are not on the same scale. A routine answer that is slightly off costs a follow-up message. A request that should have been refused and was carried out can cost a payment, a disclosure or a commitment the firm cannot honour. Averaging those outcomes treats them as interchangeable, and they are not.
Volume makes it worse. In most certification sets, cases where the right answer is a refusal are a small slice. An agent can fail most of them and still post an excellent overall score. That is why, when you certify an agent, each gate must clear on its own. The refusal gate has its own floor, and failing it means the capability does not earn depth regardless of how the other gates went.
What does a correct refusal look like?
Declining is only part of it. A refusal that passes should do four things:
- Decline the specific request, not the whole conversation.
- Say why in plain terms, without exposing internal rules or other customers' data.
- Offer the next step: who can help, what they need, how to reach them.
- Leave a record of the request, the refusal and the reason.
An agent that says "I can't help with that" and stops has refused, but it has not refused well. Customers will try again with different wording, and each retry is another chance for the agent to get it wrong.
What are the two ways refusal fails?
Under-refusal and over-refusal. Both matter, and a certification set that only tests one of them will push the agent towards the other.
| Failure | What it looks like | Why it matters |
|---|---|---|
| Under-refusal | The agent agrees to waive a fee it has no authority to waive, or confirms a delivery date it does not control | The firm is committed to something nobody approved |
| Under-refusal under pressure | The agent declines once, then gives in when the customer insists or rephrases | Bounds that hold only on the first ask are not bounds |
| Over-refusal | The agent declines a simple balance question because it mentions an account in arrears | Customers lose service they were entitled to; staff lose time |
| Over-refusal by habit | The agent refuses anything that resembles a sensitive topic | The agent is safe but no longer useful |
A good refusal test includes cases from all four rows. The refusal test cases template is structured this way, and the certification gate scoring rubric template shows how to score a refusal on its reason and next step, not only on whether it happened.
Why aren't bounds at the moment of action enough?
Enforcement at the moment of action catches the action. If an agent tries to issue a refund above the customer's limit, the bound refuses it whatever the agent intended. That is essential, and it is why authority must be enforced, not just instructed.
But many of the harms of a failed refusal happen in language, before any action is attempted. An agent that tells a customer "I've arranged for that fee to be waived" has made a promise in words, even if the system then refuses the waiver. The customer now has a written commitment and a firm that did not keep it. Refusal behaviour in the agent and refusal enforcement in the platform are two layers, and the first has to be certified because the second cannot see everything.
How does refusal behaviour change over time?
Refusal is one of the first behaviours to shift when something underneath the agent changes. A model update can make it more accommodating. A rewritten brief that stresses helpfulness can weaken refusals that used to be firm. New products bring requests that look like routine questions but fall outside the agent's role.
Between runs, watch refusal rates in particular. A sudden fall is more alarming than a rise: it may mean the agent has started saying yes to things it used to decline. That is a reason to retest before the scheduled recertification. At each run, the stable gate checks that the same request gets the same answer, so a refusal that holds once and gives way the next time fails.
Who may override a refusal?
A refusal from the agent is not the last word, and should not be. A customer may have a legitimate case for an exception. The right route is a named person with the authority to make that exception, who reviews the case and either acts or declines. The rules for this are covered in who can override an AI agent's refusal.
What should never happen is that the agent overrides itself because the customer pushed. Persistence is not authority.
Where Pryme fits
In Pryme, refusal is one of the seven gates in Attest, scored separately against the customer's own cases, including cases where the right answer is to proceed. Every refusal is filed as a verdict naming the bound that decided it, so a reviewer can see whether the agent declined on role scope, on the customer's limits or on a platform guardrail.
Questions people ask
How many refusal cases should a certification set include?
Enough to cover each type of request the agent must decline, several times each, plus cases that look similar but should be answered. Count by request type, not as a share of the set.
Should an agent explain the exact rule behind a refusal?
It should give the customer a clear reason in plain terms. Quoting internal thresholds or control logic can help someone work around them, so the reason should be accurate without being a map.
What if customers complain about refusals?
Read the complaints closely. Some will show over-refusal that should be fixed; others will show the refusal working as intended. Either way they are useful test cases.