AI Chatbot Guardrails: What It Must Never Do

Say, do, promise — three different permissions

It helps to separate three things that are usually discussed as one. What the bot may say is an accuracy question. What the bot may do is an authorisation question. What the bot may promise is a liability question. They have different owners and different failure costs.

Accuracy failures are recoverable: the customer gets a wrong answer, someone corrects it, the material is fixed. Authorisation failures are not always recoverable — a cancelled order, a released discount code, a record shown to the wrong person. Liability failures are the most expensive of all, because a commitment made in your name by an automated system is still a commitment a customer will hold you to.

So write three separate lists, and have them approved by different people: the material owner, whoever owns the systems being called, and whoever carries commercial risk.

Read permissions: what the bot may see

The first boundary is what data the conversation can reach. The instinct is to give the bot everything so it can be helpful; the consequence is that the bot becomes a way to query your database in natural language, with no access control.

• Identity first: the bot may only read a customer's own record, and only once identity is established to a standard you have defined. 'They gave a phone number in the chat' is not identity verification.
• Field-level limits: order status is not the same as payment details, and account existence is not the same as account contents. Decide field by field, not table by table.
• Never expose other customers' data through aggregate answers. 'How many people ordered this?' is an innocent-looking question with a leaky answer.
• Internal-only material must be marked as such. Pricing logic, margin notes, escalation policies and supplier terms routinely end up in a knowledge base because they were in the same folder.
• Assume every read is repeatable by someone hostile. If a reply reveals whether a phone number exists in your system, it is an enumeration tool.

Write permissions: what the bot may change

Write access is where a chatbot stops being a conversation and becomes an operator. It is entirely legitimate to grant it — booking an appointment, creating a lead, updating a preference — provided each action is enumerated rather than implied.

1. 1List actions individually, never by category'Can manage orders' is not a permission; it is an invitation. 'Can create a callback request' and 'can change a delivery date to a later date within policy' are permissions.
2. 2Make destructive actions require a personCancellation, refund, deletion, account closure. The bot may collect everything needed and prepare it; a human presses the button. This single rule removes most incident risk at almost no cost to the customer experience.
3. 3Bound every parameterIf the bot may reschedule, define how far ahead, how many times and within which hours. An action with an unbounded parameter is the one that will be found.
4. 4Log every action with the conversation attachedNot just that it happened, but which conversation caused it. Without this, investigating a disputed action is impossible.
5. 5Make every action reversible, or make it need approvalIf it cannot be undone and it does not require a person, you have accepted a risk nobody explicitly agreed to.

Promises: what the bot may commit to

This is the guardrail most often missing entirely, because it does not look like a technical setting. Yet a customer holding a screenshot of your bot promising next-day delivery has a reasonable expectation, and 'the AI said it' is not a position anyone wants to argue.

• Pricing: the bot may state published prices and must not calculate an unpublished one, apply a discount, or confirm that a price will hold.
• Discounts and exceptions: never, without exception. This is the single most common place where automation creates commercial damage.
• Delivery and timing: only published windows. 'It should arrive by Friday' invented from general reasoning is a promise the courier has not made.
• Availability: only from live data, never from an indexed document. Stock statements go stale faster than any other fact.
• Outcomes: the bot must not promise that a complaint will be resolved in a particular way, that a refund will be approved, or that a specific person will call.
• Anything legal or regulatory: not a promise, not an interpretation, not a reassurance.

Tool calls and external systems

When a bot can call your APIs, the guardrail question becomes a security question, and the failure modes are familiar to anyone who has secured a web application.

• Allow-list the destinations. A bot that can call an arbitrary address supplied at runtime can be pointed at your internal network.
• Never let conversation content determine the destination. The customer's message is untrusted input; treat it as such at every boundary.
• Scope credentials to exactly what the action needs, and never to a general-purpose admin token.
• Define timeout behaviour explicitly. When a live lookup fails, the bot must say it could not check rather than falling back to a plausible guess.
• Rate-limit per conversation and per customer, so a single conversation cannot become a load generator against your own systems.
• Treat anything returned by the tool as data, not as instruction. A record whose field contains text telling the bot what to do next is a real attack.

Who approves what

A permissions model is only as good as its sign-off. Three groups should each approve their own list, and the document should name them.

1. 1The material owner approves what the bot may sayScope limits, out-of-bounds topics, the wording of fallbacks.
2. 2The system owner approves what the bot may doEach action, each parameter bound, each credential scope, and the logging that goes with it.
3. 3Commercial or legal approves what the bot may promisePricing statements, delivery language, complaint handling and anything that could become an obligation.
4. 4Revisit on every capability changeNew channel, new integration, new action, new market. Permissions granted for a pilot have a way of surviving into production unreviewed.

How guardrails work in Vexvon

Tool calling is explicit rather than open-ended: a company registers its own APIs as tools the agent may call, and the platform includes protection against requests being aimed at internal or otherwise unsafe destinations. On the voice side tools fall into three defined models — static values, built-in actions such as transferring a call, ending a call or searching the knowledge base, and webhooks to your own endpoints — so the set of things the agent can do is a list rather than a category.

Data boundaries are enforced structurally. Each company's knowledge is isolated by partition key in the vector store, so retrieval cannot reach another company's material. Knowledge entries can be activated or deactivated individually and are targeted at the chatbot, the call agent or both, which is the mechanism for keeping internal-only material out of customer-facing answers.

On the promise side the system is designed to stop rather than improvise: there is a defined fallback when no context is found, abusive language acts as a stop condition, and a request for an operator raises a notification. Prompt versions are tracked with one active at a time and a path back, so tightening a guardrail is a reversible change rather than an edit nobody can reconstruct.

Everything is recorded. Answer transparency notes which knowledge produced a reply; the activity log covers ten action types; and AI usage is logged across seventeen distinct purposes with tokens, latency and cost — which is what makes an investigation after an incident a matter of reading rather than of guessing.

Frequently asked questions

1. 1What are AI chatbot guardrails?The rules defining what the bot may say, what it may do and what it may promise. They are three separate permissions with three different owners, and the last one is the most commonly missing.
2. 2Should a chatbot be able to take actions at all?Yes, for bounded and reversible ones — booking, creating a lead, updating a preference. Destructive actions such as cancellation, refund and deletion should be prepared by the bot and executed by a person.
3. 3What is the most dangerous permission?Unbounded write access described by category rather than by action. 'Can manage orders' is not a permission; it is an invitation to find out what that includes.
4. 4Can the bot offer a discount?It should never be able to. Discounts and exceptions are the most common way conversational automation creates commercial damage, and they are trivially easy to elicit from a bot that is allowed to try.
5. 5How should tool calls be secured?Allow-list destinations, never let conversation content choose the destination, scope credentials narrowly, define timeout behaviour, rate-limit per conversation, and treat tool output as data rather than instruction.
6. 6Who should approve the permissions?Three groups: the material owner for what it says, the system owner for what it does, and commercial or legal for what it promises. Name them in the document.

Write the three lists this week

Guardrails do not begin in a configuration screen. They begin with three short documents — may say, may do, may promise — each with a named approver. Most teams discover while writing the third one that their bot has already been promising things nobody authorised, and that discovery on paper is far cheaper than the same discovery in a screenshot.