Skip to main content

Security & Data

Zero-Retention Routing

When your organization approves specific provider accounts for zero-retention traffic, you can make the gateway send sensitive requests only to those accounts. You label each approved provider target, and a routing rule excludes every target without the right label. If no target qualifies, the gateway blocks the request instead of falling back.

The labels are your own statement about terms that you verified. zero_data_retention: true does not change how a provider stores data, and it does not create an agreement with the provider. Verdictan only compares your labels with your routing rule.

Before you start​

  • A policy pack with at least one provider target that passes lint. See Provider Configuration.
  • The provider terms or internal approval record for each guarantee that you declare.
  • A client API token for the test requests.

Declare provider handling metadata​

Add a data_policy block to each approved target. Declare only what the approved terms support:

Inside an approved providers.targets[] entry
data_policy:
  zero_data_retention: true
  training_opt_out: true
  retention_days: 0

Record the provider contract, account setting, region, and review date that support each value.

Enforce the routing rule​

Metadata alone filters nothing. Add data-routing-policy to the chain and state what each eligible target must declare:

policy-config.yaml
policies:
  chain:
    - data-routing-policy
    - audit-logger

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

The gateway checks the metadata of each target before routing and fallback. A target without the required metadata is not eligible. When no target is eligible, on_no_compliant_provider decides what happens:

ValueResult
blockThe gateway returns HTTP 403 with error code no_compliant_provider and does not call a provider.
warnThe gateway logs a warning and sends the request to its usual targets. Use this only to observe. It does not keep traffic in the declared boundary.

This rule controls routing. It is not a network firewall and it does not delete stored data. Other data_policy fields, such as in_memory_only and allow_internet_egress, are optional and must also match verified terms. Data Routing Policy lists every field and default.

Lint and test the pack​

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

Lint finds missing targets, missing data_policy blocks, declarations that contradict each other, and rules that exclude every target. policy test runs your cases, but the input-phase result of data-routing-policy is only a marker, because the gateway filters targets later, during provider selection. Neither command checks live routing or provider contracts.

Verify​

Test both paths:

  1. Start the gateway with the validated configuration.

  2. Send an authenticated request. It must complete, and the selected target must have a matching data_policy block.

  3. In a local copy of the configuration, set retention_days: 30 on the eligible target and lint the copy. Lint must fail:

    data-routing-policy: all providers would be excluded — requests will be blocked at runtime
    data-routing-policy: provider "openai-zdr" declares zero_data_retention but retention_days is 30 (must be 0)
    Error: policy lint failed (2 error(s))

    Do not deploy this copy.

  4. In a test environment where no target is eligible, send a request. It must return HTTP 403 with error code no_compliant_provider. Do not use an unknown model for this test, because that request can fail for a different reason.

With log_provider_selection: true, keep the data-routing-policy excluded provider log lines as evidence, together with the configuration version and the request IDs of both tests.

Verdictan can prove that the selected target has a matching data_policy block. It cannot prove that a provider obeys its terms. Review the provider guarantees again before you change models, regions, endpoints, or account terms.

Troubleshooting​

ProblemCauseAction
Lint reports that all providers would be excludedA rule field does not match the data_policy of any target.Compare each rule field with the target fields.
A request returns 403 with no_compliant_providerNo target meets every active rule.Correct the data_policy block of a target that must stay eligible.
A request succeeds in warn mode with no eligible targetwarn only observes.Set on_no_compliant_provider: block.
A target with zero_data_retention: true is excludedThe target has no retention_days, and the rule sets max_retention_days.Set retention_days on the target.
A selected target does not meet the provider termsYour declaration is wrong.Correct the declaration and the approval record. The gateway cannot check provider compliance.

Next steps​