scopes. For anyone calling the API directly, a PUT on /api/v1/routes/{routeId} or on /api/v1/mcp/servers/{mcpServerId} that omits scopes, or sends it as null, now responds 400 (code 400.001, field scopes) and changes nothing. Previously, omitting it silently removed the scope requirement and left the route or MCP Server accepting any authenticated token. To remove the scope requirement on purpose, send "scopes": []. Creation is unchanged: scopes stays optional. In the UI nothing changes: the routes form now always sends the scopes list.ai-gateway.ai-agents.credentials.read), granted in Access Control, under Roles, for the AI Gateway product. By default, it is already present in the Super Admin and Admin profiles and is not in Read-Only. See AI Agents.Audit trail for Inbound Address operations. Saving the inbound host configuration (in Virtual Hosts > Inbound Address) now generates a change record in the Access Control Audit Log, with the date, the author, and the outcome. On success, the Name is the host saved in lowercase, and the content is the configuration after saving: protocol, host, the selected certificate and Trust CAs (by identifier), and whether mTLS is enabled, never the certificate or CA material. Refusals right at the entry point (for example, a missing protocol or host, a missing header) generate no record; failures while processing the operation (including an invalid host format, a missing certificate on HTTPS, and an incoherent or nonexistent Trust CA) also generate a record, with the Name equal to the host as it was sent and the content carrying the failure reason and the attempted configuration. Queries generate no record. The screen stays the same. For those who call the API directly, more than 100 items in trustStoreIds, which used to end in an error, or a host, a certificateId, or a trustStoreIds item above 253 characters, which used to be accepted, are now refused with 400, with no record. See Custom Inbound.
Audit trail for Routes operations. Creating, editing, and deleting a route generates a record in the Access Control Audit Log, with the date, the author, the outcome, and the content of the object, never the configuration of another referenced object, only its identifier. Refusals right at the entry point (for example, a missing required field) generate no record; failures while processing the operation (including a nonexistent route, an LLM Provider or scope that does not exist, or a malformed scope id) also generate a record. A success record with an empty scope list indicates the route requires no scopes and accepts any authenticated token; in a create or update failure record, the list shows what was requested; in a delete failure, it is the route's state read before removal. Queries generate no record. For those who call the API directly, an exposedEndpoint or an llmProviderEndpoint above 1024 characters, an llmProviderId or a scopes item above 253 characters, and more than 100 items in scopes are now refused with 400, with no record. See Routes.
Audit trail for Scopes operations. Creating, editing, and deleting a scope now generates a record in the Access Control Audit Log, with the date, the author, the outcome, and the content of the object: identifier, name, and description, without the Authorized resources data. The record can be queried with the Scope filter, which does not need to be combined with Product, and the Name column shows the scope identifier, or stays empty on a failed creation, because no identifier exists yet. Requests refused right at the entry point (for example, a blank name or one above 255 characters) generate no record; failures while processing the operation (including a name already used, a nonexistent scope, a malformed id, and a name change or deletion of a scope in use) also generate a record. Queries generate no record. For callers of the API directly, a name containing spaces such as the em space (U+2003), which used to end in an error, or above 255 characters and a description above 1024 characters are now refused with 400, with no record. See Scopes.
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