Unified Access in Config
The current public gateway config does not use a standalone top-level
unified_access: section. Unified Access spans gateway routing and
control-plane resources, so put each setting in the surface that owns it.
Adding an unknown top-level key is not a harmless annotation: the declarative config uses strict validation and rejects unsupported keys.
What to use instead
Use the ordinary declarative-config surfaces that already govern provider access and routing:
providers.targets[]for provider definitions and credentialsdata_policyon provider targets for declared retention and handling guaranteespolicy.data-routing-policyfor routing constraints such as zero-retention, no-training, and local-only requirements- access policies, budgets, and scoped API-token management in the control plane for shared-provider workflows
Ownership map
| Need | Owning surface | What to verify |
|---|---|---|
| Define a gateway provider target | providers.targets[] | Provider kind, model, endpoint fields, and secret reference all match the selected adapter |
| Declare provider handling guarantees | providers.targets[].data_policy | The declaration matches the provider terms your organization accepted |
| Exclude targets that do not meet handling requirements | policy.data-routing-policy plus a chain entry | The required fields match target metadata and on_no_compliant_provider has the intended behavior |
| Authorize a client | Scoped API-token workflow | The client sends its own Bearer token rather than a gateway runtime token or provider key |
| Store or simulate access and budget intent | Unified Access control-plane APIs | Treat simulation as an intent check; the current live model path does not enforce stored access-policy or budget-policy records |
| Fund managed traffic | Wallet and Payments workflows | The active wallet balance can cover reservation; auto top-up is not currently an automatic rescue path |
data_policy is operator-declared metadata. Keeptrusts can apply routing rules
to that metadata, but it does not fetch or attest to a provider's legal terms
for you.
Validate each boundary
For gateway YAML:
kt policy lint --file policy-config.yaml
kt policy test --json
Linting proves that the document fits the current schema and catches several
contradictory routing declarations. Pack tests prove only the cases that the
pack actually defines; they do not contact a model provider or prove that a
client token is authorized. data-routing-policy performs its real filtering
at provider selection, so an input-phase pack test is not proof that target
selection behaves as intended.
For the live path, send an authenticated request through the intended endpoint and check the resulting response and applicable usage or request evidence. A successful access-policy or budget-policy simulation alone is not proof of live enforcement.
Common mistakes
- Adding
unified_access:topolicy-config.yaml. - Putting a provider credential in a client application.
- Treating
data_policyas a provider-issued attestation. - Assuming a stored access or budget policy already blocks live requests.
- Using
/healthzas proof that authorization, wallet reservation, and upstream model access all work.
Practical rule
If you are writing YAML, stay inside the normal config schema. If you are managing shared credentials, budgets, wallet funding, or API tokens, use the connected control-plane workflows documented in the Unified Access guides.