AI Chatbot Guardrails: What the Bot Should Never Be Allowed to Do

Guardrails are a permissions question

Guardrails are usually discussed as a matter of instruction — telling the model what not to say. That is the weakest form of control available, because it depends on the model choosing to comply and gives you no way to prove it did. The stronger framing is permissions: what the system is technically capable of doing, what data it can reach, and which actions it can take.

The distinction is practical. An instruction not to issue refunds is a request. Not giving the bot access to the refund endpoint is a control. The first fails silently under an unusual conversation; the second cannot fail that way at all.

This article sets out a permissions model in business terms — what the bot may read, what it may say, what it may promise and what it may do — and treats prompt-level instruction as the last layer rather than the first.

The four permission surfaces

Every guardrail decision falls onto one of four surfaces. Deciding them separately prevents the common error of assuming that limiting one limits the others.

1. 1

   Read: which data can it reach?

   Customer records, order history, pricing tables, internal documentation, other customers' data. The default should be the minimum needed for the use case, with access enforced at the data layer rather than by asking the model not to look. Retrieval must also respect the permissions of the person it is answering.

2. 2

   Say: what topics may it discuss?

   Published pricing ranges, product capability, process, timelines. And the explicit prohibitions: competitor comparisons, legal interpretation, medical or financial advice, speculation about roadmap, anything about other customers.

3. 3

   Promise: what commitments may it make?

   This is the surface that creates commercial exposure. A bot that says 'yes, we can integrate with that' has made a statement your business may have to honour. Commitments about capability, timeline, price and outcome should be explicitly enumerated rather than left to judgement.

4. 4

   Do: which actions may it execute?

   Creating a ticket is low risk. Issuing a refund, changing a subscription, cancelling an order, sending an email on your behalf, or updating a customer record are not. Each action needs its own decision, and the reversible ones should be separated from the irreversible ones.

A workable default permissions model

For a typical B2B deployment, a defensible starting position looks like this. Widen it deliberately, with a reason recorded for each expansion.

• Read: published documentation, the current customer's own record, order or ticket status for that customer only. Not internal notes, not draft pricing, not other customers.
• Say: anything in published documentation, with a source. Published price ranges as published, without interpretation. Process and timeline statements that are documented.
• Never say: competitor comparisons, legal or regulatory interpretation, capability claims not in documentation, roadmap speculation, anything about another customer, any figure not traceable to a source.
• Promise: nothing beyond what is published. Specifically no custom pricing, no delivery date not confirmed by a system, no capability commitment, no exception to a stated policy.
• Do, without confirmation: create a ticket, book an available slot, send documented material, log the conversation.
• Do, with explicit customer confirmation and an audit record: update contact details, reschedule an appointment.
• Never do: financial transactions, refunds, cancellations, subscription changes, anything irreversible, anything affecting another party.
• Escalate instead: everything in the never lists, plus anything the model is not confident about — which is where the escalation catalogue takes over.

The asymmetry is deliberate. Reading is cheap to widen later; actions are expensive to narrow after customers have come to expect them.

Enforcing guardrails at the right layer

The same rule can be enforced in several places, and the choice determines whether it holds under pressure.

1. 1

   Infrastructure and credentials — strongest

   If the bot's credentials cannot perform an action, no conversation can cause it to happen. This is the only layer that is genuinely robust, and it should carry every rule that matters commercially or legally.

2. 2

   Tool definitions and parameters — strong

   Where a tool exists but is constrained: refunds capped at an amount, lookups scoped to the authenticated customer, writes limited to specific fields. Tool access controls are the practical middle ground for actions that must be possible but bounded.

3. 3

   Retrieval and indexing — strong for content

   Content that is not indexed cannot be surfaced. This is the correct place to enforce 'never discuss internal pricing logic', rather than instructing the model to ignore what it has been given.

4. 4

   Output filtering — moderate

   Checking responses before they are sent, for prohibited content, unsourced figures or commitment language. Useful as a safety net, not as a primary control.

5. 5

   Prompt instruction — weakest

   Necessary for tone and for guidance, but it should never be the only thing standing between a conversation and a commercial commitment. Treat it as the layer that handles the cases the others did not anticipate.

A useful test: for each guardrail, ask what happens if the model simply ignores the instruction. If the answer is 'the action occurs', the rule is at the wrong layer.

Data, tooling and integration requirements

The controls above need specific things to exist.

• Separate credentials for the bot with least-privilege scopes, distinct from any staff or service account.
• Per-tool permission definitions with parameter constraints, versioned alongside the rest of the configuration.
• Retrieval that carries the requesting user's access rights, so a passage cannot be reached by paraphrase when it could not be reached directly.
• An audit log of every action taken, with the conversation, the parameters and the outcome, retained long enough to investigate a dispute.
• A confirmation pattern for the middle tier of actions, where the customer explicitly agrees before execution — logged as part of the conversation record.
• Rate limiting on actions, so a malfunction is bounded rather than unbounded.
• A documented review process for expanding permissions, so scope creep is a decision rather than an accumulation.

