Guardrails

Overview

Guardrails in DeepIntShield provide content safety, security validation, and policy enforcement for LLM requests and responses. The system validates inputs and outputs in real-time against your policies, protecting against harmful content, prompt injection, PII leakage, and policy violations.

Plan availability

The built-in deterministic, prompt-injection, PII-detector, and OWASP LLM Top-10 guardrails are available on every plan, including Developer (free) - which can create 1 guardrail policy (upgrade to Team for unlimited policies). The in-tree ML detector sidecar (AI Models: prompt-injection, jailbreak, toxicity, hate-speech, PII and content-moderation classifiers) and supported external Safety Providers require their included Team-or-higher entitlement. The UI and API enforce the actual plan and workspace permissions.

What you configure

Use AI Guardrails → Policies to configure built-in and custom policy cards, their scopes, and their failure actions. Cards can use deterministic checks or the available model detectors. See Editing policy cards and patterns for the editor workflow.

Use AI Models for the real detector sidecar and Safety Providers for AWS Bedrock, Azure Content Safety, Google Model Armor, or a custom webhook. Creating a provider automatically creates its linked published input policy. Select that policy on the intended Virtual Key to enforce it on live inference. See Safety provider setup for each adapter’s credentials and request contract.

Key Features

Feature	Description
Multi-Provider Support	AWS Bedrock, Azure Content Safety, Google Model Armor, DeepIntShield Models, and custom webhooks
Dual-Stage Validation	Guard both inputs (prompts) and outputs (responses)
Real-Time Processing	Synchronous and asynchronous validation modes
Versioned Policies	Publish reviewed card and pattern definitions
Linked Provider Policies	Bind a configured detector or safety provider through its published policy
Sampling Control	Apply rules to a percentage of requests for performance tuning
Automatic Remediation	Block, redact, or modify content based on policy
Comprehensive Logging	Detailed audit trails for compliance

Navigating Guardrails in the UI

Access Guardrails from the DeepIntShield dashboard:

Page	Path	Description
Policies	AI Guardrails > Policies	Create, edit, and publish versioned policies and their cards
AI Models	AI Guardrails > AI Models	Connect the detector sidecar, choose detectors, and access Fine-tune (LoRA)
Safety Providers	AI Guardrails > Safety Providers	Configure, test, enable, or disable provider connections
Findings	AI Guardrails > Findings	Investigate policy and RAG findings

Input rules evaluate request content; output rules evaluate the response. Synchronous checks gate the returned result according to the published policy. With speculative dispatch, an upstream model call can begin while input checks run; account for that when choosing your data-release boundary.

---

Editing policy cards and patterns

Open AI Guardrails → Policies, select a policy, and open one of its cards. Built-in and custom cards have two tabs:

• Settings controls enablement, failure action, severity, summary, and the card’s preset selections. Cards that support redaction also expose replacement text.
• Patterns / JSON shows the generated detector configuration. Turn on Override generated configuration to edit it. The override replaces that card’s generated detectors and lists; it does not append hidden defaults.

An override can configure regular expressions, PII categories, model allowlists, JSON schemas, text limits, and other supported runtime checks. It applies only to the card’s supported scopes. Optional per-check scopes can narrow those stages. The card’s Settings still control its action, severity, summary, and enabled state. Review the effective configuration preview before saving.

Override example

On a custom card or a built-in card that supports input, set the failure action to Block request. This configuration blocks the project identifier project-orion on input. It also matches PROJECT_ORION and project orion:

{
  "checks": [
    {
      "name": "regex_match",
      "enabled": true,
      "priority": 10,
      "scopes": ["input"],
      "config": { "rule": "(?i)\\bproject[-_ ]orion\\b" }
    }
  ],
  "blockedDomains": [],
  "allowedActionClasses": [],
  "deniedActionClasses": []
}

Use Reset to generated settings to remove an override. The shared pattern catalog describes preset coverage and matching limits.

Redaction replacement text

For a card that supports redaction, choose the redaction failure action and set Redaction replacement text in Settings. This text replaces the content redacted by that card. Leave the field blank to use [REDACTED]. Save and publish the policy, then test the returned sanitized content with a representative input. Redaction applies to matching text. Destination and action restrictions still block execution when the card’s failure action is Redact.

SDK evaluation reports an allowed redaction as decision="allow_with_redaction". SDK 2.8.5 and later treat that decision as allowed; use SDK 3.2.0 for the current SDK contract. See guardrail results.

Save, publish, and test

Cancel discards the current card draft. Save details updates the policy draft; Save Policy updates and publishes an existing policy. Create Policy creates a draft version. Select that version and choose Publish, then verify its published status before testing enforcement.

For blocking tests, choose Sync, Block, the intended scope, and 100% sampling. Direct SDK evaluation selects applicable policies in the authenticated workspace. Live inference also needs the intended policy binding on its virtual key.

