Skip to main content

v0.4.0

Released September 16, 2026. Supported until March 16, 2027.

v0.4.0 ships 7 behavior changes, 7 security updates, 10 new features, and 18 bug fixes. Two threads run through the release. Guardrail providers are now owned per project, and their credentials are handled as secrets: each project owns its own providers instead of sharing three platform-wide ones, a credential enters only through the new SetGuardrailProviderSecret operation, is stored encrypted, is returned by no read, and reaches the gateway as a mounted Kubernetes Secret instead of traveling inside the guardrail configuration. User accounts can now be managed over the management API: administrators can ban and unban a user, soft-delete and restore an account, and search the user directory the Admin Console reads. Budget policies also report live billable spend, per team member and across a customer. Behavior between the management plane and the data plane changed in this release. The most severe security issue cleared is high.

Upgrade and rollback​

  • No breaking changes. No operator action is required before upgrading.
  • The upgrade rolls through without dropping traffic.
  • Rollback to v0.3.0 is unconditional.

Behavior changes​

SDK​

The published Go, Python, and TypeScript SDKs now cover the customer API only. The packages the management plane and the data plane use to talk to each other (configurator, lookup, tokens) and two operator-only packages (registry, kms) are no longer generated into them, so the Configurator and Tokens client handles are gone from all three SDKs. No customer-facing service changes; code that reached those services through an SDK uses the platform's own generated bindings instead. The published packages are listed on the SDK reference.

Gateway​

Guardrail provider credentials are now delivered to the gateway as a mounted Kubernetes Secret instead of traveling inside the guardrail configuration, so a credential no longer appears in the tars-config ConfigMap, in the EnvoyPatchPolicy, or in the proxy's configuration dump. Upgrading to this release restarts the egress gateway pods once, when the credential volume is added to the proxy; afterwards, adding, rotating, or removing a credential takes effect on the running gateway with no restart and no traffic interruption. A rotation is picked up within a few minutes rather than immediately, since it deliberately changes no gateway configuration and travels with the gateway's periodic reconcile. Available once the data plane is on 0.4.0 or later.

Guardrails​

Guardrail providers in the configuration delivered to a data plane now carry the project that owns them, so a data plane serving several projects no longer receives one undifferentiated provider list.

Management plane API​

Listing budget policies now returns INVALID_ARGUMENT for a non-empty page.filter or an unsupported page.order_by, including multiple sort fields; these inputs were previously ignored. Before upgrading, callers leave page.filter empty and omit page.order_by or pass a single field (name, spend_limit, created_at, or updated_at, optionally followed by asc or desc). The name field is the policy name; user names and email addresses cannot be used for sorting.

Editing a guardrail rule that is bound to a provider outside its own project is now refused. The rule keeps enforcing and reading it is unaffected, but an update that touches its provider, check type, or configuration fails until the rule is repointed at a provider its own project owns, which can be done in the same update call. Only rules the guardrail-provider ownership migration reports as still bound outside their own project are affected; the migration names the count in its notice.

A guardrail provider's credential is no longer accepted in its configuration. Creating or updating a provider with an Azure AI Content Safety api_key, or an external service's auth_token, inside the configuration now fails with an error naming the new SetGuardrailProviderSecret operation, which is the only way a credential enters. The credential is stored encrypted, the provider keeps only a reference to it, and no read returns it: providers report whether one is stored, not what it is. Calling the operation again rotates the credential in place. Providers created before this release keep working and stay editable; their credential no longer appears in any API response, and editing such a provider preserves the credential rather than dropping it. Deleting a provider, or its project, destroys the credential with it.

Listing and reading guardrail providers now requires the guardrail_providers.read permission or a scope that grants guardrail reads, bringing provider reads into the same permission domain as the writes. Management API keys carrying the read, write, admin, guardrails_reader, or guardrails_admin scope keep their access with no action needed, as do the Super Admin and Viewer roles and every console session. A key scoped only to an unrelated area, and any custom role granting neither the permission nor a guardrail read scope, now receives a permission error where a provider list or lookup previously succeeded; access is restored by adding guardrail_providers.read to the role or issuing the key with a scope that includes guardrail reads.

Security updates​

Gateway​

The gateway now includes the gRPC-Go fix for malformed requests missing both the :authority and Host headers.

Changing a provider's authentication type now revokes the credential it used to hold. Previously the stored key and the policies that inject it both survived the change, so a provider moved off an API key kept authenticating gateway traffic with it indefinitely, with nothing in the Console to show it was still live. The credential is removed on the next configuration push; no action is needed beyond making the change.

The GKE Gateway charts can now attach a GCP SSL policy to the load balancers fronting the api, router, auth, dashboard, otel, proxy and registry endpoints, restricting them to TLS 1.2 or later and removing the 3DES (SWEET32) and static-RSA ciphers that GCP's default policy still permits.

Management plane API​

