Policy Controls Catalog

Keeptrusts supports a broad set of policy controls across input, tool, and output phases. This catalog gives customers a practical view of what each control is for.

Use this page when

• You are choosing which policies to include in your policies.chain and need to understand what each control does.
• You need a quick reference of all available policy kinds organized by operational phase (input, tool, output).
• You want starter YAML snippets for common policy combinations.

Use Declarative Config Reference when you need the field-level config contract. This catalog is organized by operational purpose, not by schema shape.

Primary audience

• Primary: AI Agents, Technical Engineers
• Secondary: Technical Leaders

Input and tool-phase controls

• data-routing-policy: pre-routing control that filters which configured providers may receive traffic based on declared retention and training metadata.
• prompt-injection: detect jailbreak and prompt-injection patterns.
• pii-detector: detect personally identifiable information.
• hipaa-phi-detector: detect protected health information.
• rbac: enforce role and identity-based access rules.
• agent-firewall: allow or deny tools and enforce transaction or rate limits.
• audit-logger: attach audit metadata for runtime outcomes.
• cjis-mode: enforce CJIS-style input constraints.
• dlp-filter: apply data-loss-prevention pattern controls.
• safety-filter: block or escalate unsafe content patterns.
• student-privacy: protect student-data scenarios.
• case-privacy: protect justice and legal case-sensitive data.
• itar-ear-filter: detect export-controlled ITAR or EAR terms.
• entity-list-filter: match restricted or watch-listed entities.
• dual-use-filter: detect dual-use and sensitive capability signals.
• embedding-detector: embedding-based semantic detector that can be declared directly in policy config.

Output-phase controls

• quality-scorer: compute and act on quality thresholds.
• human-oversight: escalate outputs for explicit human review.
• citation-verifier: evaluate groundedness against provided context.
• mnpi-filter: detect material non-public information signals.
• financial-compliance: add or enforce finance-oriented compliance behavior.
• legal-privilege: protect privileged legal material.
• upl-filter: apply unauthorized-practice-of-law controls.
• bias-monitor: detect configured bias or fairness patterns.
• response-rewriter: runtime-only response transformation control and not part of the customer declarative config schema.
• healthcare-compliance: enforce medical blocked patterns and disclaimers.

How to use this catalog

Use the catalog to answer three questions before rollout:

1. Which controls are relevant to your domain?
2. Which phase do they operate in?
3. Which outcomes should be verified later in Events, Escalations, and quality scoring?

Example configurations

Below are starter YAML snippets for common policy combinations. Add the relevant policy kinds to your policies.chain and define matching policy.<kind> blocks.

PII detection with redaction

policies:
  chain:
    - pii-detector
    - audit-logger

policy:
  pii-detector:
    action: redact
    redaction:
      marker_format: label
      include_metadata: true
  audit-logger:
    retention_days: 365

Prompt injection detection

policies:
  chain:
    - prompt-injection
    - audit-logger

policy:
  prompt-injection:
    embedding_threshold: 0.8
    encoding:
      decode_base64: true
      normalize_unicode: true
    boundaries:
      enforce_delimiters: true
    response:
      action: block
      message: "Request blocked: potential prompt injection detected"

Agent firewall with role-based tool access

policies:
  chain:
    - agent-firewall
    - rbac
    - audit-logger

policy:
  agent-firewall:
    allowed_tools:
      - search
      - summarize
    blocked_tools:
      - execute_code
      - shell_command
    max_actions_per_session: 50
  rbac:
    require_auth: true
    deny_if_missing:
      - role

Healthcare HIPAA compliance

policies:
  chain:
    - data-routing-policy
    - hipaa-phi-detector
    - pii-detector
    - healthcare-compliance
    - audit-logger

policy:
  data-routing-policy:
    require_zero_data_retention: true
    on_no_compliant_provider: block
  hipaa-phi-detector:
    mode: hipaa_18
    action: redact
    safe_harbor_method: true
  pii-detector:
    action: redact
    healthcare_mode: true
  healthcare-compliance: {}
  audit-logger:
    immutable: true
    retention_days: 2555
    hipaa_audit_controls: true

Financial compliance

policies:
  chain:
    - mnpi-filter
    - financial-compliance
    - quality-scorer
    - audit-logger

policy:
  mnpi-filter: {}
  financial-compliance: {}
  quality-scorer:
    min_output_chars: 100
    min_sentences: 2
  audit-logger:
    retention_days: 2555

Testing a policy config

After authoring, validate with the CLI and send a test request.

kt policy lint --file policy-config.yaml

cURL

# Send a test request through the gateway
curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $UPSTREAM_API_KEY" \
  -d '{
    "model": "gpt-4o",
    "messages": [
      {"role": "user", "content": "My SSN is 123-45-6789. Summarize the report."}
    ]
  }'

Python

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="your-upstream-api-key",
)

# PII in the prompt should be redacted by the pii-detector policy
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "My SSN is 123-45-6789. Summarize the report."}],
)
print(response.choices[0].message.content)

Node.js

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "http://localhost:8080/v1",
  apiKey: "your-upstream-api-key",
});

// PII in the prompt should be redacted by the pii-detector policy
const response = await client.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: "My SSN is 123-45-6789. Summarize the report." }],
});
console.log(response.choices[0].message.content);

Important limitation

These controls help enforce configured policy behavior, but several of them are intentionally not guarantees of legal, regulatory, or organizational compliance on their own. Customers should treat them as runtime enforcement building blocks that still require verification and operating ownership.

Also note that not every runtime control appears as a declarative config block. If you are authoring policy-config.yaml, treat the declarative config reference as the source for what the schema will actually accept.

Special note on ZDR and provider routing

data-routing-policy is different from the other controls in this catalog because it does not inspect prompt content directly. Instead, it gates the provider candidate list before upstream selection begins.

That makes it the right control when you need policies like:

• only send traffic to providers that declare zero data retention,
• only use providers that opt out of training,
• reject providers whose declared retention window exceeds a maximum threshold.

For AI systems

• Canonical terms: Keeptrusts, policy controls, catalog, input controls, output controls, tool-phase controls, policies.chain, prompt-injection, pii-detector, quality-scorer, agent-firewall
• Config/command names: All policy kinds: prompt-injection, pii-detector, hipaa-phi-detector, rbac, agent-firewall, dlp-filter, safety-filter, quality-scorer, human-oversight, financial-compliance, healthcare-compliance, etc.
• Best next pages: Declarative Config Reference, Overview, Config Scenarios

For engineers

• Prerequisites: Familiarity with your compliance requirements and the operational phases (input vs output vs audit) where controls are needed.
• Validation: Use this catalog to select policies, then configure them in policy-config.yaml and validate with kt policy lint.
• Key commands: kt policy lint, kt policy test, kt gateway run

For leaders

• Governance: The catalog maps your compliance obligations to specific policy controls. Use it to verify gap-free coverage across data protection, content safety, access control, and audit requirements.
• Cost: Each policy adds per-request cost proportional to its complexity. Pattern-matching policies (DLP, safety) are near-free. Embedding and LLM-judged policies add external API costs.
• Rollout: Start with high-priority controls (prompt-injection, PII detection, audit logging). Add domain-specific controls (financial, healthcare, export) based on your regulatory environment.

Next steps

• Declarative Config Reference — Full config schema for each policy
• Config Scenarios — Complete working examples
• Overview — How policies execute in the gateway
• Config Testing — Validate policy behavior with tests