Skip to content
Glitch

Policies

A Policy is the central configuration object in Glitch. It defines which detectors run, at what sensitivity, and what action to take when threats are detected.

Why Policies?

Section titled “Why Policies?”

Instead of configuring security rules per-application, Glitch uses policies to create reusable, consistent security configurations:

  • One Policy, Many Projects — Create a “Strict Security” policy and apply it to all production projects
  • Separate Input/Output Rules — Different detectors for what goes into vs. comes out of the LLM
  • Per-Detector Tuning — Set different threshold levels for prompt injection vs. PII detection
  • Instant Updates — Change a policy; all linked projects update immediately

Policy Structure

Section titled “Policy Structure”

Every policy contains:

FieldDescription
nameHuman-readable policy name
policy_modeIO (both), I (input only), or O (output only)
input_detectorsList of detectors to run on LLM inputs
output_detectorsList of detectors to run on LLM outputs
allow_listPatterns to bypass detection
deny_listPatterns to always block
custom_detectorsUser-defined regex patterns
rate_limitsRate limiting and resource protection settings

Detector Configuration

Section titled “Detector Configuration”

Each detector in input_detectors or output_detectors specifies:

{
  "detector_type": "prompt_attack",
  "threshold": "L2",
  "action": "block"
}
FieldValues
detector_typeprompt_attack, jailbreak, pii/email, pii/credit_card, moderated_content/hate, etc.
thresholdL1 (confident) → L4 (sensitive) — see Threshold Levels
actionblock (reject request), log (allow but log), alert (send notification)

Rate Limits

Section titled “Rate Limits”

Policies include optional rate limiting and resource protection to defend against abuse and resource exhaustion attacks (OWASP LLM10). Rate limiting is opt-in and must be explicitly enabled via the rate_limits_enabled toggle in the dashboard or API.

Configuration Options

Section titled “Configuration Options”
FieldTypeDefaultDescription
requests_per_minuteinteger60Maximum requests per project per minute
tokens_per_minuteinteger100,000Maximum tokens per project per minute
max_input_tokensinteger8,192Maximum tokens per single request
max_output_tokensinteger4,096Maximum output tokens per response
max_input_charactersinteger64,000Maximum characters per request
burst_multiplierfloat2.0Allow temporary bursts (e.g., 2.0 = 2x normal rate)
cost_limit_per_day_centsinteger0Daily spending cap in cents (0 = disabled)

Example Configuration

Section titled “Example Configuration”
{
  "rate_limits": {
    "requests_per_minute": 100,
    "tokens_per_minute": 150000,
    "max_input_tokens": 16384,
    "max_output_tokens": 8192,
    "max_input_characters": 128000,
    "burst_multiplier": 2.0,
    "cost_limit_per_day_cents": 5000
  }
}

Response Headers

Section titled “Response Headers”

When rate limiting is enabled, Glitch returns informative headers on every response:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 95
X-RateLimit-Reset: 1699999999
X-TokenLimit-Limit: 150000
X-TokenLimit-Remaining: 142500
X-TokenLimit-Reset: 1699999999

Rate Limit Errors

Section titled “Rate Limit Errors”

When limits are exceeded, Glitch returns a 429 Too Many Requests response:

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "Request rate limit exceeded",
    "details": {
      "limit": 100,
      "window": "1m",
      "retry_after": 45
    }
  }
}

The Retry-After header indicates how many seconds to wait before retrying.

Input Validation

Section titled “Input Validation”

In addition to rate limiting, Glitch validates inputs to prevent resource exhaustion:

  • Token limits — Requests exceeding max_input_tokens are rejected with a 400 Bad Request
  • Character limits — Requests exceeding max_input_characters are rejected
  • Repetition detection — Suspicious patterns (e.g., AAAA... repeated thousands of times) are blocked to prevent token-flooding attacks

Example Policy

Section titled “Example Policy”
{
  "name": "Balanced Security",
  "policy_mode": "IO",
  "input_detectors": [
    { "detector_type": "prompt_attack", "threshold": "L2", "action": "block" },
    { "detector_type": "pii/email", "threshold": "L2", "action": "log" },
    { "detector_type": "pii/credit_card", "threshold": "L1", "action": "block" }
  ],
  "output_detectors": [
    { "detector_type": "pii/email", "threshold": "L2", "action": "block" },
    { "detector_type": "moderated_content/hate", "threshold": "L2", "action": "block" }
  ]
}

Projects

Section titled “Projects”

A Project represents a single application or use case using Glitch. Each project:

  • Has a unique API key for authentication
  • Is assigned to exactly one Policy
  • Falls back to the organization’s default policy if none is set
Organization
├── Policy: "Strict Security"
│   ├── Project: prod-chatbot (API key: glitch_xxx...)
│   └── Project: prod-assistant (API key: glitch_yyy...)
├── Policy: "Permissive"
│   └── Project: internal-tools (API key: glitch_zzz...)
└── Default Policy: "Balanced Security"

Managing Policies

Section titled “Managing Policies”

Create a Policy

Section titled “Create a Policy”
Terminal window
curl -X POST https://api.golabrat.ai/api/v1/policies/ \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "My Policy",
    "policy_mode": "IO",
    "input_detectors": [
      { "detector_type": "prompt_attack", "threshold": "L2", "action": "block" }
    ],
    "output_detectors": []
  }'

Assign Policy to Project

Section titled “Assign Policy to Project”
Terminal window
curl -X PATCH https://api.golabrat.ai/api/v1/projects/{project_id}/ \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "policy_id": "uuid-of-policy" }'

Set Organization Default

Section titled “Set Organization Default”
Terminal window
curl -X POST https://api.golabrat.ai/api/v1/policies/{policy_id}/set_default/ \
  -H "Authorization: Bearer YOUR_TOKEN"

Next Steps

Section titled “Next Steps”