Skip to main content

Unified Access

Unified Access provides Keeptrusts-managed credentials, billing, and rate limiting for supported model traffic. Chat Completions and Responses also run the gateway policy path. The Anthropic-shaped Messages route is recognized, but its current governance and upstream-adapter limitations make it unsuitable for production traffic.

How it works​

  1. Model catalog — Browse available models with published per-token pricing.
  2. Access policies — Define and simulate intended model-access rules; the current live model path does not yet load these policy records.
  3. Budget policies — Define and simulate hourly, daily, weekly, and monthly limits; live reservation enforcement is not yet wired.
  4. Auto top-up — Store wallet refill settings and history; the runtime does not currently initiate the first automatic top-up attempt.
  5. Zero Data Retention — Enable passthrough or strict controls for sensitive workloads.

Billing​

  • Provider list prices with 0% markup on supported Unified Access models.
  • Team seats include monthly credits that are consumed before the shared org wallet.
  • Service users are billed from wallet funds only.
  • Usage is traffic metered per request and settled from actual token usage.

Endpoint status​

EndpointProvider/formatCurrent boundary
POST /v1/chat/completionsOpenAI / Chat CompletionsManaged billing and the Chat/Responses policy path
POST /v1/responsesOpenAI / Responses APIManaged billing and the Chat/Responses policy path
POST /v1/messagesAnthropic / Messages APIAuth, billing, and provider routing only; no Chat/Responses policy evaluation. The current Anthropic adapter also emits a non-conforming request body, so do not use this route for production traffic.

See Runtime Request Families and the Anthropic integration status before choosing a transport.

Managed public endpoints​

Unified Access credentials work across direct connected-gateway URLs and Keeptrusts-managed public endpoints. The hostname you choose changes locality and publication routing, not the auth model.

Published traffic familyBehavior
*.ai.global.keeptrusts.comGlobal entrypoint that selects an eligible published region after organization policy and region rules are resolved
*.ai.eu.keeptrusts.comEU locality commitment
*.ai.us.keeptrusts.comUS locality commitment

The wildcard label is an API-assigned, immutable 12-character lowercase alphanumeric publication key, for example abc123def456.ai.eu.keeptrusts.com. Do not substitute an organization or agent slug. Publish the endpoint through Keeptrusts and use the exact hostname the publication returns.

Root hosts at keeptrusts.com, eu.keeptrusts.com, and us.keeptrusts.com are discovery-only status surfaces. They are not soft latency hints and they do not serve customer model traffic. The published traffic hostnames are the locality commitments, and they only serve traffic after the organization publishes that hostname from an eligible connected gateway.

Use Configurations for rollout workflow, validation, and publication-state checks.

Programmatic authentication​

Use a scoped governed API token for Unified Access model requests. Create the token from API Tokens, copy the one-time value through an approved secret channel, and send it as an Authorization: Bearer ... credential. Keep provider keys and browser-session credentials out of client applications.

See Managing API Tokens for token profiles, bindings, rotation, and revocation.

Access policies​

Access-policy APIs let you define and simulate who should use which models:

  • Allow and deny rules support tag-based resource matching.
  • Deny always overrides allow.
  • When multiple allow rules match, the most restrictive limits win.
  • Use simulation to confirm the effective decision represented by the stored policy.

The current gateway, Unified Access, and wallet request paths do not load the access_policies records, so these definitions do not yet gate live model traffic. Enforce production access with the active token, role, gateway, and declarative-policy controls until that integration is wired.

Budget policies​

Budget-policy APIs define and simulate spend limits across time windows:

  • Hourly, daily, weekly, and monthly windows.
  • Effective-policy evaluation chooses the most restrictive matching limit.
  • The current wallet reservation path does not invoke that enforcement function, so exhausted policy windows do not currently block live traffic or produce a budget-policy 429. Wallet insufficiency remains the active hard stop.

See Unified Access budgets for policy design guidance.

Zero Data Retention (ZDR)​

For sensitive workloads:

  • passthrough sets store=false upstream and skips cache use.
  • strict also strips request and response bodies from event logs.

Next steps​