The Guardrails Customers Never See
There is a moment in every customer-facing artificial intelligence project when the conversation changes. In the demo, everyone is impressed that the agent can answer questions, look up an order, and draft a reply. Then someone asks the real question: What happens when we let it act? Issue the refund. Change the delivery address. Apply the discount. Cancel the subscription.
That is the point at which many projects stall, and it is usually for the right reason. An agent that can act on a customer's account can also damage the relationship in a single exchange. The answer is not to keep agents on a short leash forever, and it is not to hope the model behaves. It is to design the guardrails customers never see.
Over the past decade of building custom AI systems at Critical Future, I have come to think of these guardrails in three layers: what the agent is allowed to touch, when it must hand over to a person, and how you stop it when something goes wrong. None of them is glamorous. All of them matter more than the choice of model.
Layer one: Access controls that match the job
The most common mistake I see is giving an agent the same system access as the human role it is supporting. Service representatives might have broad permissions because they are trusted to use judgement. An AI agent should be given only what the specific task requires.
In practice, that means three things. First, scope permissions to actions, not systems. An agent that handles delivery questions might need to read order status and update an address, but it does not need access to payment details or the ability to issue credit. Second, set limits within each action. A refund agent might be allowed to refund up to a fixed amount, once per order, for a defined set of reasons. Anything outside those bounds is not refused; it is routed. Third, separate reading from writing. Letting an agent look things up is low risk. Letting it change a record is a different decision and deserves its own approval.
Security researchers have a name for the failure this prevents. The OWASP Top 10 for Large Language Model Applications lists "excessive agency" as a core risk: an AI system given more functionality, permissions, or autonomy than its task needs. It is a useful phrase to bring into internal discussions, because it frames the problem as a design choice rather than a flaw in the technology.
Layer two: Escalation rules written before launch
Every customer-facing agent needs a clear answer to one question: when does it stop and bring in a person? Too many teams leave this to the model's own sense of confidence, which is the least reliable signal available.
Good escalation rules are explicit and written down before launch. Some are about the request: Any complaint that mentions legal action, a regulator, a vulnerable circumstance, or a cancellation of a long-standing account goes to a person. Some are about value: Any action above a set amount, or any customer above a set tier, needs human approval. Some are about the conversation itself: If a customer repeats the same request twice, expresses frustration, or asks for a human, the agent hands over without argument.
The hand-over is part of the guardrail. When an agent escalates, it should pass a short summary of what the customer wants, what it has already tried, and why it stopped. The customer should never have to explain themselves twice. Done well, escalation feels to the customer like better service, not a failure of the system.
Layer three: Kill switches and a clear record
The final layer is the one teams hope never to use. Every agent that can act on customer accounts needs a way to be stopped quickly and a record that shows exactly what it did.
A kill switch does not have to mean switching the whole agent off. The most useful designs allow you to suspend specific actions while leaving the rest running. If refunds start behaving unexpectedly, you pause refunds and the agent keeps answering questions and routing the rest. Someone in the business, not just the engineering team, should know how to pull that switch and have the authority to do it.
Alongside it sits the record. Every action the agent takes should be logged with the request that triggered it, the data on which it relied, and the outcome. When a customer disputes a change to his account, the service team needs to be able to see what happened in plain language. This also makes continuous improvement possible: Reviewing a sample of agent actions every week is the fastest way to find the rules that need tightening.
For teams that want a broader structure for this work, the NIST AI Risk Management Framework is a sensible, vendor-neutral reference. Its emphasis on governing, mapping, measuring, and managing AI risk translates well into the practical question of who owns each agent and how its behavior is checked.
Why invisible guardrails build visible trust
CRM Editor Leonard Klie made the case for forward-looking guardrails rather than backward-thinking restrictions, and I agree. The goal is not to stop agents acting. It is to let them act confidently within boundaries the business has chosen deliberately.
Customers will never see an access policy, an escalation rule, or a kill switch. They will notice that the agent resolved their issues quickly when it could, handed them to a person when it should, and never did anything to their accounts they did not expect. That experience is the product of decisions made long before the first conversation.
For CRM leaders, the practical step is simple. Before any agent is allowed to act on a customer account, write down what it can touch, when it must stop, and how you will stop it. If those three answers are clear, the technology is ready to earn trust. If they are not, no model is good enough to make up the difference.
Adam Riccoboni is founder and CEO of Critical Future.