AI Security Gateway

Appearance

Creating Custom Security Policies ​

This guide explains how to create your own organization-specific security policies using the AI Security Gateway's web interface.

Policy Quick Start ​

The gateway provides three ways to create custom policies:

  1. Use a Template - Start with pre-configured templates and customize
  2. Use the Pattern Library - Add pre-built patterns to new or existing policies
  3. Build from Scratch - Create completely custom policies using the Policy Builder

All policy creation and management is done through the web interface - no file editing required.

Policy Builder Workflow

Method 1: Create from Template ​

The fastest way to create a custom policy is to start with a template.

Access Templates ​

  1. Navigate to Policies → Templates tab
  2. Browse available templates by type (MCP, LLM, Both)
  3. Use the search bar to filter templates by name or description

Select a Template

Select and Customize Template ​

  1. Review template details:

    • Click View Details to see template contents
    • Review rule count, severity level, and usage notes

  2. Use the template:

    • Click Use Template button
    • The Policy Builder opens with pre-filled form

  3. Customize the template:

    • Edit Policy Name (required) - e.g., "acme-corp-security"
    • Select Policy Type (MCP, LLM, or Both)
    • Update Description to match your use case
    • Set Severity and Version
    • Modify rules, patterns, and redaction settings as needed

  4. Save your policy:

    • Click Validate to check policy structure
    • Click Save Policy to create your custom policy

Method 2: Use Pattern Library ​

Add pre-built detection patterns to new or existing policies.

Access Pattern Library ​

  1. Navigate to Policies → Pattern Library tab
  2. Browse categories:
    • PII Detection - Patterns for personally identifiable information
    • Toxicity Detection - Patterns for toxic/harmful content
    • Prompt Injection - Patterns for prompt injection attacks

Select a Pattern

Add Patterns to Your Policy ​

Adding Individual Patterns:

  1. Browse patterns in your desired category
  2. Expand pattern details by clicking "View Patterns"
  3. Click "Use" next to a specific pattern
  4. Pattern is automatically added to your policy's last rule

Adding All Patterns from a Category:

  1. Find the category you want (e.g., PII Detection)
  2. Click "Use All Patterns" button on the category card
  3. All patterns from that category are added to your policy

Pattern Library Categories:

  • PII Detection: Email addresses, phone numbers, credit cards, SSNs, IP addresses, etc.
  • Toxicity Detection: Hate speech, profanity, harassment, threats
  • Prompt Injection: Jailbreak attempts, system prompt manipulation, role confusion

Method 3: Build from Scratch ​

Create a completely custom policy using the Policy Builder.

Access Policy Builder ​

Option 1: From MCP/LLM Security Pages

  1. Navigate to MCP Security or LLM Security page
  2. Click + Create Policy button
  3. Policy Builder modal opens

Option 2: From Policies Page

  1. Navigate to Policies → Policy Builder tab
  2. Start configuring your policy

Build Custom LLM Policy

Policy Builder Form Fields ​

Policy Builder Form Fields ​

The Policy Builder is organized into four main sections:

1. Basic Information Section ​

Policy Name (required)

  • Unique identifier for your policy
  • Example: "acme-corp-security", "finance-dept-policy"

Policy Type (required)

  • MCP: For Model Context Protocol servers
  • LLM: For Large Language Model APIs
  • Both: For policies that work with both types

Description

  • Explain the purpose of your policy
  • Example: "Security policy for ACME Corp - Protects employee IDs and internal API keys"

Severity

  • Low, Medium, High, or Critical
  • Sets the baseline severity for this policy

Version

  • Track policy versions (e.g., "1.0", "2.1")

2. Security Rules Section ​

Add detection rules to identify threats and patterns.

Per-Rule Fields:

  • Rule ID: Unique identifier (e.g., "COMPANY_001")
  • Rule Name: Descriptive name (e.g., "Employee ID Detection")
  • Category: Type of security check (e.g., "Data Protection")
  • Severity: Low, Medium, High, or Critical
  • Description: What this rule detects
  • Patterns: One regex pattern per line (multi-line supported)

