Guardrails for AI Support Agents: A Practical Checklist
Before an AI agent touches a customer, put these guardrails in place.
The difference between an AI agent you'd put in front of customers and a demo you'd never trust isn't the model. It's the guardrails around it. A capable model with no limits is a liability. A modest model with the right checks is something you can actually ship.
Here's the practical checklist to run before an AI agent touches a single customer.
AI support guardrails start with scope
Before anything else, decide what the agent is allowed to be about. An unscoped agent will confidently answer questions it has no business answering — legal advice, competitor comparisons, things it can't ground in your data.
- [ ] Define the domains it handles. Orders, accounts, shipping, returns — name them. Everything outside scope routes to a person.
- [ ] List the topics it must never touch. Legal, medical, financial advice, anything that needs a human judgment call.
- [ ] Set a "when unsure, hand off" default. Out of scope shouldn't mean "improvise." It should mean "get a person."
Scope is the cheapest guardrail and the one most often skipped. An agent that knows its lane is already most of the way to safe.
Allowed actions and hard limits
Sensing and answering are low-risk. Acting is where guardrails earn their keep. Every action the agent can take needs an explicit boundary.
- [ ] Enumerate the allowed actions. The agent can do exactly these things — issue a refund, update an address, resend a receipt — and nothing else. No open-ended ability to "do whatever."
- [ ] Set ceilings on consequential actions. A refund ceiling is the classic example: the agent can refund up to a set amount on its own; above it, a person approves. Same idea for discounts, credits, plan changes.
- [ ] Rate-limit the agent. A bug or a bad pattern shouldn't let an agent issue a thousand refunds before anyone notices. Cap the volume.
- [ ] Require approval for the irreversible. Account deletion, cancellations, anything you can't easily undo gets a human in the loop.
A capable model with no limits is a liability. A modest model with the right guardrails is something you can ship.
Fail closed, not open
The single most important design choice: when the agent is uncertain, what does it do? The safe answer is nothing customer-affecting — it stops and hands off. That's fail-closed, and it's the opposite of how most demos behave.
- [ ] Default to no action under uncertainty. Low confidence means stop and escalate, not "best guess and proceed."
- [ ] Validate before executing. The agent proposes an action; that proposal is checked against your rules; only a valid proposal runs. The model never acts directly.
- [ ] Make the unhappy path safe. If a system is down or data is missing, the agent should hand off gracefully, not fabricate an answer or take a blind action.
Fail-closed is uncomfortable because it means the agent does less when it's unsure. That's exactly the point. The cost of an agent that does too little is a slightly slower handoff. The cost of one that does too much is a wrong action on a real customer.
A receipt for every action
You can't trust what you can't audit. Every action the agent takes — and every proposal a person approved — should leave a receipt: what it did, the data it used, why, and on whose authority.
- [ ] Log every action with its reasoning. Not just "refund issued" but the order, the amount, the policy it matched, the confidence.
- [ ] Capture approvals. When a person signed off on a supervised action, the receipt records who and when.
- [ ] Make receipts reviewable. They're useless if nobody looks. Review them, and feed what you learn back into tighter guardrails.
The receipt is also what lets you expand the agent's autonomy safely over time. You can see exactly what it's been doing, judge whether it's been right, and only then give it more rope.
The checklist, in order
If you do nothing else, do these five, in this order:
- Scope — what it's allowed to be about.
- Allowed actions — exactly what it can do.
- Limits — ceilings and rate caps on those actions.
- Fail-closed defaults — stop and hand off when unsure.
- Receipts — an auditable record of everything it did.
Skip any one and you've left a gap a real customer will eventually find.
| Guardrail | What it controls | Failure mode it prevents |
|---|---|---|
| Scope | What the agent is about | Confident answers outside its lane |
| Allowed actions | What it can do | Open-ended "do whatever" power |
| Limits | How much / how often | One bug refunding a thousand orders |
| Fail-closed | Behavior when unsure | Blind action on a bad guess |
| Receipts | Auditable record | Actions you can't trace or trust |
Where BearScope fits
BearScope is built on these guardrails by default. Every AI action is scoped, checked against your rules before it runs, capped by limits you set, set to fail closed under uncertainty, and recorded as a receipt you can audit. The guardrails aren't a feature you bolt on — they're how the system works. See how in the product overview, read the details on our security page, or book a walkthrough.
See it on your own conversations.
Bring your busiest day. We'll score every conversation in it.
Book a walkthrough →