LLM Providers

The LLM Providers module defines the set of models and providers that AI Gateway can invoke when a route is triggered. Each provider is a reusable configuration that groups one or more provider + model + API Key combinations with different priorities. This helps you define failover strategies or balance requests across models.

NOTE

Before creating an LLM Provider, register the API Keys for the providers you want to use. The form only lets you save when at least one key exists for each selected combination — the only exception is Bedrock, which also accepts Assume Role authentication.

Quick links

Learn how to:

• Filter and list LLM Providers
• Create an LLM Provider
• View an LLM Provider
• Edit an LLM Provider
• Delete an LLM Provider
• Review the Audit Log record
• Review the form fields
• Understand conditional fields by provider
• Configure Bedrock with Assume Role
• Review permissions

Listing

The LLM Providers page lists registered configurations with pagination. You can filter by:

• Provider (optional): associated LLM provider. Values: All Providers, OpenAI, Gemini, Anthropic, Azure OpenAI, Azure AI Foundry, Bedrock, Vertex AI, Custom.
• Model (optional): text search by model name.

Use Search to apply the filter and Clear to reset it.

Columns shown in the table:

• Providers and Models: summary of registered Provider / Model / Priority combinations, separated by |.
• Created At: creation date and time.
• Actions: View and Delete icons for each row, each one shown according to the user's permission — see Permissions. The whole column disappears when neither icon is available.

Create LLM Provider

View LLM Provider

In the Actions column of the row you want, click the View icon. This opens the read-only Overview screen, on the General Info tab. The Provider configurations block states how many configurations the record holds and lists one section per configuration — Provider 1, Provider 2 and so on — each with the following fields:

• Provider
• Model
• Priority (shown as P1, P2, …)

At the end, the block shows the Created At field. No field is editable on this screen.

Edit LLM Provider

Editing lives inside the details screen. Open the record through the View icon (see View LLM Provider) and, on the Overview screen, click the Edit button next to the Provider configurations title. The Update LLM Provider form opens with all configurations prefilled. Change the required fields, add or remove provider rows, and click Save.

Delete LLM Provider

In the Actions column of the row you want, click the Delete icon. Confirm the operation in the "Are you sure you want to delete this LLM provider?" dialog.

IMPORTANT

Deletion is permanent and cannot be undone. Routes that reference the deleted LLM Provider start failing. Update or remove dependent routes before deleting it.

Audit Log record

Creating, editing, or deleting an LLM Provider generates a queryable record in the Access Control Audit Log, with the date, the author, the outcome of the operation, and the object's content. Querying, listing, or opening the detail of an LLM Provider doesn't generate a record — only write operations are audited.

A request refused right at the entry point — for example, due to invalid data — generates no record at all. From the moment the operation is processed, both success and failure generate a record, and the failure record carries the reason for the refusal and the configuration that was attempted, including when the failure happens because the object doesn't exist. On deletion, when the object's content can't be read before removal, the record carries only the LLM Provider identifier. The trail therefore shows the attempt, not only what changed.

Querying the Audit Log uses the Audit List (access-control.audits.list) and Audit View (access-control.audits.view) permissions, which already govern that screen.

Form fields

The form is made up of a list of provider configurations. At least one is required. Each Provider block repeats the fields in the table below.

Action buttons outside the table:

• Add provider: adds a new Provider block to the list.
• Delete icon for each block: removes the corresponding block (disabled when there is only one configuration).
• Save: saves the creation or edit. Cancel: discards changes.

Conditional fields by provider

The visibility and required state of some fields depend on the Provider selected in each block:

• OpenAI, Gemini, and Anthropic: do not require extra fields beyond Priority, Provider, Model, and API Key.
• Azure OpenAI: shows the required Resource name field.
• Azure AI Foundry: shows the Resource name and Project name fields, both required.
• Bedrock: shows the Region field (required) and the Guardrail identifier + Guardrail version pair (optional as a pair; when you fill in one, the other becomes required).
• Vertex AI: shows the Project ID field (required) and the Region field (optional — left blank, the gateway uses the global endpoint).
• Custom: shows the Host and Port fields, both required. Use this provider for any model that exposes an API compatible with the OpenAI completions standard (OpenAI-like) — the requirement applies both to your own or self-hosted models and to providers not yet natively supported by the platform.

TIP

The Guardrail pairing rule prevents ambiguous configurations. To disable the guardrail, clear both fields. They become optional again, and the set is not sent when you save.

Bedrock with Assume Role

For the Bedrock provider, the API Key field is optional. Leave it blank when you want the gateway to authenticate with AWS through the Assume Role mechanism, where credentials are resolved at the infrastructure level instead of being registered as a static key. This is the recommended setup for cross-account AWS integrations.

If you prefer to authenticate with a static key, select a Bedrock API Key as usual — both forms are accepted, and the choice applies per configuration block.

REQUEST THE INFRASTRUCTURE SETUP

Assume Role depends on an infrastructure setup that must be prepared in advance for your environment. Open a ticket with the Sensedia support team requesting Assume Role to be enabled for the Bedrock integration. Without this preparation, a Bedrock provider registered without an API Key will not be able to authenticate with AWS.

Permissions

Access to each action in the LLM Providers journey depends on its own permission. Without the corresponding permission, the screen element does not appear — the interface never shows an unavailable action as disabled.

Permissions are granted in Access Control, on the Roles screen, under the AI Gateway product. The table below lists each one exactly as Access Control displays it.

The last one belongs to another journey and is required by specific LLM Providers actions, shown in the next table.

Create and Edit: List API Keys is what feeds the form's API Key field, required in every provider configuration except Bedrock (see Conditional fields by provider). Without it, the key list comes up empty and the form shows No API Keys are registered for the selected provider., even when credentials do exist.

A control without its permission is not rendered; an LLM Provider reached directly by URL without its permission lands on the AI Gateway's own access denied screen, not on Access Control's.

EDITING REQUIRES VIEWING

The Edit button only exists inside the record's Overview screen. Because of that, a user holding Create and Update LLM Providers but not View LLM Provider has no path to edit an already registered configuration. This is expected platform behavior, not a bug.