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 need to choose which policy controls to include in your chain for a specific domain (healthcare, finance, defense, etc.).
• You want to understand what each control does and which phase it operates in.
• You are planning a rollout and need to verify which controls are relevant before authoring policy-config.yaml.

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: Technical Engineers
• Secondary: AI Agents, 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

Targeting — restrict controls to specific teams or gateways

Any chain entry can include a targeting block to limit where it applies at runtime.

policies:
  chain:
    - prompt-injection
    -
      hipaa-phi-detector:
        targeting:
          scope: team
          teams: [healthcare, compliance]
          gateways: prod-gw
    -
      pii-detector:
        targeting:
          gateways:
            regex: "prod-.*"

• scope: organization (default) — the entry applies to all traffic.
• scope: team — the entry is evaluated only when the request's team context matches one of the listed teams.
• gateways — a single name, list of names, or { regex: "..." } to restrict the entry to specific gateway instances. Omit to apply to all gateways.
• Entries without targeting default to organization-wide, all-gateway applicability.

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, policy chain, input-phase control, output-phase control, data-routing-policy, prompt-injection, pii-detector, hipaa-phi-detector, agent-firewall, quality-scorer, human-oversight, citation-verifier.
• Feature and config names: policies.chain, policy.<kind>, targeting, scope, data_policy, action: redact, action: block.
• Commands: kt policy lint --file policy-config.yaml, kt policy test --json.
• Best next pages: Declarative Config Reference, Zero Retention Endpoints, Quickstart.

For engineers

• Validate your policy chain with kt policy lint --file policy-config.yaml after adding any control from this catalog.
• Each control name in the catalog corresponds to a policy.<kind> block in your YAML — use Declarative Config Reference for exact field schemas.
• Input-phase controls run before the upstream call; output-phase controls run after. Order in policies.chain determines execution sequence.
• Use targeting blocks to scope controls to specific teams or gateways without duplicating config files.

For leaders

• Use this catalog to map your regulatory requirements (HIPAA, GDPR, CJIS, ITAR, EU AI Act) to specific enforceable controls before rollout.
• Controls like human-oversight and quality-scorer provide verifiable evidence that governance requirements are met in production.
• The catalog covers both blocking controls (immediate enforcement) and monitoring controls (audit-logger, bias-monitor) — choose based on your risk tolerance and rollout maturity.
• Targeting by team or gateway lets you enforce stricter controls on sensitive workloads without affecting the entire organization.

Next steps

• Declarative Config Reference — field-level schema for every policy kind
• Quickstart — author, lint, and run your first policy config
• Zero Retention Endpoints — data-routing-policy enforcement with ZDR providers
• Roll Out a New Template — use an industry template to bootstrap your chain
• Managing Policy Changes — safe rollout workflows for production policy updates