Example Rule:

Rule ID: COMPANY_001
Name: Employee ID Detection
Category: Data Protection
Severity: Medium
Description: Detect company employee ID patterns in traffic
Patterns:
  \b(EMP|EMPL)[-_]?\d{6}\b
  \b[A-Z]{2}\d{6}\b

Add/Remove Rules:

  • Click + Add Rule to create a new rule
  • Click Remove to delete a rule

3. Blocked Patterns Section ​

Define patterns that should be immediately blocked.

Per-Pattern Fields:

  • Pattern (required): The pattern to block
  • Severity: Low, Medium, High, or Critical
  • Action: block, warn, or log
  • Reason: Why this pattern is blocked

Example Blocked Pattern:

Pattern: \bdrop\s+table\s+company_data\b
Severity: Critical
Action: block
Reason: Attempted access to protected company data table

Add/Remove Patterns:

  • Click + Add Blocked Pattern to create a new pattern
  • Click Remove to delete a pattern

4. Redact Patterns Section ​

Define patterns that should be redacted (replaced) rather than blocked.

Per-Pattern Fields:

  • Pattern (required): The pattern to redact
  • Severity: Low, Medium, High, or Critical
  • Redact String: Replacement text (default: "[REDACTED]")
  • Reason: Why this pattern is redacted
  • Unmask for user (toggle): Enable to restore original values in responses
  • Placeholder Format: Format for temporary placeholders (e.g., <{TYPE}_{COUNT}>)

Redact and Unmask

Example Redact Pattern (without unmasking):

Pattern: \b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b
Severity: High
Redact String: [CREDIT_CARD_REDACTED]
Reason: Credit card numbers should be redacted from logs
Unmask for user: OFF

Example Redact Pattern (with unmasking):

Pattern: \b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b
Severity: Medium
Redact String: [EMAIL_REDACTED]
Reason: Email addresses should be hidden from LLM provider
Unmask for user: ON
Placeholder Format: <{TYPE}_{COUNT}>

When "Unmask for user" is enabled:

  1. Sensitive data is masked with placeholders (e.g., <EMAIL_1>) before sending to LLM provider
  2. Original values are stored securely
  3. Response is automatically unmasked before returning to user

Add/Remove Patterns:

  • Click + Add Redact Pattern to create a new pattern
  • Click Remove to delete a pattern

Organization-Specific Pattern Examples ​

Use these examples as starting points for your custom rules.

Employee Information Detection ​

In Policy Builder → Security Rules:

Rule ID: COMPANY_001
Name: Employee ID Detection
Category: Data Protection
Severity: Medium
Description: Detect company employee ID patterns
Patterns:
  \b(EMP|EMPL)[-_]?\d{6}\b
  \b[A-Z]{2}\d{6}\b
  \bSTAFF[-_]?\d{4,8}\b

API Key Protection ​

In Policy Builder → Blocked Patterns:

Pattern: \bCOMP[-_]?[A-Za-z0-9]{32,64}\b
Severity: Critical
Action: block
Reason: Company API keys must never be exposed

In Policy Builder → Redact Patterns:

Pattern: \byour[-_]?api[-_]?[A-Za-z0-9]+\b
Severity: High
Redact String: [API_KEY_REDACTED]
Reason: API keys should be redacted from logs
Unmask for user: OFF

Internal System Protection ​

In Policy Builder → Blocked Patterns:

Pattern: /internal/
Severity: High
Action: block
Reason: Access to internal systems blocked
Pattern: /admin/company/
Severity: High
Action: block
Reason: Company admin endpoints are restricted
Pattern: /api/v[0-9]+/internal
Severity: High
Action: block
Reason: Internal API endpoints blocked

Financial Data Protection ​

In Policy Builder → Redact Patterns:

