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:
data_policy:
zero_data_retention: true
training_opt_out: true
retention_days: 0Record 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:
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: trueThe 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:
| Value | Result |
|---|---|
block | The gateway returns HTTP 403 with error code no_compliant_provider and does not call a provider. |
warn | The 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 --jsonLint 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:
-
Start the gateway with the validated configuration.
-
Send an authenticated request. It must complete, and the selected target must have a matching
data_policyblock. -
In a local copy of the configuration, set
retention_days: 30on 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.
-
In a test environment where no target is eligible, send a request. It must return HTTP
403with error codeno_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
| Problem | Cause | Action |
|---|---|---|
| Lint reports that all providers would be excluded | A 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_provider | No 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 target | warn only observes. | Set on_no_compliant_provider: block. |
A target with zero_data_retention: true is excluded | The 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 terms | Your declaration is wrong. | Correct the declaration and the approval record. The gateway cannot check provider compliance. |
Next steps
- Data Routing Policy: every rule field,
data_policyfield, default, and reason code. - Provider Configuration: the provider targets that carry
data_policy.