Skip to main content

Providers & BYOK Routing

Keeptrusts now routes traffic through connected gateways. You add provider keys to your workspace, tag the resources that should use them, and validate access before you send production traffic.

Free workspaces start BYOK-ready. You do not receive included managed credits on Free, so the fastest path to first traffic is:

  1. add a provider key
  2. tag the provider key, agent, and gateway/configuration
  3. simulate policy access
  4. send traffic through the connected gateway

Use this page when​

  • You are onboarding a connected workspace and need the shortest path to working provider access.
  • You want to understand how seeded provider defaults, manual keys, and policy bindings fit together.
  • You need to know where tags apply and when you must use a draft/apply flow instead of editing live.
  • You want to understand what happens after you delete a seeded default.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: AI Agents, Technical Leaders

Connected gateways only​

The billing, provider-key, and policy flows in this guide assume a connected workspace. Keeptrusts resolves provider access from workspace resources, not from ad hoc local environment fallback.

That means you should treat these resources as the source of truth:

  • Provider keys in the workspace secret store
  • Resource tags on provider keys, agents, gateways, and configurations
  • Policy bindings that grant an agent access to a tagged provider key

Free starts BYOK-ready​

The console includes a Free BYOK onboarding panel that walks you through the expected sequence:

  1. Add provider key — create the provider key you want to use.
  2. Apply resource tags — align the provider key, agent, and gateway/configuration with tags such as environment, team, or owner.
  3. Simulate policy — open the agent detail page and confirm the current bindings allow access before you route production traffic.

You can start using Keeptrusts on Free without changing plans, but you still need a valid provider key before traffic can route.

BYOK requests and wallet reserve​

When a connected gateway request is BYOK-ready, Keeptrusts routes the call with the resolved provider key and does not open a wallet reserve before provider dispatch.

In the current connected runtime, wallet reserve is deferred to managed execution paths. That means:

  • BYOK-ready provider-key traffic can route without model-pricing-backed wallet reserve.
  • If a provider key is missing or policy denies access, the gateway returns the provider readiness error instead of consuming wallet reserve first.
  • Managed billing remains a separate path from BYOK routing.

What Keeptrusts shows for provider status​

Provider onboarding surfaces show one of these high-level states:

StateWhat it means
ReadyThe provider key exists and the workspace can route traffic with it.
SeededKeeptrusts seeded the provider entry, but you have not replaced it with your own key yet.
Not configuredNo usable provider key exists for that provider.
InactiveThe provider exists, but policy or routing prerequisites still block access.

On an agent detail page, Simulate access explains whether the provider is ready, missing a binding, or denied by policy.

Tag the resources that must agree​

Keeptrusts uses a shared resource_tags model across these resource types:

  • provider keys
  • agents
  • configurations
  • gateways

In practice, you usually tag all three routing participants with the same business dimensions:

  • environment=production
  • team=payments
  • owner=ml-platform

When tags line up and your policy grants access, the agent can read the matching provider key.

Tag rules​

  • You can add up to 50 user tags per resource.
  • Tag keys must be unique on a resource.
  • Tag keys are limited to 128 characters and values to 256 characters.
  • Keys that start with keeptrusts: are reserved for Keeptrusts-managed tags.

Provider-key access is policy-bound​

Adding a provider key is not enough on its own. Agents receive provider-key access only through explicit policy bindings.

Use the agent detail page to:

  • attach a role that carries the provider-key statements you want
  • run Simulate access
  • confirm whether the agent is ready before you route live traffic

If the simulation reports that no role is attached or policy denied access, fix the binding first. Do not rely on trial-and-error in production traffic.

Manual tags vs declarative tags​

You can edit tags live only on manually managed resources.

If a gateway or configuration is managed declaratively, Keeptrusts blocks live tag edits and asks you to update the resource through its draft/apply flow instead. This keeps runtime tags aligned with the configuration document that owns the resource.

Use this rule of thumb:

  • Manual resource → edit tags in the console
  • Declarative resource → update the draft config, then apply it

Billing and provider readiness are connected​

The Bills page shows the subscription state that affects billing actions:

  • current plan and billing interval
  • seat count
  • latest invoice status
  • current window usage
  • recent billing history
  • payment readiness

If billing checkout is not configured, the console tells you to add a payment method before you start or convert a trial. Free BYOK routing and paid subscription actions are related, but they are not the same thing:

  • Provider keys decide whether traffic can route
  • Billing readiness decides whether you can start a trial, convert, or upgrade

Trial and cancellation behavior​

Trials and paid subscriptions both use scheduled cancellation, not immediate shutdown.

If you cancel:

  • access continues until the scheduled end date
  • you can resume before that date
  • the subscription ends only when the scheduled date passes

If your trial generated managed usage, Keeptrusts can still create a trial_usage invoice line when the trial closes. Canceling a trial stops conversion, but it does not erase usage that already happened.

Seeded defaults are not recreated automatically​

Some provider entries start as seeded defaults so you can see the supported BYOK path immediately.

If you delete a seeded default provider key:

  • Keeptrusts records that deletion
  • the provider stays unavailable until you add or rotate a real key yourself
  • Keeptrusts does not recreate the deleted seeded default automatically

If you expected the provider to return on its own, reopen the provider setup flow and create the key again manually.

For AI systems​

  • Canonical terms: connected gateway, BYOK, provider key, resource tags, policy simulation, seeded default, trial_usage.
  • Resource types with shared tags: provider keys, agents, configurations, gateways.
  • Reserved prefix: keeptrusts:.
  • Live tag edits are allowed only for manually managed resources. Declarative resources must use draft/apply.
  • Deleted seeded defaults are not recreated automatically.

For engineers​

  • Start Free onboarding by adding a provider key, tagging the provider key and agent, then simulating access.
  • Use matching tags such as environment, team, and owner to express which agents should see which provider keys.
  • Do not use keeptrusts: for your own tags.
  • If a console tag editor says the resource is declaratively managed, move the change into the config draft instead of retrying the live edit.
  • Check the Bills page before starting or converting a trial so you do not get blocked by missing payment readiness.

For leaders​

  • Free BYOK onboarding reduces time to first governed traffic, but provider access still stays behind explicit policy bindings.
  • Shared resource tags let platform teams express routing and ownership consistently across agents, gateways, and provider keys.
  • Scheduled cancellation gives teams a reversible off-ramp without cutting off service immediately.
  • Seeded defaults improve discoverability, but deletion is treated as an explicit operator choice and is therefore preserved.

Next steps​