Claiming a hostname that is already in use no longer exposes details about the existing configuration.

A deleted user is now refused on the platform login path, and an existing session of a deleted or banned user stops working on its next use.

A guardrail rule can now be bound only to a provider its own project owns; the binding check previously asked only whether the provider existed and was usable, never who owned it, so a caller who knew another project's provider id could send that project's traffic through another project's provider and credential. The refusal reads the same whether the id names another project's provider, a catalog template, or nothing at all. Rules written before this release are not rewritten: any left bound outside their own project keep enforcing, and keep exporting the other project's provider configuration into the referencing project's data plane configuration, until each is repointed at a provider its own project owns. The guardrail-provider ownership migration reports how many such rules remain.

A management API key scoped to an unrelated area can no longer enumerate a project's guardrail providers.

New features​

Management plane API​

Budget policies can now report live billable spend and passthrough estimates, including per-member spend for teams and customer spend and near-limit, over-limit and unmeasured policy counts on list requests.

Administrators can ban and unban a user through the management API.

Platform operators can soft-delete and restore user accounts over the management API.

The management API now serves the user directory the Admin Console reads.

The API can now permanently remove an inactive budget policy without changing the existing deactivation behavior of DELETE.

Creating or updating a guardrail provider now fails with a clear message when the provider could never run: an Azure AI Content Safety provider must carry an endpoint that is an absolute http(s) URL, alongside the existing checks on provider kind and on an external service's declared checks.

Data plane​

An active route deployment whose AI Gateway routes have gone missing now says so, as a Warning condition on the RouteDeployment naming how many of the routes its last render created are no longer there, alongside a warning log.

Guardrails​

Each project now owns its own guardrail providers instead of sharing three platform-wide ones, so provider settings such as an endpoint can differ per project. The three shared rows become catalog templates, joined by a new Azure AI Content Safety template, and listing a project's providers returns only the project's own rows unless templates are asked for. Existing guardrail rules are moved onto their own project's provider of the same kind during the upgrade, so what each guardrail enforces is unchanged; a script that creates rules against one of the three fixed provider ids is refused and reads the project's own providers instead.

A newly created project arrives with its own regexp, builtin and Tetrate guardrail providers, so a guardrail can be written and enforced in it without setting a provider up first.

A guardrail created from a template now binds each of its rules to the project's own provider of the same kind, so it enforces as soon as it is enabled, with no further setup. In a project that does not yet own a provider of the kind the template needs, the clone is refused with an error naming that kind, rather than created with rules that can never run.

Bug fixes​

Management plane API​

A user whose ban has expired can sign in again, and an existing session of theirs keeps working.

Registering a data plane now returns after its durable workspace bootstrap instead of waiting for the full configuration replay across the customer's catalog.

Creating or rotating a routing key through the API saves the key and its client membership together.

CreateBudgetPolicy now accepts only the released TEAM, TEAM_PER_USER_DEFAULT, and API_KEY scopes.

A revoked admin API key or registry credential now stops authenticating within five minutes.

Release process​

Customer-facing version labels now show the promoted release version after a final Helm chart is deployed, instead of the prerelease build identifier used during internal validation.

Data plane​

A route deployment for an API key no longer becomes active while only part of its AI Gateway routes exist.

tare CLI​

Model lifecycle states, new, preview, deprecated and retired, are now derived from catalog metadata by a single shared policy, so every catalog surface reads the same verdict.

Catalog sync now warns when a model past its retirement date is still enabled on this management plane, and names the remedy, --apply disables the ones the published catalogue still lists, --disable-absent the ones it no longer lists at all.

tare doctor no longer tells an operator their CLI is too old to check upstream reachability.

Catalog sync​

The scheduled catalog sync can now run on a management plane using that plane's admin key.

Gateway​

Passthrough requests now stay with one provider: the highest-priority leg that accepts a caller's own key, plus that provider's other legs.

Anthropic requests sent through AWS Bedrock now normalize system-role messages before forwarding them, and return a useful HTTP-status error when Bedrock responds with an empty error body.

Requests with max_tokens no longer fail because their input cost is larger than the output-only estimate.

A model the gateway lists but cannot yet serve now returns model_not_available and says its catalog entry is still propagating, instead of model_not_found with a pointer to /v1/models, the endpoint that had just listed it. The catalog is also published earlier, so a model whose route is still being deployed answers 503 model_not_ready instead of being missing from /v1/models until the whole update lands. Available once the data plane is on 0.4.0 or later.

Consoles​

The Playground no longer reports "no gateway URL configured" on a project whose Base URL is configured; it now dials the same URL the API keys page shows.

An API key's settings page no longer fails when model-specific fallback is turned on or the Budget section is opened.

The fallback settings for an API key now name the one provider a passthrough request (one carrying the caller's own provider credential) uses, and say that steps on any other provider are skipped. A chain that spans providers is still accepted and still used in full by ordinary requests.