What LLM Guardrails Stop Your Support Chatbot Writing Code for Strangers?

LLM guardrails are the checks around a language model that decide what it may answer, what reaches the visitor and what it may cost you. To stop a support chatbot writing code for strangers you need three of them working together: an off-topic rule in the prompt, an output guard in code that ends any reply carrying a long block of code, and a spend ceiling that caps length and volume. Each one fails on its own, so a request has to beat all three at once.

A public support chatbot can be asked to write code for anyone who asks. A visitor types a programming task, and a bot that was put there to answer questions about one company's service writes the program, explains it and offers to improve it. The company pays for each of those replies, which help nobody who might ever buy from it, and its name is on the screenshot.

The fix is a prompt, a piece of code and a budget, each one covering the gap the others leave, because even a cleverer prompt can still be argued round by a visitor who keeps trying.

What are LLM guardrails?

LLM guardrails are rules and checks placed around a language model so that it stays inside the job you gave it. Some sit before the model and decide what it is allowed to read. Others are written into its instructions and tell it what to refuse. A third kind reads every reply after the model writes it and before the visitor sees it, and a fourth limits how much any one visitor, or the whole site, can make it do.

The word covers very different things, so it helps to sort them by where they run:

A support chatbot needs at least one guardrail in each row. A chatbot with only the second row is relying on the model to police itself.

Why does a support chatbot write code for strangers?

A support chatbot writes code for strangers because the model underneath it was trained to help with almost anything, and writing code is one of the things people ask models for most. The company's prompt says "you help customers of our service". It rarely says what to do with everything else, and even when it does, the visitor's request sits in the same conversation and pulls the other way.

The model has no idea who is paying. It sees a polite request it knows how to answer well and an instruction that may or may not cover it, and its training to help usually wins.

Is it a security problem or a cost problem?

Mostly it is a cost and reputation problem. Every reply costs money in model usage, and a long program costs far more than a two-line answer about opening hours. A public chatbot with no limits becomes free computing for anyone who finds it, and a screenshot of one of those replies can reach more people than any advert.

It can become a security problem too. The same gap that lets a bot write code also lets a visitor talk it into repeating its own instructions, or into pretending to be a person. A guard that catches one of these usually catches the others with a few more patterns.

Why is a longer prompt not enough?

A longer prompt adds more rules for the model to weigh, and the model can still decide that this visitor's case is the exception. Long prompts also fail in their own way: as the context fills up, some rules get less attention or drop out of what the model sees. Why your RAG chatbot ignores the rules you gave it measures how that happens and how to pin the rules that matter.

How do AI chatbot guardrails work in layers?

AI chatbot guardrails work in layers because each layer fails in a different way. The prompt understands meaning, but a visitor can argue it round. Code follows only the patterns it was given, and no amount of arguing moves it. A budget understands neither, but it puts a ceiling on the damage when both of the others miss. With all three in place, a request has to beat every one of them at once.

What should the off-topic rule in the prompt say?

The off-topic rule should name the kinds of request that are out of scope, say exactly how to decline, and say what to do next. A good one reads like this: off-topic requests such as trivia, poems, stock tips and general coding tasks get one short, friendly line, then a question that brings the visitor back to their own project, and no part of the task is done. Without that last clause, a model will often decline politely and then do half the work anyway, "just to get you started".

Keep a line for the requests that look off-topic but are not. A question about the technology behind the visitor's own project is in scope, even when it is about something you do not offer. That deserves a plain answer and the nearest thing you do.

What does an output guard check?

An output guard is code that reads the reply as it streams, sentence by sentence, before the visitor sees it. When a sentence breaks a rule, the guard replaces it or ends the reply with a fixed line, and nothing after that point is sent. For code the rule is simple: a fenced block longer than a short example ends the reply. A short example inside a real answer about the visitor's project still passes.

Use the same guard for the other rules that the prompt states but cannot enforce. A sentence that claims to be a person can be swapped for a plain statement that the visitor is talking to an AI assistant. A sentence that repeats the prompt can end the reply. Each time the guard fires, log the reason and a count, never the visitor's text.

Why do you need a spend ceiling?

A spend ceiling turns the worst case into a known cost. Cap the length of a reply, the number of questions one visitor can ask in a minute and in a day, the number the whole site answers in a day, and the length of a single message. When the prompt and the guard both miss, the off-topic reply is short, and nobody can ask for a hundred of them.

Set the caps from your real traffic, with room for a busy day. Keep the exact numbers private, because a visitor who knows a limit can work just under it.

What happened when we tried to make our own chatbot write code?

We run Boffin AI, the chatbot on this site, with all three layers, and in October 2026 we tried four ways to make it write code on the live site. The prompt's off-topic rule held every time: one line declining, one line back to the visitor's project, and no code. These are the four requests and what each one was testing:

Four passes did not settle it, because a prompt that holds four times can still fail on the fifth wording, or after the next model update. So the same day we added the output guard for code as a backstop. A long code block now ends the reply with "Writing code isn't something I do here. If you're planning a build, tell me about the project and I can help with that." The spend ceiling was already in place and stayed as it was.

How do you stop a chatbot answering off-topic without blocking real questions?

To stop a chatbot answering off-topic without blocking real buyers, scope it by the visitor's purpose, because a buyer's question and a stranger's coding task often use the same technical words. Someone asking which framework suits their booking app is a buyer, even though the question is technical. Someone asking for a finished function is not. Decline the second in one friendly line, answer the first properly, and test both kinds every time you change the prompt.

Blocking too much costs more than it saves: a guard that refuses every technical question turns away the visitors most likely to buy, and you will never see them in a report, because a visitor who gets a refusal usually just leaves.

What should the decline line say?

The decline line should say what the chatbot does not do in one short, friendly sentence, then give the visitor a reason to stay: a question about their project, or the one thing it can help with. Avoid lectures about policy and avoid apologising three times. The visitor asked for something reasonable from their side, and the reply should treat them that way.

Should the guard block every block of code?

No. A short example inside a real answer can help a buyer understand a suggestion, such as the shape of a setting or a single command. So the guard should judge a block by its length and its context. The prompt decides whether code belongs in the answer at all, and the guard steps in only when a reply turns into a finished program.

How can you test your own chatbot's guardrails?

Test your chatbot's guardrails by trying to break them the way a curious visitor would, on the live site, after every change to the prompt or the model. Use the four requests above, then add two more: ask the chatbot whether it is a person, and ask it to repeat the text above the conversation. A pass looks the same every time: a short decline, a way back to the visitor's project, and nothing done.

Then read the logs. Each guard should record when it fired and why, as a count. If the output guard fires often on one kind of request, tighten the prompt for that kind, so the prompt does most of the work and the guard stays a backstop.

How often should you re-test?

Re-test after every change to the prompt, the model or the knowledge the chatbot reads, and once a month even when nothing has changed. A new model version can weigh the same prompt differently, and a new page in the knowledge base can pull answers in a new direction. Keep the six requests in a file so the test takes a few minutes.

If you would rather have these layers built into your own support bot, we build chatbots that answer from your own knowledge base with the prompt rule, the output guard and the spend ceiling in place from the first day.