Insights

Guardrails for customer-facing chatbots: profanity, prompt injection and personal data

A layered guardrail catalog for public chatbots: input, context, model, tool, output and human oversight, mapped to VAISS, OWASP LLM 2025 and NIST AI RMF.

A public chatbot is open to everyone, including people who want to see what it will say. Guardrails are the controls that keep it safe, useful and affordable under that pressure. They are not the same as conversation flow. Flow control decides what to ask next: intents, slots, retries and routing. Guardrails decide what may come in, what the model may see and do, and what a visitor may be shown. Keeping the two apart lets you test, own and evidence each one. For agents and internal tools, see guardrails for LLM applications and AI agents.

Map each control to a standard

A guardrail you cannot trace to a risk and a standard is hard to defend. For each control, record the failure mode it addresses and its mapping to the Voluntary AI Safety Standard guardrail number, the OWASP Top 10 for LLM Applications (2025) identifier and the NIST AI RMF function (Govern, Map, Measure or Manage). ISO/IEC 42001 expects the same traceability in its management system. Each control also needs an action: allow, redact, block, rewrite or escalate.

Layer 1: input

  • Input limits and rate limits reject empty and oversized messages and cap messages per session, address and day (OWASP LLM10, VAISS 2 and 4).
  • Toxicity and profanity filtering has to survive obfuscation. Normalise case, accents and invisible characters, map substitutions such as 0 to o and 5 to s, join letters spaced apart and collapse repeated letters, then match whole words and a short list of unambiguous stems so that innocent words are not caught.
  • Prompt-injection and jailbreak detection looks for attempts to override instructions, change role or disable rules (OWASP LLM01).
  • System-prompt extraction detection looks for requests to reveal hidden instructions (OWASP LLM07).
  • Sensitive-data detection finds email addresses, phone numbers, card-like and identifier-like numbers. Standard profiles mask them. Strict profiles for health, insurance and education block the message (OWASP LLM02, VAISS 3).
  • Topic and scope enforcement keeps the bot to its purpose (OWASP LLM06).
  • Unsafe-advice refusal declines medical, financial, legal and assessment requests with a safe alternative (OWASP LLM09).

Layer 2: context

Give the model only what it needs: validated answers and the scripted question. Pass visitor text inside clear delimiters and tell the model it is data, not instructions. Masked or blocked data never reaches the model. This limits both injection through supplied content and leakage (OWASP LLM01, LLM02 and LLM08).

Layer 3: model

  • Keep a fixed system prompt on the server and never accept instructions from the client.
  • Set token, temperature and time caps to bound spend and variance.
  • Apply a confidence threshold. When a model reads a free-text answer into a slot, use the value only if its stated confidence is high and it passes the slot validator.
  • Plan for failure with retry and backoff, a fallback model and graceful degradation to scripted wording, so the journey completes when the model does not.
  • Pin the model version and gate each release on an evaluation set of normal, abusive and adversarial conversations to catch drift and unequal treatment.

Layer 4: tool and action

The safest chatbot has almost nothing to abuse. Give the model no tools. Allow-list the actions the system itself can take, and for a task chatbot that may be a single hand-off to a fixed address. Use a server role that can invoke one model and nothing else, and store no visitor data (OWASP LLM06, VAISS 5).

Layer 5: output

  • Schema validation confirms the reply is the expected shape: one question, a short summary, or JSON that passes the validator (OWASP LLM05).
  • Moderation blocks profanity, links, prices and promises, personal data and markup.
  • Leakage checks block replies that repeat or describe the instructions (OWASP LLM07).
  • Grounding checks allow a reply to restate only the scripted question or the visitor’s confirmed answers, with no new facts or numbers (OWASP LLM09).

If any check fails, replace the reply with scripted wording. The visitor never sees the failure and you log the event.

Layer 6: human oversight

  • Vulnerable-customer and crisis escalation detects crisis, self-harm, hardship and safety signals and hands over to a person at once, with safe guidance such as 000 or Lifeline. This is the control that most protects people (VAISS 5 and 7).
  • Retry limit and hand-off moves to a person after repeated failures, guardrail hits or a request for one.
  • Audit logging records control decisions with masked values and no raw text (VAISS 9, NIST Govern and Measure).
  • Disclosure says plainly that the assistant is automated and keeps a route to a person open at every step (VAISS 6 and 7).

Failure modes the catalog addresses

Hallucination, prompt injection, system-prompt leakage, sensitive-data leakage, toxic content, scope drift, unsafe advice, harm to a vulnerable person, tool misuse, improper output handling, model outage, cost runaway, over-reliance, bias and drift. Every control lists the failure modes it mitigates, and every failure mode has at least one control, so gaps are visible.

Safe refusals

A refusal should be short, polite and useful. State what the bot can help with, repeat the current question and offer a person. Avoid explaining which rule fired, which helps attackers tune their attempts. Count the event as a retry so abuse cannot run indefinitely.

Managed options and testing

Amazon Bedrock Guardrails and similar services add configurable content, topic and personal data filters as a second layer, which suits policy owners who need to tune rules without code changes. Keep a test set of abusive, off-topic and injection attempts and run it before every release. Track guardrail hits by control, review samples of masked conversations and alert on spend and traffic anomalies.

See every layer working on our AI agents and chatbots page, where the Mini Bot trace shows each control’s result, the failure mode it addresses and its standard reference. Our customer chatbot reference architecture shows the layers on AWS, and our AI governance and assurance service covers policy, testing and evidence for every kind of AI. Related reading: designing chatbot conversations.

To discuss a chatbot for your organisation, get in touch or call 0402 401 584.

More insights

Let’s talk about your next project

Talk to an Adelaide-based team. We reply within one business day.