When an AI agent should refuse to answer

An AI agent should refuse to answer when it would have to invent the information someone needs to act. It should also stop before taking an action the user isn't authorized to request.

Consider a customer asking an assistant to delete a workspace. Before acting, the system needs to know which workspace they mean, whether they can delete it, and whether they understand what will be removed. A clear request doesn't settle those questions by itself.

We think a useful refusal explains the specific limit and leaves the customer with a way to proceed when one is available.

The four cases that should refuse

Out of scope

A billing assistant doesn't need to answer a question about the weather. It can briefly explain what it handles and return to the product. There's little value in a long apology for a boundary that is easy to explain.

Out of permissions

If a customer can't change the account's billing details, the assistant should not make that change for them. Tell them which role can do it, if that information is available. Enforce the same permission check in the code that performs the action; a sentence telling the model to behave isn't sufficient authorization.

Out of confidence

Suppose the assistant retrieves instructions for an older version of a settings page and can't verify the current steps. It should say what it can establish and stop short of guessing where the missing control went. A request for a screenshot, a link to the known documentation, or a support handoff may help, depending on what the product supports.

Out of safety

Some actions need a confirmation even when the customer has permission. Deleting a workspace is a good example. Ask for the confirmation your product requires before running it. If the request would expose information the customer isn't entitled to see, refuse that part of the request.

These cases need different responses. An unclear workspace name calls for clarification. A missing permission calls for an authorized person. Neither is solved by a more confident answer.

The confidence problem

We would judge an answer by its evidence before judging how certain it sounds. A retrieved page gives you something to check, but you still need to establish that it supports the answer and applies to this customer's situation.

For a question about billing settings, check that the source covers the right account type and that the relevant controls are available to this role. If two sources conflict, don't choose between them just to keep the conversation moving. Explain what needs to be checked.

The same approach belongs in evaluation. Include questions with missing context, outdated instructions, and contradictory sources. Assess whether the assistant identifies the missing information and avoids an unsupported answer. A test set containing only answerable questions won't tell you how it handles these cases.

The cost of refusing well

A refusal needs a working path through the product. If you tell someone to contact an admin, give them the route your product supports. If you offer a support handoff, carry over the question and the evidence already collected so the customer doesn't have to start again.

Those paths take implementation work. Someone also needs to review refusals: was the limit appropriate, or did the assistant fail to find an answer it had access to? Refusing a request unnecessarily deserves attention alongside answering it incorrectly.

What the right refusal looks like

For an ambiguous instruction such as "delete it," ask which item the customer means. If the missing detail can resolve the problem, a follow-up is useful. Stop asking when the next question would only repeat one the customer has already answered.

A permission refusal might read: "Your role can't delete this workspace. An account admin can do that from workspace settings." Use that wording only if the role and route are verified. Otherwise, explain that you can't confirm the required access and offer the support path you have.

Record the requested action, the reason it stopped, and enough context for the team to investigate. Keep that operational record separate from the short explanation shown to the customer.

Where this leaves us

Give refusals a place in your release review. Test a request the assistant should complete, one it should clarify, and one it should decline. Then follow each response through the interface to see whether the customer can take the next step it promises.

When should an AI agent refuse to answer or take an action?

An AI agent should refuse a request outside its scope or permissions, and stop before an answer or action it cannot support with the required evidence or authorization. If a missing detail would resolve the problem, ask for it. Explain the limit and offer a next step that is actually available.