Guardrail Rules
Configurable rules that evaluate every AI request and response.
Rule Types
| Type | Description |
|---|---|
| contains_pii | Detects emails, phone numbers, SSNs, custom PII patterns |
| contains_secret | Detects API keys, tokens, AWS keys, high-entropy strings |
| token_limit_exceeded | Enforces maximum token limits per request |
| model_allowlist | Restricts which AI models can be used |
Actions
| Action | Behavior |
|---|---|
| allow | Log the violation but allow the request |
| warn | Log a warning and allow the request |
| block | Block the request entirely |
| redact | Replace matched spans with [REDACTED:pii] or [REDACTED:secret] before storage. The original text is never persisted. Redaction applies to what SignalVault stores — it does not rewrite the payload sent to your provider. Via the SDK the request proceeds and you receive the decision; via the proxy a redact rule blocks rather than forwarding a partially-redacted prompt. |
How Redaction Works
Redaction happens inside the ingest layer, before encryption — raw text never reaches the database.
- The
redactionsarray in the API response lists the rule types that redacted content and how many matches each removed, for example[{"type": "contains_pii", "count": 2}]. It does not report locations — SignalVault redacts what it stores, so there is nothing for your application to apply. - The dashboard prompt/response viewer shows the redacted version because the encrypted field stores the already-redacted text.
- Redaction applies to both
ai.requestprompts andai.responseoutputs. - When redaction fires, the raw
messages/outputkeys are also removed from the stored JSONB payload.
Decision Hierarchy
When multiple rules fire, the strictest action wins: block > redact > warn > allow.
What a new app starts with
Every new app is created with a set of default rules already enabled, scoped to all environments.
Most of them warn rather than block, so your first requests are
logged and flagged without being rejected. If you are evaluating SignalVault and expect a request to be
blocked, check this table first — a warn
decision means the guardrail fired and allowed the request through, which is working as intended.
| Rule | Default action | Plans |
|---|---|---|
| contains_pii | warn | All |
| contains_secret | warn on trial, block on paid plans | All |
| token_limit_exceeded | block | All — 8 000 tokens |
| prompt_injection | block | Growth and Enterprise |
Secret detection starts as warn on the free trial
deliberately: a first request that trips the entropy filter shows up as a violation to investigate rather than a
400 that looks like a broken integration.
Promote it to block in the Rules tab once you
are happy with what it catches. Every default can be edited, disabled or deleted.
Managing Rules
Rules are managed per-app in the dashboard under the Rules tab. You can create, edit, enable/disable, and delete rules. Each rule can be scoped to a specific environment or applied to all environments.