Pattern: \b\d{4}[-\s]?\d{4}[-\s]?\d{4}[-\s]?\d{4}\b
Severity: Critical
Redact String: [CREDIT_CARD_REDACTED]
Reason: Credit card numbers must be redacted for PCI compliance
Unmask for user: OFF
Pattern: \b\d{3}-\d{2}-\d{4}\b
Severity: Critical
Redact String: [SSN_REDACTED]
Reason: Social Security Numbers must be protected
Unmask for user: OFF
Pattern: \b[A-Z]{2}\d{2}[A-Z0-9]{4}\d{7}([A-Z0-9]?){0,16}\b
Severity: High
Redact String: [IBAN_REDACTED]
Reason: IBAN numbers must be redacted
Unmask for user: OFF

Project and Customer Codes ​

In Policy Builder → Security Rules:

Rule ID: COMPANY_004
Name: Project Code Detection
Category: Data Classification
Severity: Low
Description: Track project codes in requests
Patterns:
  \b(PROJ|PROJECT)[-_]?[A-Z]{2,4}[-_]?\d{3,6}\b
  \b(CUST|CUSTOMER)[-_]?\d{6,10}\b
  \b(CONTRACT|CNTR)[-_]?[A-Z0-9]{6,12}\b

Testing Your Policy ​

Validate Policy Structure ​

Before saving:

  1. In the Policy Builder, click Validate button
  2. Review validation results for:
    • Missing required fields
    • Invalid regex patterns
    • Duplicate rule IDs
  3. Fix any errors before saving

Test Against Sample Content ​

After saving:

  1. Navigate to Policies → Policy Testing tab
  2. Select your custom policy from the dropdown
  3. Enter test content in the text area:
    • Sample employee IDs: EMP123456, AB987654
    • Sample API keys: COMP_abc123def456
    • Sample internal URLs: /internal/data
  4. Click Test Policy
  5. Review detection results:
    • Which patterns matched
    • Severity levels assigned
    • Actions that would be taken (block/monitor/redact)

Policy Testing

Test Pattern Matching ​

Test individual patterns:

  1. In Policy Testing, enter sample data that should match your patterns
  2. Verify patterns are detected correctly
  3. Check that severity levels are appropriate
  4. Ensure redaction strings are applied correctly

Example test content:

Employee EMP123456 accessing /internal/data
Project PROJ-ABC-001234 with API key COMP_abc123def456
Customer CUST123456789 with credit card 4532-1234-5678-9010

Test Redaction and Unmasking ​

For redact patterns with unmasking enabled:

  1. Create a test proxy with your policy
  2. Send a request containing sensitive data
  3. Check proxy logs to verify:
    • Data was masked before sending to LLM provider
    • Response contains unmasked data for the user
    • Placeholder format is correct (e.g., <EMAIL_1>)

Deploying Your Custom Policy ​

Apply to New Proxy ​

  1. Navigate to MCP Security or LLM Security page
  2. Click + Create Proxy
  3. Fill in proxy details (name, target, port)
  4. In Policy Selection, find your custom policy
  5. Select your custom policy (checkbox)
  6. Click Create

Apply to Existing Proxy ​

  1. Navigate to Proxies page
  2. Find your proxy and click Edit
  3. Scroll to Policy Assignment section
  4. Select your custom policy
  5. Click Save

Combine with Default Policies ​

You can use your custom policy alongside default policies:

  1. In proxy creation/editing, select multiple policies:
    • Your custom policy: acme-corp-security
    • Default policy: llm-critical-security
    • Data protection: llm-data-redaction
  2. All selected policies are applied to the proxy
  3. Policies work together for defense-in-depth

Managing Custom Policies ​

View Your Policies ​

  1. Navigate to MCP Security or LLM Security page
  2. Your custom policies appear in the policy list
  3. Look for policies with your custom names

Edit a Custom Policy ​

  1. Navigate to MCP Security or LLM Security page
  2. Find your custom policy card
  3. Click Edit button
  4. Policy Builder opens with current settings
  5. Make your changes
  6. Click Validate, then Save Policy

Delete a Custom Policy ​

  1. Navigate to MCP Security or LLM Security page
  2. Find your custom policy card
  3. Click Delete button
  4. Confirm deletion
  5. Policy is removed from all proxies using it

