Audit trail for API Key operations. Creating, editing, and deleting an API Key now generates a record in the Access Control Audit Log, with the date, the author, the outcome, and the object's content — the record never includes the key's value. Refusals right at the entry point (invalid data) generate no record; failures while processing the operation — including when the object doesn't exist — do. Queries generate no record. See API Keys.
Audit trail for Certificates operations. Registering, editing, and deleting a certificate now generates a record in the Access Control Audit Log, with the date, the author, the outcome, and the object's content — the private key never appears in the record, regardless of the outcome. Refusals right at the entry point (invalid data, missing header) generate no record; failures while processing the operation — including deleting a certificate that is in use or a nonexistent id — do. Queries generate no record. See Custom Inbound.
Audit trail for Trust Stores operations. Registering, editing, and deleting a Trust CA now generates a record in the Access Control Audit Log, with the date, the author, the outcome, and the object's content — the CA material never appears in the record, regardless of the outcome. On success, the record usually carries the identifier, the name, and how many CA certificates that Trust CA's PEM holds — the content after the operation on registration and editing, and the content read before removal on deletion; the count refers only to that Trust CA, not to the Trust CAs selected on the host, and doesn't tell which certificates make up the chain. Refusals right at the entry point (a required field missing or blank, a missing header) generate no record; failures while processing the operation — including deleting a Trust CA that is in use, passing a nonexistent id, reusing a name that is already registered, or sending a PEM that is malformed or above the size limit — do. Queries generate no record. See Custom Inbound.
Granular permission-based access control. AI Gateway operations now require a specific permission in Access Control, as this control is rolled out progressively from the internal environments to production — access to the product used to be all-or-nothing. The product's 46 permissions — one per action on each resource (LLM Providers, Pricing, API Keys, Routes, Policies, MCP Servers, AI Agents, Scopes, General, Inbound Address, Certificates, and Trust Stores) — become available as the control reaches each environment, ready to compose custom roles in Access Control as soon as they appear — for example, a role that can only view the gateway's configuration without being able to change it. Pricing has permissions of its own, separate from those of LLM Providers: viewing prices, overwriting a model's price and removing it are distinct permissions, so someone can be given control over negotiated pricing without being given the technical configuration of the providers — and the other way round. The default Super Admin and Admin roles already ship with all of them, so anyone using one of those keeps every access they already had. The default Read-Only role becomes genuinely read-only: write actions it can currently perform — and viewing AI Agent credentials — will start returning 403 as the control is rolled out to each environment.
CUSTOM ROLES NEED THE NEW PERMISSIONSIf your tenant uses a custom role (other than Super Admin, Admin, or Read-Only) to access AI Gateway, that role loses access to the product's operations until an administrator grants it the corresponding permissions in Access Control's Roles screens.
global endpoint). Authentication uses the API Key registered for the provider, like the other providers. See the conditional fields by provider. A Vertex AI provider also takes part in Pricing: the models it serves show up in the unpriced-models alert and can be given custom pricing like those of the other native providers.Client secrets are no longer returned by configuration reads. The Sensedia Platform Client Secret (General screen) and the MCP server client secret (MCP Servers screen, Client credentials mode) are no longer returned by any read operation — the field now always opens blank on edit, with the text Leave blank to keep the current secret, and leaving it blank on save preserves the currently registered value. Before this fix, both secrets were returned in cleartext to any user authenticated in the tenant who queried these endpoints. See the updated behavior in General and MCP Servers.
RECOMMENDATION: ROTATE ALREADY-REGISTERED CREDENTIALSIf you already had a Sensedia Platform Client Secret or an MCP server client secret registered before this fix, that value was transmitted in cleartext on previous reads. We recommend rotating the affected credentials, in the following order, to avoid a window with no valid credential:
- Generate a new credential pair in Access Control (or in your MCP Server's OAuth provider).
- Write the new pair via
POST /v1/configs(or, for MCP Servers, by saving the edit form with the new Client Secret).- Validate that the gateway is operating normally with the new pair.
- Only then revoke the old pair.
Your own Authorization Server. In addition to the platform Authorization Server, AI Gateway lets you validate access tokens against your own OpenID Provider. Just provide the provider's Well-Known URL on the General screen: the gateway discovers the issuer and the public keys, validates the configuration when you save, and starts accepting only tokens issued by it.
REST API selection when registering MCP Servers. When creating an MCP Server from a catalog API, the selector lists only REST APIs, which are the ones that have an OpenAPI contract for generating the tools. This keeps the list leaner and avoids selections that would not produce a valid MCP Server.
MCP as Proxy: exposure and governance of existing MCP Servers. In addition to turning APIs into MCP Servers, the AI Gateway can now also sit in front of MCP Servers that already exist — internal to your company or from third parties — acting as a single point of governance, authentication, and observability.
You register an existing MCP as an origin, choose which tools to expose to your agents (allowlist), define the authentication mode, and route all traffic through the AI Gateway control layer, without rewriting, migrating, or re-hosting anything.
Support for custom and self-hosted language models. The AI Gateway now goes beyond traditional LLM providers (OpenAI, Anthropic, Gemini, among others) and allows integration with local, custom, or self-hosted language models — ideal for cost optimization, performance, compliance, or data sovereignty scenarios. You can also combine local and traditional models with priority rules.
Passthrough authentication for MCP Servers. The AI Gateway's MCP Servers now support the Passthrough authentication mode. Previously, when calling the business API, the MCP Server always generated its own service token (client_credentials). With Passthrough, the token of the end user logged into the agent can be passed on to the API, enabling scenarios where the API needs to identify the user to apply its own access rules — without giving up gateway governance.
AWS Bedrock with Assume Role. The AWS Bedrock integration can be authenticated through the Assume Role mechanism, where credentials are resolved at the infrastructure level, without relying on a static key registered in the gateway. To use it, just leave the API Key field blank when configuring a Bedrock provider. Authentication with an API Key remains available.
Prompt Guard with moderation and regex combined. The moderation and regex checks can be applied together in the same Prompt Guard (Request) policy. This makes it possible, for example, to submit the prompt to the moderation model and, at the same time, block specific patterns via regular expression, with a single custom response for both cases.
AI Gateway integrated into the Sensedia Platform and the Multi-Gateway strategy. The AI Gateway is now officially part of the Sensedia Platform, available on the home page alongside the other products and with unified access management via Access Control.
It also now operates integrated with the Multi-Gateway strategy: you can consume APIs from the federated catalog and expose them as tools and resources via MCP Servers, regardless of the gateway or API Manager of origin. In practice, the AI Gateway can be applied on top of existing API ecosystems, extending Federated API Management coverage to the AI context.
New hybrid infrastructure model. The AI Gateway now operates with a clear separation of responsibilities between platform and execution. This model supports multi-cloud and distributed scenarios, ensuring flexibility with centralized governance.
Sensedia AI Gateway. To enable secure, governed, and scalable adoption of Artificial Intelligence, we launched the Sensedia AI Gateway.
You can now orchestrate AI agents and LLMs with centralized governance, advanced security, and full observability across your entire architecture.
We use cookies to enhance your experience on our site. By continuing to browse, you agree to our use of cookies.Learn more