How do you stop an AI agent from going beyond its role?

Write the role down as a list of capabilities, enforce that list outside the model at every action, and give out-of-scope requests somewhere to go. An agent drifts beyond its role when helpfulness meets a tool it should not have or a request nobody planned for. Remove the tool, route the request, and review the refusals for patterns.

How do agents drift beyond their role?

Rarely through bad intent. More often:

• Helpfulness. A customer asks the billing agent about a delivery, and the agent, wanting to help, looks up the order and promises a date.
• Leftover tools. A capability added during testing was never removed.
• Chained requests. One agent asks another to do what it cannot.
• Conversation drift. A long exchange wanders, and the agent follows.
• Instruction creep. Someone edits the agent's brief to cover "just this one case", and the case becomes a category.

Role scope is the bound that addresses all of these: the list of capabilities the agent has at all, before any limit or depth applies.

What are the steps, and who acts?

1. Process owner: writes the role charter. Purpose, capabilities, what is explicitly out of scope, where out-of-scope requests go. The agent role charter gives a format, and what an AI agent's role description should include covers the content. Evidence: the signed charter.
2. Platform team: maps the charter to tools. Only tools needed for listed capabilities are available. Evidence: the tool list against the charter.
3. Platform: enforces scope at every action. A proposed action outside the listed capabilities is refused, naming role scope as the deciding bound. Evidence: refused verdicts.
4. Process owner: defines hand-off routes. For each common out-of-scope request, where it goes: another agent within its own scope, or a team. Evidence: the routing table.
5. Platform: checks hand-offs. A hand-off carries the requesting agent's scope; the receiving agent cannot be used to widen it. Evidence: hand-off records.
6. Process owner: reviews refusals monthly. A steady stream of the same out-of-scope request may mean the role should change, through change control, or that another agent should own it. Evidence: the review note and any change record.
7. Change owner: controls brief edits. Edits to the agent's instructions go through change control and are compared with the charter. Evidence: the change log.

Our guide on setting an AI agent's role scope covers steps 1 to 3 in depth.

What does in scope and out of scope look like?

The agent should not refuse silently. A clear message and a working route stop the customer pushing the agent to try anyway.

A worked example

Take a pension provider's member services agent. Its charter covers explaining statements, updating contact details after verification, and sending forms. Transfers out are explicitly excluded.

A member asks the agent to start a transfer to another scheme. The agent has no transfer tool, and the proposed action is refused on role scope. It replies that transfers are handled by a specialist team because of the checks involved, and books a call. Over a month, the refusal review shows 300 transfer requests. The process owner does not add transfers to the agent's role; she adds a better explanation of the transfer process to its sources so members know what to expect before the call.

Which controls make the answer hold?

• A written charter, signed by the owner.
• Tools that match the charter, nothing extra.
• Scope enforced at every action, outside the model.
• Routes for out-of-scope requests.
• Monthly refusal review.
• Brief edits through change control.

Agents nobody registered have no charter at all; see how to stop shadow AI agents. The topic guide, agent governance is a bound, not a model, explains why role scope is the first bound.