Skip to main content

Zero-Retention Routing

Use this page to configure and verify zero-retention requirements in Keeptrusts.

This page is deliberately not a provider catalog. Provider guarantees change over time, and Keeptrusts only enforces what you declare in config.

Prerequisites​

  • A valid policy pack with one or more explicit providers.targets[].
  • Current provider terms or an internal approval record that supports every handling guarantee you plan to declare.
  • A gateway verification plan that covers both a compliant-target path and a no-compliant-target path.

1. Declare provider handling metadata​

Add data_policy to each provider target that participates in sensitive routing. Replace the resource host, deployment name, API version, and model with values from the Azure deployment your organization has approved.

providers:
  targets:
    - id: azure-openai-zdr
      provider: azure-openai
      model: gpt-5.4-mini
      base_url: https://your-resource.openai.azure.com
      secret_key_ref:
        env: KEEPTRUSTS_AZURE_OPENAI_API_KEY
      azure_deployment: your-azure-deployment
      azure_api_version: your-supported-api-version
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        allow_internet_egress: false

2. Enforce the routing rule​

policies:
  chain:
    - data-routing-policy
    - audit-logger

policy:
  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    require_in_memory_only: true
    allow_internet_egress: false
    on_no_compliant_provider: block
    log_provider_selection: true

The selector evaluates target metadata before normal routing and fallback. A target without the required metadata does not satisfy that requirement.

When every target is excluded:

  • block returns HTTP 403 without sending the request upstream.
  • warn continues with the full target list.

warn is therefore an observation mode, not zero-retention enforcement. Do not use it for traffic that must stay inside the declared boundary.

3. Validate before rollout​

kt policy lint --file policy-config.yaml
kt policy test --json

Linting catches missing provider targets, missing data_policy blocks, several contradictory declarations, and configurations where all targets would be excluded. kt policy test runs the pack's declared policy cases, but the data-routing-policy input-phase result is only a marker: real target filtering happens at provider selection. Use a gateway request test for the eligible and no-eligible-target paths. Neither test validates a provider's contract.

After rollout, send an authenticated request through the intended request family. Confirm that the request succeeds only when an eligible target exists, and that the no-eligible-target case returns 403 in block mode. When log_provider_selection is enabled, use the gateway log diagnostics and any delivered request record as supporting evidence.

What Keeptrusts can prove​

Keeptrusts can prove that the gateway only routed to provider targets whose declared data_policy matched your requirements.

Keeptrusts cannot prove a vendor's legal or contractual promises on your behalf. Treat data_policy as an operator declaration that should match the provider terms you actually accepted.

  • Use data_policy on every provider target in a sensitive route.
  • Keep data-routing-policy in the active chain; metadata alone does not filter targets.
  • Use on_no_compliant_provider: block for enforced workloads.
  • Test both the eligible and no-eligible-target paths before rollout.
  • Re-review provider guarantees before changing models, regions, endpoints, or account terms.
  • Preserve the config version and request identifiers used for verification.
  • Record the provider contract, account setting, region, and review date that justify each declaration. A config value without that evidence is not a retention guarantee.

Troubleshooting​

SymptomCheck
Lint says every provider is excludedCompare each required policy field with the corresponding target data_policy value
Request returns 403Confirm at least one configured target satisfies every active routing requirement
Request succeeds in warn mode with no compliant targetsExpected observation behavior; change to block before treating the route as enforced
Selected target violates the intended provider termsCorrect the operator declaration and provider approval process; the gateway cannot verify vendor promises automatically

Next steps​