Policies saved with the current builder retain their saved checks until edited and republished. Legacy builder policies regenerate their checks from the installed catalog when loaded. Review and republish those policies with the current builder to pin their configuration.

Pattern validation

The editor checks JSON structure and common unsupported regex constructs. The management API validates patterns with the runtime’s Go/RE2 parser before creating, updating, publishing, or rolling back a policy version. Lookaround and backreferences are unsupported. Invalid configurations return an error instead of becoming silently ignored checks.

Policy definitions are limited to 2 MiB, individual check arrays to 512 entries, and individual patterns to 128 KiB. Card overrides require version 2 builder metadata, which the editor sets automatically; the API rejects overrides in legacy metadata.

Test both matching and benign inputs before publishing. Text signatures detect specified forms; they do not establish the truth of a claim or actual tool permissions. Use model/provider detectors when semantic analysis is required, and enforce permissions in your application and tool execution layer.

Supported Guardrail Providers

Server 3.2.0 exposes these current provider types:

Provider	Type	Setup
AWS Bedrock Guardrails	aws_bedrock	Region, guardrail ID/version, and authorized AWS credentials.
Azure AI Content Safety	azure_content_safety	Resource endpoint and API key.
Google Model Armor	gcp_model_armor	Project/location/template and supported Google authorization.
Custom Webhook (BYO)	webhook	HTTPS evaluation service and the supported request/response contract.
DeepIntShield Models	deepintshield_models	Operator-deployed detector sidecar configured through AI Models.

Use the Safety Providers guide for exact credential keys, provider-specific policy fields, live tests, and debugging. Partner products without a native entry can be integrated through a compatible webhook adapter you operate. The legacy managed provider is not a working runtime adapter and is not offered for new connections.

Configure AI Models

1. Open AI Guardrails → AI Models → Detectors.
2. If no models provider exists, use Connect DeepIntShield Models. Set the name and enabled state, then Connect. The sidecar endpoint and deployment credentials are operator-managed.
3. Select the intended provider when more than one exists, choose supported detectors, and click Save selection.
4. Inspect its automatically linked policy in Policies and bind that policy to the Virtual Key that will send the request.
5. Validate using representative benign and triggering inputs and inspect Findings. Fine-tune (LoRA) is a separate AI Models tab and requires its deployment prerequisites.

The current policy editor links to Open AI Models instead of selecting a model by name on an ordinary card. If a migrated policy contains legacy metadata.detector_model, use Remove legacy detector selection and configure an actual models provider. An enabled policy cannot be saved while the legacy selection remains.

Configure Safety Providers

1. Open AI Guardrails → Safety Providers and choose New Provider.
2. Enter its name, actual provider type, mode, required region/endpoint, and optional customer scope. Use Credentials JSON and Connection Metadata JSON for the selected adapter’s configuration.
3. Save, then use Test to check live connectivity and authorization. On updates, a blank credentials field preserves stored secret material.
4. Inspect the automatically created policy with the same name. It begins as a published input policy with synchronous blocking evaluation and a 10-second timeout, enabled according to the provider’s state at creation.
5. Bind the intended policy on the Virtual Key and verify runtime findings. If you need other stages or custom controls, explicitly review and publish the corresponding policy configuration.

Captured with synthetic demonstration data.

Guardrail Rules

The current console authors runtime checks as policy cards and versioned policy definitions. Follow Editing policy cards and patterns for the complete workflow. Older Guardrails → Configuration bookmarks open Policies. The current UI does not expose the former standalone CEL Save Rule or Add Profile workflows.

Managing Profiles

Manage reusable provider connections under Safety Providers, and bind their published policies through the Virtual Key. Use the current provider_type, credentials, and connection_meta contract from the provider guide. Provider selection, published policy scope, and the request’s key binding all contribute to whether a check runs. A successful connection test alone does not prove live enforcement.

Using Guardrails in Requests

Attaching guardrails to a virtual key

In production, guardrails are attached to a virtual key in the dashboard (Access & Credentials → Virtual API Keys, in the key’s Guardrail Policies field) and run automatically on every request made with that key - there is no per-request header to set. Just call the gateway as usual:

curl -X POST https://app.deepintshield.com/v1/chat/completions \
  -H "Authorization: Bearer sk-ds-your-virtual-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [
      { "role": "user", "content": "Help me with this task" }
    ]
  }'

The guardrails bound to that key use their configured stages and enforcement mode. Synchronous input checks gate the result; with speculative dispatch an upstream call can begin while input checks run. Synchronous output checks run before the response is returned, while asynchronous output checks record later evidence.

Note: Passing raw guardrail definitions inline on a request (x-deepintshield-input-guardrails / x-deepintshield-output-guardrails) is restricted to the dashboard test-lab simulation flow. For live traffic, bind guardrails to the virtual key as shown above.

Reading the guardrail outcome

DeepIntShield reports the guardrail result on response headers, not in the response body:

