AI Guardrails Should Be Rules You Own
Credentials look the same everywhere. Personal data does not. Why guardrails work best as profiles you define, with a baseline teams cannot weaken.
In this post
Why teams switch guardrails off
The most common guardrail failure is not a missed detection.
It is a team turning the guardrail off because it blocked something it should not have.
Picture this
A developer pastes a sample customer record into a prompt while debugging. A vendor-tuned filter flags it, the test run fails, and a team lead is asked why the assistant is broken. Two sprints later the filter is disabled for that app, temporarily. Nobody turns it back on.
Filters you cannot see into, tune, or explain train people to route around them. Guardrails work when the people they affect understand the rule, can change it, and can see what it did.
A guardrail that gets switched off protects nobody.
Two kinds of sensitive data
Not everything sensitive is the same kind of problem.
Some of it looks identical everywhere, and some of it only exists in your business.
Universal: credentials
- API keys, tokens, private keys, password assignments
- The same format in every company
- Cloptima detects them out of the box
Local: personal and business data
- National ID formats, phone numbers, internal codenames, customer identifiers
- Formats and meaning depend on your region and business
- You define the rules, starting from templates
- Cloud and developer credentials: AWS access keys, GitHub, GitLab, Slack, Stripe, npm, Hugging Face, and SendGrid tokens
- AI provider keys: Anthropic, OpenAI, and Google
- Private keys, bearer tokens, and password or secret assignments
- Cloptima's own tokens and virtual keys, so a leaked key in a prompt is caught too
Treating the two differently is what keeps false positives low. You are not asked to trust one global detector with your national ID formats.
Two actions, rule by rule
Every template and custom rule in a guardrail profile has its own action, and the action decides what a match does.
Rules protect the request, so sensitive data is handled before any model sees it.
| Action | What happens | Good for |
|---|---|---|
| Redact | Replaces the match with a placeholder before the model sees it | Credentials and personal data you want to keep flowing |
| Block | Refuses the request with a clear message | Content that must never leave, such as a customer ID bound for a third-party model |
Redaction keeps work flowing in both directions. The model reasons over the placeholder, and when its answer repeats one, your application gets the original value back.
Before: Debug this config: api_key = abc123def456ghi789
After: Debug this config: [SECRET_K7Q2M4XAB3CD]Rules you can read
Custom rules are deliberately plain.
A rule is a list of terms, one regular expression, or a value next to its label, with an id and an action.
resource "cloptima_llm_guardrail_profile" "customer_data" {
name = "Customer data protection"
definition = {
protect = [
{ template = "secrets", action = "redact" },
{ template = "us_personal_data", action = "redact" },
{ rule = "employee_id", match = { label = "(?i:employee id|badge)", value = "E\\d{6}" }, action = "redact" },
{ rule = "codename", match = { terms = ["Project Falcon"] }, action = "block" },
]
}
}Rules run on a linear-time matcher. In plain words, that is a guarantee: no pattern, however it is written, can make a request slower or stall other traffic. To keep that promise, rules have sensible bounds: up to 10 terms per rule, up to 64 characters per term, up to 128 characters per pattern, and no look-ahead or back-references.
One baseline, many teams
Security wants one floor. Teams want to add their own rules. A guardrail baseline gives you both.
| Baseline (whole organization) | Team profile (research) | What happens |
|---|---|---|
| Redact credentials | Block the codename Project Falcon | Credentials are redacted everywhere. The codename is blocked for research. |
| Redact US personal data | Block US personal data | Personal data is blocked for research. A block in either profile wins. |
Each profile is evaluated as written and the strictest outcome wins. A team profile can add protection, and it cannot weaken the baseline.
Roll out in four weeks
A guardrail you trust is one you have watched work.
This schedule moves from evidence to enforcement without surprising anyone.
- 1
Week 1: watch first
Create a profile with Secrets and your regional templates, and attach it to one policy in Monitor only. Review what it would redact or block.
- 2
Week 2: redact
Enforce that policy. Work continues, and secrets and personal data stop reaching models.
- 3
Week 3: block what must never leave
Move the rules that matter most to Block, with a clear message for developers.
- 4
Week 4: make it the baseline
Switch on Org baseline, and every policy gets the same protection.
Where meaning-aware checks fit
Local rules are fast and predictable, but they cannot understand meaning.
For prompt injection, jailbreak attempts, harmful content, and sensitive information in free text, connect a safety service you already trust.
| Provider | Good for | You bring |
|---|---|---|
| Azure AI Content Safety | Prompt Shields and harm categories: hate, self-harm, sexual, and violence | A Content Safety resource |
| AWS Bedrock Guardrails | Your own guardrail: content filters, denied topics, word filters, sensitive information | A guardrail id, version, and region |
| Google Model Armor | Prompt injection, responsible-AI filters, and sensitive data in a template you control | A template and a service account |
| Your own webhook | Any custom check | An HTTPS endpoint that answers allowed or not |
Local rules run first, so a request they block never pays for a provider scan. Each profile also chooses what happens if its scan cannot run: keep traffic flowing on your local rules, or block the request. Cloptima never adds a check you did not configure.
What shows up in the audit trail
Compliance conversations go better with evidence.
Guardrails leave a record you can point to.
- Profile changes are versioned, with who changed what and when
- Under a policy in Monitor only, what a profile would have blocked appears in Audit
- A blocked request names the rule that matched, never the content that matched it
- The response a developer sees names the rule, so the fix is obvious
- A request that continued without its provider scan shows as Not checked, with the cause