How OmniRoute Guardrails Handle Prompt Injection and PII Redaction

OmniRoute protects users and downstream LLM providers through two dedicated guardrails—PromptInjectionGuardrail and PIIMasker—that operate early in the request pipeline to detect malicious instructions and redact personally identifiable information.

The OmniRoute routing layer implements configurable guardrails that intercept requests before they reach upstream providers. These defensive mechanisms are built on a shared BaseGuardrail foundation and can be fine-tuned via code or environment variables to match your security requirements.

Prompt Injection Detection

OmniRoute's PromptInjectionGuardrail (src/lib/guardrails/promptInjection.ts) scans user prompts for attempts to inject malicious instructions, system prompt overrides, or hidden directives.

Configuration Options

The guardrail behavior is controlled via PromptInjectionGuardrailOptions at line 31:

• mode — detect (log only), block (reject request), or safe (sanitize)
• threshold — confidence score required to trigger action (0.0–1.0)
• enabled — boolean flag to toggle the guardrail

Execution Flow

When a request arrives, the guardrail follows this path:

1. getLogger (line 113) initializes structured logging
2. getMode (line 134) and getThreshold (line 154) resolve runtime configuration
3. isEnabled (line 158) short-circuits processing if disabled
4. apply (lines 249–266) executes the classifier and returns a PromptInjectionGuardrailDecision (allowed, blocked, or safe) defined at lines 40–41

The guardrail auto-registers at startup via guardrailRegistry.register(new PromptInjectionGuardrail()) at line 293 of src/lib/guardrails/registry.ts.

Configuration Example

import { guardrailRegistry } from "@/src/lib/guardrails/registry";
import { PromptInjectionGuardrail } from "@/src/lib/guardrails/promptInjection";

guardrailRegistry.register(
  new PromptInjectionGuardrail({
    mode: "block",
    threshold: 0.75,
    enabled: true,
  })
);

PII Redaction

The PIIMasker (src/lib/guardrails/piiMasker.ts) prevents accidental leakage of sensitive data to LLM providers by masking personally identifiable information in both requests and responses.

Opt-In by Design

PII redaction is disabled by default. The PII_REDACTION_ENABLED constant in src/shared/constants/featureFlagDefinitions.ts defaults to "false", ensuring operators must explicitly enable this behavior.

Runtime Behavior

When activated, the guardrail:

• Scans prompts with regex-based detectors (email, credit card, SSN patterns)
• Replaces matches with "[REDACTED]" or configurable placeholders
• Applies the same masking to streaming response chunks via src/lib/streamingPiiTransform.ts

The mask is applied after Zod validation but before provider execution, guaranteeing that no raw PII reaches upstream LLMs when the flag is enabled.

Enabling PII Redaction

# .env or database feature flag

PII_REDACTION_ENABLED=true
PII_RESPONSE_SANITIZATION=true

Guardrail Architecture

Both guardrails extend BaseGuardrail, which provides:

• Unified logging infrastructure
• Context handling through GuardrailContext
• Safe error responses via buildErrorBody from open-sse/utils/error.ts

This design ensures policy violations are reported to clients without exposing internal stack traces or implementation details.

Request Pipeline Flow

Incoming /v1/chat/completions
        ↓
    Zod validation
        ↓
PromptInjectionGuardrail.apply
        ↓
PIIMasker.apply (if enabled)
        ↓
handleChatCore → Provider executor
        ↓
Response → PIIMasker (stream) if enabled
        ↓
      Client

Summary

• Prompt injection attacks are mitigated by PromptInjectionGuardrail with configurable modes (detect, block, safe) and confidence thresholds
• PII redaction is handled by PIIMasker and is opt-in only—disabled by default via PII_REDACTION_ENABLED
• Both guardrails operate before upstream provider contact, ensuring protective filtering at the edge
• Shared BaseGuardrail infrastructure provides consistent logging, context handling, and error sanitization
• Configuration supports both programmatic setup (TypeScript) and runtime toggles (environment variables)

Frequently Asked Questions

What happens when prompt injection is detected in block mode?

The PromptInjectionGuardrail immediately returns a blocked decision from its apply method (lines 249–266), halting request processing before any upstream LLM call occurs. The client receives a sanitized error response constructed via buildErrorBody without internal stack traces.

Can PII redaction be enabled for streaming responses only?

No—the PII_REDACTION_ENABLED flag activates redaction for both request payloads and streaming responses. However, the PII_RESPONSE_SANITIZATION flag can control response-side behavior independently. Streaming redaction is handled by src/lib/streamingPiiTransform.ts, which processes each SSE chunk through the same regex-based maskers.

Where does the prompt injection classifier run?

The classifier executes within the apply method of PromptInjectionGuardrail (lines 249–266 in src/lib/guardrails/promptInjection.ts). This occurs after Zod schema validation but before the request reaches handleChatCore and the provider executor.

Is the prompt injection guardrail enabled by default?

No—each guardrail must be explicitly instantiated and registered. The auto-registration at line 293 of src/lib/guardrails/registry.ts only executes when guardrailRegistry.register(new PromptInjectionGuardrail()) is called during application startup. Without this registration step, the guardrail remains inactive.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}