Header	Values	Meaning
x-deepintshield-guardrail-status	pass, blocked, redacted, flagged	Outcome of the guardrail evaluation
x-deepintshield-guardrail-mode	sync, async, shadow	Execution mode the guardrail ran in

Passed (HTTP 200) - the normal completion is returned, with x-deepintshield-guardrail-status: pass:

{
  "id": "chatcmpl-abc123",
  "object": "chat.completion",
  "model": "gpt-4o-mini",
  "choices": [
    {
      "index": 0,
      "message": { "role": "assistant", "content": "I'd be happy to help..." },
      "finish_reason": "stop"
    }
  ]
}

Blocked (HTTP 403) - the request is rejected with a guardrail_blocked error and x-deepintshield-guardrail-status: blocked:

{
  "error": {
    "type": "guardrail_blocked",
    "code": "guardrail_blocked",
    "message": "Request blocked by guardrail policy"
  }
}

When a guardrail is configured to redact rather than block, the completion is returned (HTTP 200) with the offending content removed and x-deepintshield-guardrail-status: redacted. In monitor / shadow mode the request is never blocked - the violation is only recorded - and the status header reflects flagged.

Redactions from several cards compose: each is applied to the accumulated text while detection still runs against the original content. Redact findings from the DeepIntShield Models detectors rewrite the payload from the detector’s character spans; a finding without usable spans becomes a block rather than an unredacted release. See PII redaction.

Policies saved by the policy builder store the exact checks you selected, and the runtime treats them as authoritative: presets you left unticked are not re-enabled, custom cards apply to every stage they are scoped to, the OWASP Agentic ASI cards keep their declared stages, and blocked-domain and action-class restrictions take the action and severity of the card that owns them. Restrictions added through advanced settings without an owning card still block.

For explicit Python input, output, action, MCP, and RAG checks, see Chat and guardrails. SDK exceptions expose the same stable guardrail_blocked identifier through the centralized error catalog; branch on the code rather than response prose.

Multimodal guardrails

By default the guardrail engine evaluates text, chat, responses and passthrough requests. Multimodal guardrails extend the same policy engine, decision path and x-deepintshield-guardrail-* headers to non-text endpoints - so image, audio and video traffic is governed exactly like text, with one consistent verdict model.

What gets guarded

Endpoint	Request type	What is evaluated
Image generation	image_generation	The prompt (and negative prompt)
Image edit	image_edit	The prompt + text embedded in the source images (PNG/JPEG metadata, OCR-style strings)
Speech / TTS	speech	The text to synthesize + voice instructions
Transcription	transcription	The produced transcript (output side)
Video generation	video_generation	The prompt (and negative prompt)
Embeddings	embedding	The input text(s)
Rerank	rerank	The query + candidate documents

The text these requests already carry is guarded by the existing text detectors. Binary artifacts (source images, generated images, audio, video) are forwarded to the guard runtime as attachments - fingerprinted with a content hash for deduplication - where a modality-extraction stage resolves them to text (document/OCR text today; OCR/STT/keyframe extractors are pluggable) and optional modality detectors (vision/audio safety models) score them natively.

Enabling it

Multimodal guarding is off by default - when disabled, no attachment extraction or modality-detector work is scheduled, although ordinary request processing and feature-gate checks still have measurable overhead. Enable it with environment variables (Helm: deepintshield.guardrails.*):

Variable	Component	Effect
GUARDRAILS_MULTIMODAL	gateway	Gate image/audio/video/embedding/rerank requests into the engine and guard the text they carry; forward artifacts as attachments
GUARDRAILS_MODALITY_INLINE_BYTES	gateway	Inline raw artifact bytes into the guard request so the extraction stage can process them (otherwise only metadata + content hash are sent)
GUARDRAILS_STREAM_ACCUMULATE	gateway	Guard streamed output on a growing window so a violation split across chunks is caught
DEEPINTSHIELD_GUARD_MODALITY_EXTRACT	guard runtime	Run the modality-extraction / detector stage over forwarded attachments

Note

No SDK or client change is required. Keep using the native provider SDKs through the gateway - multimodal requests are guarded transparently, and a blocked request surfaces as the usual 403 guardrail_blocked error.

Performance & scale

• No extraction work when off. The feature gate still has ordinary request processing overhead. When enabled, text already present in prompts or transcripts reuses the text path; attachment extraction adds workload-dependent latency.
• Bounded work - per-request attachment count, per-asset byte size and extracted-text length are all capped, and identical assets are deduplicated by content hash. These limits bound individual jobs; size the worker pool and timeouts for your asset mix and concurrency.
• Scales horizontally - heavy extraction/detection runs in the separately deployable guard runtime, off the gateway hot path.

Analytics

Multimodal activity appears on the Guardrail Metrics → Multimodal tab (workspace analytics): a decision timeline by modality, request distribution, decision breakdown, and attachment-level findings - using the same filters and date range as the other guardrail dashboards.