Much of this is engineering rather than configuration, and where a platform stops short, it lands on the integration layer — our custom software services page covers how that is usually built. How a vendor handles security and permissions is worth examining specifically during evaluation, because it is difficult to retrofit.

Metrics and monitoring

Guardrails need monitoring, because a guardrail that has quietly stopped working looks identical to one that is working.

1. 1

   Guardrail trigger rate by rule

   How often each control actually fired. A rule that never fires is either unnecessary or broken, and telling those apart matters.

2. 2

   Prohibited-topic violations

   Cases where the bot discussed something it should not have. This should be zero, and every instance should be investigated as a configuration failure rather than a model quirk.

3. 3

   Unsourced claim rate

   Answers containing figures or commitments not traceable to a source. Sampled by human review, since automated detection here is imperfect.

4. 4

   Action audit completeness

   Every executed action should have a complete log entry. Gaps in the audit trail are a finding in themselves, independent of whether any action was wrong.

Run an adversarial review periodically: have someone deliberately try to get the bot to make a commitment, reveal internal content or take an action it should not. This finds more than passive monitoring does, and it should be repeated after each significant change.

Failure modes

Guardrail failures are consistent and mostly architectural.

• Relying on prompt instruction for rules with commercial or legal consequences.
• Giving the bot broad credentials because narrow ones are more work to set up.
• Indexing internal content and instructing the model not to use it.
• Retrieval that ignores the requesting user's permissions, so access control is bypassable by rephrasing.
• Irreversible actions with no confirmation step and no audit log.
• Permissions widened during a project and never reviewed afterwards.
• No monitoring, so a guardrail broken by a configuration change is discovered by a customer.
• Treating guardrails as a launch task rather than an operational discipline.

What guardrails cannot decide for you

The permissions model encodes decisions. It does not make them.

• Whether a category of question may be automated at all — particularly anything with legal, financial or regulatory exposure — is a decision for whoever owns that risk in your organisation, and it should be recorded as such.
• What your business is willing to commit to in writing, which is commercial policy rather than configuration.
• How much friction a confirmation step is worth, which is a trade-off between customer experience and exposure.
• Which data may be processed and retained, which depends on the markets you operate in and belongs with whoever owns data protection.
• When to widen scope, which should require the same approval as the original decision rather than less.

Documenting who made each of these decisions is as valuable as the decisions themselves, because it is what makes them reviewable when circumstances change.

Decision framework and next step

Four questions to work through.

1. 1

   What is the worst action this bot could take?

   Start there and remove the capability rather than instructing against it. If the capability is genuinely needed, constrain it at the tool layer with an audit trail.

2. 2

   Does retrieval respect the asker's permissions?

   If not, every content-level guardrail is bypassable and this is the first thing to fix.

3. 3

   Which commitments would your business have to honour?

   Enumerate them, then prohibit them at a layer stronger than instruction.

4. 4

   Can you prove what the bot did?

   A complete action audit log is what turns an incident into an investigation rather than an argument.

Start narrow and widen with a recorded reason. Narrow permissions produce more escalations at first, which is a visible and recoverable cost; broad permissions produce rare, expensive incidents, which are neither. Our AI solutions overview covers how these controls are usually staged alongside the rest of an implementation, and the escalation catalogue covers what should happen at each boundary.

Frequently asked questions

1. 1

   What are AI chatbot guardrails?

   They are the controls defining what a bot may read, say, promise and do. The useful ones are permissions enforced at the credential, tool and retrieval layers; prompt instructions are the weakest form and should not carry rules with commercial or legal consequences.

2. 2

   What data and integrations are required to enforce them?

   Least-privilege credentials separate from staff accounts, per-tool permission definitions with parameter constraints, retrieval that carries the asker's access rights, a complete action audit log, a confirmation pattern for sensitive actions, and rate limiting.

3. 3

   Which metrics should be monitored?

   Trigger rate per rule, prohibited-topic violations, the rate of unsourced claims found by sampled human review, and completeness of the action audit trail. Periodic adversarial testing finds more than passive monitoring.

4. 4

   What are the most common mistakes?

   Relying on prompt instructions for rules that matter, granting broad credentials for convenience, indexing internal content and instructing the model to ignore it, and widening permissions during a project without ever reviewing them afterwards.

5. 5

   What decisions cannot be delegated to guardrails?

   Whether a category may be automated at all, what the business will commit to in writing, what data may be processed and retained, and when scope should be widened. These are business decisions the configuration only encodes.

Guardrails, escalation rules and answer grounding are three views of the same boundary — what the system is allowed to handle alone.