Enable/Disable a Policy ​

  1. Find your policy card
  2. Use the Enable/Disable toggle
  3. Disabled policies remain configured but are not applied

Policy Best Practices ​

  1. Start with Templates: Use templates as starting points rather than building from scratch
  2. Use Pattern Library: Leverage pre-built patterns for common detections (PII, toxicity, injection)
  3. Test Thoroughly: Always test policies in the Policy Testing tab before deployment
  4. Start with Monitoring: Set initial policies to "monitor" or "log" actions, then gradually enable blocking
  5. Version Your Policies: Use the version field to track policy changes over time
  6. Document Patterns: Use descriptive rule names and detailed reasons for each pattern
  7. Review Regularly: Check policy performance in the Performance tab and adjust as needed
  8. Combine Wisely: Use 2-4 complementary policies per proxy for balanced protection

Understanding Pattern Actions ​

Blocked Patterns (Immediate Rejection) ​

Use for:

  • Malicious patterns (SQL injection, command injection)
  • Known attack signatures
  • Patterns that indicate active threats

Result:

  • Request is immediately rejected
  • Error returned to client
  • Alert created in system

Redact Patterns (Replace and Allow) ​

Use for:

  • Sensitive data that needs logging but should be masked
  • PII that must be redacted for compliance
  • Secrets that shouldn't appear in logs

Result:

  • Pattern is replaced with redact string
  • Request continues with redacted content
  • Original content recorded in secure logs (if enabled)

Redact with Unmasking (Mask from Provider, Show to User) ​

Use for:

  • Protecting user data from LLM providers
  • Maintaining user experience while ensuring privacy
  • Compliance with data minimization requirements

Result:

  • Pattern masked with placeholder before LLM provider
  • LLM processes masked content
  • Response automatically unmasked before returning to user
  • User sees original data, LLM provider does not

Troubleshooting ​

Policy Not Appearing in List ​

Check:

  • Policy was saved successfully (check for success notification)
  • Policy type matches page (MCP policies on MCP page, LLM on LLM page)
  • Refresh the page to reload policy list

Patterns Not Matching ​

Check:

  • Use Policy Testing tab to test patterns individually
  • Verify regex syntax using the Validate button
  • Ensure patterns are properly escaped (use raw strings)
  • Test with actual sample data that should match

Policy Validation Errors ​

Common issues:

  • Invalid regex: Test patterns with an online regex tester
  • Missing required fields: Ensure Policy Name and Type are filled
  • Duplicate Rule IDs: Each rule must have a unique ID

Policy Performance Issues ​

Solutions:

  • Avoid overly complex regex patterns
  • Use specific patterns instead of broad catch-alls
  • Check Performance tab for slow patterns
  • Consider splitting large policies into multiple focused policies

Need Help? ​

  • Policy Overview: See Policy Overview Guide to understand default policies
  • Pattern Library: Navigate to Policies → Pattern Library tab for pre-built patterns
  • Templates: Navigate to Policies → Templates tab for policy templates
  • Testing: Use Policies → Policy Testing tab to validate before deployment
  • Performance: Check Policies → Performance tab for optimization insights

Summary: Creating Custom Policies ​

The AI Security Gateway provides three flexible ways to create custom policies:

  1. Templates - Start with pre-configured policies and customize for your needs
  2. Pattern Library - Add proven detection patterns to new or existing policies
  3. Policy Builder - Build completely custom policies from scratch

All policy management is done through the intuitive web interface - no file editing or command-line tools required.

Key Features:

  • Visual Policy Builder with validation and testing
  • Pre-built Pattern Library for PII, Toxicity, and Injection detection
  • Redaction with Unmasking to protect data from LLM providers while maintaining user experience
  • Real-time Testing to validate policies before deployment
  • Flexible Deployment to apply policies to multiple proxies

Security policies should be tailored to your specific organizational needs and threat model. Use the tools provided to create, test, and deploy policies that protect your unique environment.