Skip to main content

​
What are Policies?

Policies are collections of Guardrails with specific configurations that define what should be protected and how. Instead of configuring individual guardrails for each application, you create policies that bundle related protections together and apply them consistently across projects. A policy specifies:
  • Which Guardrails to activate
  • How strictly to enforce them (BLOCK or WARN)
  • Custom detection thresholds and patterns
  • Placeholder text for redactions
  • Scope and applicability rules

​
Why Use Policies?

​
Consistency

Apply the same security rules across multiple projects without duplicating configuration. When you update a policy, all projects using it inherit the changes.

​
Flexibility

Create different policies for different scenarios:
  • Strict enforcement for production customer-facing APIs
  • Moderate protection for internal tools
  • Permissive settings for development environments

​
Compliance

Build policies that meet specific regulatory requirements (HIPAA, PCI, GDPR) and apply them to relevant projects automatically.

​
Maintainability

Manage security rules in one place instead of updating each project individually. Easier to audit, test, and improve over time.

​
Policy Structure

A policy contains: Guardrail Configurations: Which protections to enable 
{
  "guardrails": [
    "prompt-injection-defense",
    "data-leakage-prevention",
    "content-moderation"
  ]
}
Enforcement Levels: How to respond to violations 
{
  "enforcement": {
    "prompt-injection": "BLOCK",
    "data-leakage": "BLOCK",
    "content-moderation": "WARN"
  }
}
Custom Settings: Tune detection for your needs 
{
  "settings": {
    "pii-detection-sensitivity": "high",
    "custom-patterns": ["EMP\\d{6}", "CUST-[A-Z0-9]{8}"],
    "allowed-domains": ["company.com", "partner.com"]
  }
}

​
Common Policy Types

​
Production Policy

Strict protection for customer-facing applications:
  • All guardrails enabled
  • BLOCK enforcement for critical threats
  • High sensitivity detection
  • Comprehensive logging
  • Real-time alerting
Use for: Public APIs, customer portals, production services

​
Internal Tools Policy

Moderate protection for employee-facing applications:
  • Core guardrails enabled
  • WARN enforcement for most violations
  • Medium sensitivity detection
  • Standard logging
  • Periodic review
Use for: Admin panels, internal dashboards, employee tools

​
Development Policy

Permissive settings for testing and development:
  • Basic guardrails enabled
  • WARN enforcement with logging
  • Low sensitivity detection
  • Detailed logging for debugging
  • No alerting
Use for: Dev environments, staging, testing

​
Compliance Policies

Industry-specific protection: HIPAA Policy:
  • PHI detection and redaction
  • Medical content moderation
  • Strict audit logging
  • BLOCK enforcement
PCI Policy:
  • Payment card data detection
  • Financial information protection
  • Transaction logging
  • BLOCK enforcement
GDPR Policy:
  • EU personal data protection
  • Right to deletion support
  • Consent tracking
  • Data minimization

​
Policy Inheritance

Policies can inherit from base policies: 
Base Policy (Organization Standards)
  ├── Production Policy (+ Strict Enforcement)
  ├── Internal Policy (+ Moderate Enforcement)
  └── Development Policy (+ Permissive Enforcement)
Changes to the base policy automatically propagate to all derived policies, while allowing each to add specific rules.

​
Real-World Example

A healthcare company creates three policies: Patient Portal Policy (Production): 
{
  "name": "Patient Portal Policy",
  "base": "hipaa-compliance",
  "guardrails": ["all"],
  "enforcement": "BLOCK",
  "settings": {
    "phi-detection": "strict",
    "medical-content-moderation": "enabled",
    "audit-logging": "comprehensive"
  }
}
Internal EHR Policy (Internal): 
{
  "name": "Internal EHR Policy",
  "base": "hipaa-compliance",
  "guardrails": ["data-leakage", "prompt-injection"],
  "enforcement": "WARN",
  "settings": {
    "phi-detection": "moderate",
    "audit-logging": "standard"
  }
}
Development Policy (Testing): 
{
  "name": "Development Policy",
  "base": "hipaa-compliance",
  "guardrails": ["data-leakage"],
  "enforcement": "WARN",
  "settings": {
    "phi-detection": "low",
    "audit-logging": "detailed"
  }
}
All three inherit HIPAA compliance requirements but enforce them differently based on their use case.

​
Policy Assignment

Policies are assigned to projects: 
Project: Customer Service API
Policy: Production Policy
Result: Strict protection with BLOCK enforcement

Project: Admin Dashboard  
Policy: Internal Tools Policy
Result: Moderate protection with WARN enforcement

Project: Dev Environment
Policy: Development Policy
Result: Permissive protection with WARN enforcement
When a request arrives, the project loads its policy and applies the configured guardrails.

​
Best Practices

  1. Start with templates: Use pre-built compliance policies as starting points
  2. Test before deploying: Validate policies in staging before production
  3. Monitor false positives: Track blocked legitimate requests
  4. Version policies: Keep history of policy changes
  5. Document decisions: Explain why specific rules are configured
  6. Regular reviews: Audit policy effectiveness quarterly
  7. Gradual enforcement: Start with WARN in development, move to BLOCK in production after tuning