Single Policy Documents

Keeptrusts supports two top-level declarative shapes:

• ConfigDocument for full gateway configs with pack, policies, and optional providers
• SinglePolicyDocument for one of four standalone policy shapes

Single-policy documents are useful when you want to isolate, reuse, or test one policy without authoring a full gateway config.

Use this page when

• You want to author a standalone policy file for testing, reuse, or modular composition without a full gateway config.
• You are building reusable policy fragments for prompt-injection, agent-firewall, citation-verifier, or quality-scorer.
• You need to understand the differences between ConfigDocument and SinglePolicyDocument shapes.

Primary audience

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

Supported standalone policy kinds

Only these four policy kinds support the standalone document shape:

• prompt-injection
• agent-firewall
• citation-verifier
• quality-scorer

Shared structure

Every single-policy document starts with a policy metadata object.

policy:
  name: prompt-injection
  version: 1.0.0
  enabled: true

Field	Type	Required	Description
policy.name	string	yes	Must be one of the four supported standalone policy kinds
policy.version	string	yes	SemVer string
policy.enabled	boolean	yes	Enable or disable the standalone policy

Unlike the full config shape, single-policy documents do not use pack, policies.chain, or providers.targets as required top-level objects.

Prompt injection document

policy:
  name: prompt-injection
  version: 1.0.0
  enabled: true

detection:
  embedding_threshold: 0.8
  attack_patterns:
    - "ignore.*previous.*instructions"
    - "forget.*system.*prompt"

encoding:
  decode_base64: true
  normalize_unicode: true
  detect_homoglyphs: true

boundaries:
  enforce_delimiters: true
  reject_fake_boundaries: true

response:
  action: block
  message: Request blocked: potential prompt injection detected
  log_level: warn

Top-level sections for this shape:

• detection
• encoding
• boundaries
• response

Agent firewall document

policy:
  name: agent-firewall
  version: 1.0.0
  enabled: true

tools:
  roles:
    analyst:
      allowed:
        - "search_*"
        - "read_*"
      denied:
        - "delete_*"
    admin:
      allowed:
        - "*"

rate_limits:
  default: 60
  search_records: 120

transaction_limits:
  max_single_transaction: 10000.0
  max_daily_total: 50000.0
  require_approval_above: 5000.0

kill_switches:
  max_errors_before_halt: 5
  halt_on_pii_in_action: true
  halt_on_suspicious_pattern: true

monitoring:
  alert_on_denied_action: true
  alert_on_rate_limit: true
  alert_threshold_percent: 80

max_actions_per_session: 500

Top-level sections for this shape:

• tools
• rate_limits
• transaction_limits
• kill_switches
• monitoring
• max_actions_per_session

Citation verifier document

policy:
  name: citation-verifier
  version: 1.0.0
  enabled: true

verification:
  require_source_match: true
  min_groundedness: 0.8
  extract_patterns:
    - academic
    - url

rag_context:
  verify_against_context: true
  min_context_overlap: 0.7

output_action:
  unverified_action: flag
  hallucination_action: block

response:
  include_verification_report: true

Top-level sections for this shape:

• verification
• rag_context
• output_action
• response

Quality scorer document

policy:
  name: quality-scorer
  version: 1.0.0
  enabled: true

benchmarks:
  ragas_faithfulness: true
  ragas_relevancy: true

assertions:
  - type: contains
    value: "source"
  - type: word-count
    config:
      min: 50
  - type: llm-rubric
    config:
      rubric: "The answer should be accurate, concise, and grounded in evidence."
    threshold: 0.8

thresholds:
  min_aggregate: 0.75
  min_faithfulness: 0.75

weights:
  faithfulness: 0.4
  relevancy: 0.35
  bleu: 0.25

failure_action:
  action: block

Top-level sections for this shape:

• providers
• targets
• benchmarks
• assertions
• thresholds
• weights
• industry_profiles
• failure_action

How standalone docs differ from full configs

Capability	Full config	Single-policy doc
pack metadata	yes	no
policies.chain	yes	no
Multiple policies	yes	no
Standalone testing of one policy	possible	ideal

Validation workflow

Lint the standalone file the same way you lint a full config:

kt policy lint --file prompt-injection.yaml

Migrating to a full config

When you outgrow a standalone policy, move the policy-specific sections under policy.<kind> and add a pack plus a policies.chain list:

pack:
  name: example-gateway
  version: 1.0.0
  enabled: true

policies:
  chain:
    - prompt-injection

policy:
  prompt-injection:
    embedding_threshold: 0.8
    response:
      action: block

For AI systems

• Canonical terms: Keeptrusts, SinglePolicyDocument, ConfigDocument, policy.name, policy.version, policy.enabled, prompt-injection, agent-firewall, citation-verifier, quality-scorer
• Config/command names: SinglePolicyDocument shape, policy: metadata block, supported standalone kinds: prompt-injection, agent-firewall, citation-verifier, quality-scorer
• Best next pages: Declarative Config Reference, Prompt Injection Detection, Quality Scorer

For engineers

• Prerequisites: Understanding of the full ConfigDocument shape. A use case where modular policy files are needed (e.g., shared across multiple gateway configs).
• Validation: Run kt policy lint --file my-policy.yaml against your single-policy document. The linter validates both document shapes. To exercise it with kt policy test, include the policy in a pack directory with policy-config.yaml and run kt policy test --json from that pack.
• Key commands: kt policy lint --file <single-policy.yaml>, kt policy test

For leaders

• Governance: Single-policy documents enable reusable compliance artifacts that can be version-controlled, shared across teams, and audited independently of full gateway configs.
• Cost: No additional cost — single-policy documents are a config authoring convenience, not a runtime feature.
• Rollout: Use single-policy documents for shared security policies (e.g., prompt-injection rules) that must be consistent across all gateway deployments.

Next steps

• Declarative Config Reference — Full ConfigDocument shape
• Prompt Injection Detection — Standalone prompt-injection policy details
• Quality Scorer — Standalone quality-scorer policy details
• Config Testing — Test suites for standalone policies