Guardrails for AI in Drupal: Ensuring Data Safety and Compliance¶
AI guardrails for Drupal sites on the Dropsolid AI Gateway: what runs in your site, what runs at the gateway, and what each costs in response time. Personal data masking keeps customer data away from the model provider at almost no cost, and one attack detection guardrail covers most public features.
If you put an AI feature in front of real users, two questions come up fast.
- What stops someone misusing it? and…
- What stops personal data from ending up with a model vendor?
Drupal's AI module handles the first one well on its own. The second needs help from outside the site. This page explains where each check runs, what it costs, and how to choose.
It assumes your Drupal site runs against the Dropsolid AI Gateway. Guardrails come with the gateway, so there's nothing extra to install on our side. This is the first version of the guardrail layer. The configuration is stable, and because the guardrails run centrally, improvements reach your site without a deploy.
Two kinds of guardrail¶
In your Drupal site. The ai module ships with guardrails that run as PHP plugins. They check the prompt against a rule and pass or stop it. Nothing leaves your server.
| Plugin | What it does |
|---|---|
| Regular expression | Blocks or rewrites text that matches a pattern you write |
| Restrict to topic | Keeps the conversation on a subject you define |
| Input length limit | Rejects prompts longer than a limit you set |
In the AI Gateway. Your site names the guardrails it wants (opt-in), and the gateway applies them before the prompt reaches the model. They're maintained centrally, so every site benefits when detection improves. The trade-off is a network round trip on shared capacity.
What the gateway provides¶
| Guardrail | What it does | Speed |
|---|---|---|
| Personal data masking | Replaces personal data with placeholders before the model sees it | ⚡ Instant |
| Keyword filter | Blocks text containing terms from a category list | ⚡ Instant |
| Prompt injection detection | Spots attempts to override the assistant's instructions | ⏳ Adds time |
| Spam detection | Spots spam and attempts to waste tokens | ⏳ Adds time |
| Harmful content detection | Spots requests for harmful content | ⏳ Adds time |
The first two apply a rule. The last three ask a small dedicated model for a verdict, which takes longer. Most choices on this page follow from that split.
Personal data masking¶
Your site sends:
Contact Sarah Johnson at sarah.johnson@example.com or +32 475 12 34 56,
IBAN BE68 5390 0754 7034.
The model receives:
Contact <PERSON> at <EMAIL_ADDRESS> or <PHONE_NUMBER>, IBAN <IBAN_CODE>.
The replacement happens inside the gateway, so the model provider never holds the real values. It covers names, email addresses, phone numbers, IBANs, Belgian VAT numbers, Belgian national registry numbers and medical licence numbers.
If you've wanted a capable hosted model but couldn't justify sending customer records to it, this solves that. It's also the cheapest guardrail in the list.
What it costs¶
We measured with an advanced reasoning model, which thinks before it writes. Without guardrails, a typical search answer took about 15 seconds from request to the last word. That covers the reasoning step and the full answer. The answer streams, so users start reading well before that. A faster, non-reasoning model finishes much sooner. What matters here is the time guardrails add on top.
- Masking and the keyword filter are close to free. Under a tenth of a second. There's no performance reason to leave masking off.
- Each detection guardrail adds about half a second to a second. They run one after another, so three cost about three times as much as one.
- Traffic makes the gap bigger. Without guardrails, the model provider absorbs extra traffic. Guardrails run on shared gateway capacity, so requests start to queue. With four requests at once, masking plus one detection guardrail added under two seconds. All five added more than seven.
Setting it up¶
- Sync. In the LiteLLM provider settings, click "Sync guardrails from LiteLLM". Drupal picks up every guardrail the gateway offers. Run it again any time, it won't create duplicates.
- Group them into a set. Guardrails are applied as a set. A set separates checks before generation from checks after it. Give every set a description, because a set saved without one can fail to load.
- Attach the set to a feature. Today the AI Search Block lets you pick a set per block, so different features on one site can run different policies. Support for AI Answers is on its way. There's also a site-wide setting that applies a set to every AI request, which suits something like masking.
You need the ai module 1.4.0 or later. The sync and the block setting are on development branches until their next releases:
composer require "drupal/ai_provider_litellm:1.3.x-dev" "drupal/ai_search_block:1.1.x-dev"
Best practices¶
- ✅ Start with masking plus prompt injection detection. For most client-facing features, that covers the compliance need and the main attack type for about a second of extra time. Add more only with a specific reason.
- 🏠 Keep site-specific rules in Drupal. Length limits, topic rules, and patterns like an unannounced product name belong in the site. They cost nothing and combine with gateway guardrails in one set.
- ⌨️ Keep detection off anything that fires as the user types, like autocomplete. Masking is fine there.
- 🕒 Skip attack detection on trusted input. Content from your own editorial workflow doesn't need it. Keep masking if it holds personal data.
- 🧪 Test both directions. Send something legitimate from your own domain that sits near the edge (for a bank, a sentence about fraud investigation) and check it gets a real answer. Then send an obvious attack and check it's rejected. A guardrail that blocks everything looks the same as one that works, until a user complains.
Guardrails have soft edges¶
Every guardrail makes a best guess, and each one gets some cases wrong in both directions. Treat the layer as a filter with soft edges, not a wall.
The keyword filter shows this best. It matches words without reading the sentence, so in our tests it blocked "Our financial crime unit filed a report with the federal police" because of the word "crime". The detection guardrails read the whole sentence and passed it. They have blind spots too: each one watches for its own kind of problem and can miss others.
- Test with real prompts from your domain before going live.
- Design the experience so a false block isn't a dead end for the user.
- Pick guardrails that match the risk you care about, instead of stacking all of them.
If a guardrail keeps getting in your way, get in touch. We'll help you find a better configuration, and your feedback shapes how the guardrails improve.
Not the whole answer¶
Guardrails reduce risk. They don't replace the rest of your security model. The hosted models have their own safety layers, and guardrails sit in front of them.
What guardrails add: personal data never reaches the provider, the policy is yours rather than the vendor's, and it applies the same way across every model you route to. What they don't replace: access control, rate limiting, and good judgement about what an assistant can reach.
Summary¶
| If you're building | Use |
|---|---|
| Public assistant handling customer data | Masking plus prompt injection detection |
| High-traffic public feature | Masking, and talk to us about capacity before adding detection |
| Internal tool for signed-in staff | Masking, or nothing |
| Anything that fires as the user types | Masking and keyword rules only |
| Editorial or batch generation | Masking if personal data is involved |
Turn masking on. Add one detection guardrail where untrusted users can reach the feature. Beyond that, measure before you add more.