How Guardrino is designed: layers, policies and a test before every change

Guardrino is designed as a gateway: your applications and agents send their requests to it, it checks them, and it forwards them to whichever language model you use, hosted or your own. The answer comes back the same way and is checked as it streams. Two ideas shape everything else: check fast first and look deeper only when a message is unclear, and never get in the way of normal users.

Layer 1: fast rules, on every message

The first layer is a set of rules that run on every message in both directions, in a tiny fraction of the time a model takes to answer. They handle what can be recognised by its shape:

• Secrets: API keys, tokens and passwords pasted into a chat or appearing in an answer.
• Personal data from the Gulf, checked properly rather than guessed: an Emirates ID, a Saudi ID or Iqama, a GCC IBAN (validated with its mod-97 check digits ^[1]), phone and card numbers.
• Your own lists: words and names to block, values that are always fine (your support number), rules you switch off for one app.

Before anything is checked, the text is cleaned up so that a trick in the spelling cannot hide a word. This step is Arabic-aware from the start:

• Tashkeel, the short-vowel marks of Arabic ^[2], and tatweel, the stretching stroke (ـ) that lengthens a word ^[3], are folded away for matching, so تَجَاهَلْ and تجـــاهل are read as تجاهل.
• Arabizi, Arabic written in Latin letters and digits (3 for ع, 7 for ح) ^[4], is read as Arabic.
• Look-alike letters, invisible characters and simple encodings are normalised or decoded, following the same idea as Unicode normalisation ^[5].

Folding is used to match, never to judge. Fully vowelled Arabic is normal in the Quran, poetry and school material, so tashkeel on its own is never treated as a sign of an attack.

Layer 2: a small classifier that only decides

The second layer is Guardrino-t7, a small model HisnLabs is training for one job: to answer typed questions about a message. Is it a direct attempt to take control of the assistant? An instruction hidden in a document or tool result? An attempt to extract the system prompt? Off topic for this app? Disguised in an encoding? It is trained on Arabic with and without tashkeel, on Arabizi and on English.

Guardrino-t7 only classifies. It reads a message once and returns scores; it never writes text. A model that cannot generate anything cannot be talked into saying something it should not, which makes it a dependable judge and keeps it light enough to run on every message that needs it.

Layer 3: a deeper review, only when unclear

Most messages are settled by the first two layers. The few that remain unclear go to a larger guard model that reviews the meaning: what is really being asked, and whether the conversation as a whole is heading somewhere the policy does not allow. Keeping this step for unclear cases is what makes the design both thorough and quick for everyone else.

Five actions, not one

This ladder is how the design keeps the assistant useful: the customer who pasted an ID still gets their answer, only without exposing the number.

Policies as code

Each application gets its own policy: which checks are on, which action applies to what, which words and values are on its lists. Policies are planned to be kept as versioned files, so every change has a history, can be compared with the version before and can be rolled back. Policies can also be written in plain language through an assistant; the next lesson walks through it.

A test panel before every deployment

A change to a policy is a change to how your AI behaves, so the design treats it like a software release. Each policy carries its own test cases: messages that must be caught and ordinary messages that must pass. Before a draft goes live:

1. The draft is validated, so a typo cannot reach production.
2. The test cases run against exactly this draft and against the live policy, side by side, so you see what the change catches and what it would newly flag.
3. It deploys only when every case passes, or when someone acknowledges a failing case with a written reason, which is kept in the audit log.
4. It can start in watch-only mode: Guardrino records what it would have done on real traffic and blocks nothing, so you tune with evidence before you enforce.

An audit trail you can show

Every decision and every change is planned to be logged: what was checked, which rule acted, which policy version was live, who changed it and why. Personal data in the logs is masked. The logs are designed to feed your security team’s own tools, so AI joins the monitoring you already have.

The console prototype

HisnLabs has built a working prototype of the admin console, in Arabic, English and French with full right-to-left layout. It shows the planned screens: a policy editor with versions, the rule tests and the deploy gate, the plain-language assistant, a playground to try messages, a review queue, an incident trace, and settings for apps, model connections, users and the audit log. It runs on sample data; it is a prototype, not a product you can use yet.

To see the design in motion, visit the Guardrino page, where companies can also ask to join the pilot programme.