Allow & Deny Lists

Allow and Deny Lists let you override automatic detection decisions with explicit rules. Allow lists bypass detection for known-safe patterns; deny lists force blocking for known-bad patterns.

How They Work

flowchart LR
    A[Content] --> B{Allow List}
    B -->|Match| C[ALLOW]
    B -->|No Match| D{Deny List}
    D -->|Match| E[BLOCK]
    D -->|No Match| F[Detectors]

    style A fill:#1a1a2e,stroke:#00d4ff,color:#fff
    style B fill:#0d3d4d,stroke:#00d4ff,color:#fff
    style C fill:#1a4a1a,stroke:#44ff44,color:#fff
    style D fill:#0d3d4d,stroke:#00d4ff,color:#fff
    style E fill:#4a1a1a,stroke:#ff4444,color:#fff
    style F fill:#1a1a2e,stroke:#00d4ff,color:#fff

Allow list is checked first — matching content bypasses all detection
Deny list is checked second — matching content is always blocked
Detectors run on remaining content

Configuration

{
  "allow_list": {
    "entries": ["support@yourcompany.com", "sales@yourcompany.com"],
    "match_type": "exact"
  },
  "deny_list": {
    "entries": ["*.malicious-domain.com"],
    "match_type": "wildcard"
  }
}

Match Types

Exact Match

Matches the literal string:

{
  "allow_list": {
    "entries": [
      "support@yourcompany.com",
      "Contact customer service for help"
    ],
    "match_type": "exact"
  }
}

Content	Matches?
`support@yourcompany.com`	✅ Yes
`SUPPORT@YOURCOMPANY.COM`	❌ No (case sensitive)
`email: support@yourcompany.com`	❌ No (not exact)

Wildcard Match

Uses * as a wildcard:

{
  "allow_list": {
    "entries": [
      "*.yourcompany.com",
      "*@yourcompany.com"
    ],
    "match_type": "wildcard"
  }
}

Content	Matches?
`docs.yourcompany.com`	✅ Yes
`api.yourcompany.com`	✅ Yes
`john@yourcompany.com`	✅ Yes
`yourcompany.com`	❌ No

Regex Match

Full regex pattern support:

{
  "deny_list": {
    "entries": [
      "\\d{16}",
      "https?://[a-z]+\\.suspicious\\.com"
    ],
    "match_type": "regex"
  }
}

Allow List Examples

{
  "allow_list": {
    "entries": [
      "*@yourcompany.com",
      "*@yourcompany.io"
    ],
    "match_type": "wildcard"
  }
}

Prevents PII detection from blocking your company’s email addresses.

{
  "allow_list": {
    "entries": [
      "*.yourcompany.com",
      "github.com",
      "docs.python.org",
      "stackoverflow.com"
    ],
    "match_type": "wildcard"
  }
}

Prevents unknown link detection from flagging trusted domains.

{
  "allow_list": {
    "entries": [
      "4111111111111111",
      "test@example.com",
      "555-555-5555"
    ],
    "match_type": "exact"
  }
}

Allow known test/example data that would otherwise trigger PII detection.

Deny List Examples

{
  "deny_list": {
    "entries": [
      "*.competitor.com",
      "competitor.io"
    ],
    "match_type": "wildcard"
  }
}

Block mentions of competitor domains in LLM output.

{
  "deny_list": {
    "entries": [
      "badword1",
      "badword2"
    ],
    "match_type": "exact"
  }
}

Block specific words regardless of content moderation confidence.

{
  "deny_list": {
    "entries": [
      "PROJECT_CODENAME",
      "sk_live_[a-zA-Z0-9]+"
    ],
    "match_type": "regex"
  }
}

Always block mentions of internal project names or API keys.

Precedence Rules

Allow list takes precedence over deny list
- If content matches both, it’s allowed
- Design lists to be non-overlapping
Deny list takes precedence over detectors
- Deny-listed content is blocked even if detectors would allow it
Allow list bypasses detectors entirely
- Allow-listed content skips all detection

Use Cases

1. Known-Safe Company Data

Your company’s contact info shouldn’t trigger PII alerts:

{
  "allow_list": {
    "entries": [
      "support@company.com",
      "sales@company.com",
      "+1 (800) 555-0100"
    ],
    "match_type": "exact"
  }
}

2. Test Environment Patterns

Allow test data in development:

{
  "allow_list": {
    "entries": [
      "*@example.com",
      "4111111111111111",
      "000-00-0000"
    ],
    "match_type": "wildcard"
  }
}

3. Domain Allow List for Links

Only allow links to approved domains:

{
  "allow_list": {
    "entries": [
      "*.company.com",
      "docs.python.org",
      "github.com/*"
    ],
    "match_type": "wildcard"
  }
}

4. Blocking Specific Threats

Always block known attack patterns:

{
  "deny_list": {
    "entries": [
      "ignore all previous instructions",
      "you are now DAN",
      "jailbreak"
    ],
    "match_type": "exact"
  }
}

Full Policy Example

{
  "name": "Production Policy",
  "policy_mode": "IO",
  "allow_list": {
    "entries": [
      "*@yourcompany.com",
      "support@yourcompany.com",
      "+1 (800) 555-0100",
      "*.yourcompany.com"
    ],
    "match_type": "wildcard"
  },
  "deny_list": {
    "entries": [
      "*.malware-domain.com",
      "internal_secret_project",
      "sk_live_[a-zA-Z0-9]{24}"
    ],
    "match_type": "regex"
  },
  "input_detectors": [
    { "detector_type": "prompt_attack", "threshold": "L2", "action": "block" }
  ],
  "output_detectors": [
    { "detector_type": "pii/email", "threshold": "L2", "action": "block" },
    { "detector_type": "unknown_links", "threshold": "L3", "action": "flag" }
  ]
}

Best Practices

1. Keep Lists Minimal

Only add entries you’re confident about. Large lists can:

Be hard to maintain
Introduce security gaps
Slow down processing

2. Use Specific Patterns

// ❌ Too broad
{ "entries": ["*@*.com"], "match_type": "wildcard" }

// ✅ Specific
{ "entries": ["*@yourcompany.com"], "match_type": "wildcard" }

3. Document Why

Keep a record of why each entry was added:

Allow list entries:
- support@company.com - Company support email, OK to appear in output
- 4111111111111111 - Test credit card number for demos

4. Review Regularly

Audit your lists periodically:

Remove entries that are no longer needed
Check for entries that have become security risks
Update patterns as your data formats change

Next Steps

Custom Detectors — Regex-based detection rules
Input/Output Scope — Configure detection stages
Policies — Combine all configuration into policies