The best guardrail is the one your customers never notice. They ask their question, in their own words and their own dialect, and get a helpful answer. Behind the scenes, the rare message that tries to manipulate the assistant is handled firmly. That is the goal, and it has two halves. Most writing about AI security talks only about the first half, catching attacks. This article is about the second: letting people through.
It matters for a simple business reason. A guardrail that refuses ordinary questions does not make anyone safer. Users rephrase in frustration, give up, or call the support line the assistant was meant to relieve. The team that owns the assistant hears the complaints and, sooner or later, loosens the filter or turns it off. A guard that is switched off protects nothing. Over-blocking is not an excess of security. It is a failure of it.
Researchers have a name for it
The XSTest paper calls it exaggerated safety: models that refuse “even clearly safe prompts” when they “use similar language to unsafe prompts or mention sensitive topics”. Its authors built a test of 250 safe prompts that a well-calibrated model should answer, alongside 200 unsafe contrasts that it should refuse, precisely so that this failure can be measured instead of guessed at [1].
Meta’s CyberSecEval 2 team reached the same point from the security side: “conditioning an LLM to reject unsafe prompts can cause the LLM to falsely reject answering benign prompts, which lowers utility.” They proposed tracking it as a false refusal rate, next to the attack figures [2]. The lesson for buyers is direct. A guardrail’s quality is two numbers, not one: how much manipulation it notices, and how few normal messages it wrongly stops.
Where naive filters go wrong in Arabic
Over-blocking is worse for languages a filter was not built for. Many filters learn mostly from English, and Arabic as it is really written in the Gulf looks unusual to them. The examples below are our own, written to show the pattern. Each is an ordinary message that a careless filter might misjudge.
Fully vowelled text
Most Arabic is written without short-vowel marks, but they are used in texts that demand exact pronunciation: the Quran, hadith, poetry, children’s books and teaching material [3]. A student who pastes «العِلْمُ نُورٌ» (“knowledge is light”) into a school assistant is doing something entirely normal. Attackers also add diacritics to disguise forbidden words, so a filter that learns “lots of diacritics means trouble” ends up treating religious and school texts as suspicious. Diacritics must never become a sign of an attack. The right design removes them before checking, then judges the meaning.
Arabizi
Arabizi is Arabic written with Latin letters and numerals, where 3 stands for ع, 7 for ح and 2 for the hamza; it is used above all in chat and text messages [4]. A customer who writes “ana 3ayez a3raf leh el card bta3ti et2afalet” (Egyptian: “I want to know why my card was locked”) is asking a routine banking question. To a filter that only knows English, it looks like noise or obfuscation. To a filter that only knows Arabic script, it is invisible. Either way, the customer is let down.
Gulf dialect and mixed messages
“أبي أكسر حد التحويل اليومي، شلون؟” is Gulf dialect for “I want to raise my daily transfer limit, how?”, though word for word it says “break” the limit. A keyword filter sees “break” and a money transfer, and gets nervous. Add English in the same sentence, as many people in the Gulf naturally do (“please check my balance، ابي اعرف الرصيد”), and a filter that expects one language per message may read the switch itself as a trick. These are customers, not attackers.
Five outcomes, not two
The single most useful idea in a user-friendly guardrail is that “allow” and “block” are not the only choices. A risk score can map to several actions, and most of them keep the conversation going.
- Allow: the message goes through as written. This should be the outcome for the great majority of messages.
- Mask: the user pastes an ID number or an IBAN, and the guardrail swaps it for a placeholder before the model sees it, then puts the real value back in the answer. The user gets a useful reply; the value never reaches the model provider.
- Warn: the message goes through, with a short note to the user and an entry in your log. Useful for grey areas where context matters.
- Ask to rephrase: instead of a cold refusal, the user is invited to word the request differently. A polite redirect keeps a confused customer in the conversation.
- Block: kept for clear attempts at manipulation or requests your policy does not allow, logged for your security team.
Masking deserves special mention because it turns a refusal into a yes. OWASP lists scrubbing or masking sensitive content among its mitigations for sensitive information disclosure [5]. A guardrail that blocks every message containing an Emirates ID makes the assistant useless for visa forms, bank letters and HR questions. A guardrail that masks it lets the assistant help, safely.
How Guardrino is designed to keep normal users happy
Guardrino, the AI firewall HisnLabs is building for businesses, starts from this principle. Everything below is planned design, not a released product, and we will publish no measured results until a release has been tested on public and held-out test sets.
- Clean-up first: diacritics, stretched letters, alef and yaa forms are normalised, and Arabizi is read as Arabic, before any check runs. A vowelled poem and a plain one are judged on the same meaning.
- The five outcomes above, chosen by your own policy, per app and per team. A school assistant and a payments assistant do not need the same limits.
- A watch-only start: for the first weeks, Guardrino only records what it would have done. You review the results before anything is blocked.
- A must-pass set: a fixed collection of everyday Arabic and English messages that must always go through, checked again before every change.
- Feedback that teaches it: when a user or an admin overrides a decision, the case is reviewed and used to improve the checks.
The result we are designing for is an assistant your customers enjoy using in the language they actually speak, and a security team that can see, in the log, exactly what was stopped and why. To understand the layers behind these decisions, read our plain guide to AI guardrails. To check any guardrail’s wrongly-blocked figures yourself, follow our testing tutorial.
A short checklist for your own assistant
- Write down twenty real questions your users ask, in every language and dialect they use, including Arabizi and mixed messages. Run them through your guardrail. Every one should pass.
- Look at your refusal messages. Could any of them be an invitation to rephrase instead?
- Find every rule that blocks personal data, and ask whether masking would let the assistant help instead.
- Make sure your log shows why a message was stopped, so wrong decisions can be found and fixed.
- Measure the wrongly-blocked rate before and after every change, not only the number of attacks caught.
If you run AI apps in Arabic and English and want a guardrail designed around your users from the first day, the Guardrino pilot programme is open to a small number of companies. The background to the project is in why we are building Guardrino for the Middle East.
How Guardrino and HisnLabs fit in
Guardrino is designed so that the people your AI serves are understood first and refused last. The simulation below shows the idea in three messages: personal data masked, an attack stopped with a request to rephrase rather than a bare refusal, and an everyday Arabic question let straight through. Guardrino is in development and not released.