# LLM Gateway Management

> LLM Gateway Management - Provides admin controls to configure granular access to LLM models,
> enrollment policies, and deprecation fallbacks for an organization

This Markdown file sits beside the HTML page at the same path (with a `.md` suffix). It summarizes the topic and lists links for tools and LLM context.

Companion generated at `2026-06-22T16:50:38.101305+00:00` (UTC).

## Primary page

- [LLM Gateway Management](https://docs.datarobot.com/en/docs/platform/admin/llm-gateway-mgmt.html.md): Full documentation for this topic (Markdown sidecar).

## Sections on this page

- [Configure access](https://docs.datarobot.com/en/docs/platform/admin/llm-gateway-mgmt.html.md#configure-access): In-page section heading.
- [Access rule resolution](https://docs.datarobot.com/en/docs/platform/admin/llm-gateway-mgmt.html.md#access-rule-resolution): In-page section heading.

## Related documentation

- [Account management](https://docs.datarobot.com/en/docs/platform/index.html.md): Linked from this page.
- [Administrator's guide](https://docs.datarobot.com/en/docs/platform/admin/index.html.md): Linked from this page.

## Documentation content

LLM Gateway Management allows organization administrators to configure granular access to LLM models, enrollment policies, and deprecation fallbacks for an organization. These access rules are applied for all agentic workflows.

To manage provider, creator, and model access, open Admin settings and click the LLM Gateway Management tile. The left panel displays categories for models—provider as top-level, and creator as a child category—as well as badges that provide at-a-glance access information:

| Badge | Description |
| --- | --- |
| Org | Enabled organization-wide. |
| Custom | Access rules have been customized for users and/or groups. |
| Inherits | Adopts all access rules configured for the parent provider. |
| Disabled | Disabled organization-wide. |

Select a provider or creator in the left panel—access rules and associated models display. When a model is selected, that area displays its access rules and describes where that model is [inheriting its permissions](https://docs.datarobot.com/en/docs/platform/admin/llm-gateway-mgmt.html.md#access-rule-resolution) from.

## Configure access

Adminstrators can assign access control rules at the provider, creator, and model- level. To configure access rules:

1. Select a provider or creator in the left panel, or with one selected, click on a model in the Models section.
2. Then, next toWho can use this?, clickEdit override. Assign one or more access conditions, using the options in the dropdown: For example, to assign organization-wide access to Amazon Bedrock, selectAllowandOrganization. If the access conditions conflict with existing permissions, the affectedTargetfield values are highlighted in red and a message with additional details displays below them.'
3. ClickSaveto apply the access rule.

To quickly reset access rules, next to Edit access rule, click Delete.

## Access rule resolution

At the model level, you can view how the access rules are resolved for the provider, creator, and model, detailing exactly where the model's inheriting permissions. To correctly read the access rules, start with Model and move upwards. The table uses the following badges:

| Badge | Description |
| --- | --- |
| Effective | Access rules adopted by the model. |
| Inherited | Access rules are adopted by the entity above it. |
| Overidden | ccess rules are not applied to the model because they are overriden in the hierarchy. |

> [!NOTE] Example 1: Inherited rules
> If the model has no access rules, it inherits rules from the creator and displays an
> Inherited
> badge on the right.
> If the creator also has no access rules, the model inherits rules from the provider.
> The provider has the rule
> Allow Organization
> , meaning the model will use these rules to determine access and displays an
> Effective
> badge on the right. In this case, the model is available organization-wide.

> [!NOTE] Example 2: Overidden rules
> The model has the access rule Allow Organization, however, the creator and provider also have access rules. In this case, the rules for the creator and provider are overriden by the model's rule, meaning the model is available organization-wide. The model displays an Effective badge, and both the creator and provider display an Overidden badge.

**Access flowchart**

In this example, you're requesting chat completion with the model `LLM Model gpt-4o`, but first, DataRobot must evaluate your access to the model.     DataRobot collects the parent provider, creator, and model rules and must answer "What access rules are configured to each of these resources separately?"

For the first step, in the internal access control system, DataRobot checks each of the collected resources for an explicit deny on any level. If there is any deny, the result is denied. The result is also denied if there are no rules at all. If there is allow at any level (without explicit deny), the result is allowed.

Then, DataRobot starts checking for an explicit allow to the model, starting with the model itself and ending with the provider. Once again, if there are no access rules for all three, the result is deny. At the end of this process, you will either be denied access, in which case you receive the error "404 - Not found error: `Model not found in catalog`", or you can proceed with chat completion.

```
flowchart TD
    classDef allow fill:#90EE90,stroke:#4CAF50,color:#000
    classDef deny fill:#FFB6C1,stroke:#F44336,color:#000

    A["/chat/completion/responses<br/>llm: azure/gpt-4o"] --> B{Access evaluation}

    B --> C["Internal DataRobot Access Control System"]
    C --> D["LLM Provider<br/>entity: Azure<br/>user: user1"]
    C --> E["LLM Creator<br/>entity: Azure/OpenAI<br/>user: user1"]
    C --> F["LLM Model<br/>entity: azure/gpt-4o<br/>user: user1"]

    D & E & F --> G{Explicit allow for<br/>LLM Model gpt-4o?}

    G -- Yes --> ALLOW1([Allow]):::allow
    G -- No --> H{Explicit deny for<br/>LLM Model gpt-4o?}
    H -- Yes --> DENY1([Deny]):::deny
    H -- No --> I{Explicit allow for<br/>LLM Creator Azure/OpenAI?}
    I -- Yes --> ALLOW2([Allow]):::allow
    I -- No --> J{Explicit deny for<br/>LLM Creator Azure/OpenAI?}
    J -- Yes --> DENY2([Deny]):::deny
    J -- No --> K{Explicit allow for<br/>LLM Provider Azure?}
    K -- Yes --> ALLOW3([Allow]):::allow
    K -- No --> DENY3([Deny]):::deny

    ALLOW1 & ALLOW2 & ALLOW3 --> L{Allow?}
    DENY1 & DENY2 & DENY3 --> L

    L -- No --> M[Raise 404 Not Found]
    L -- Yes --> N[Proceed with chat completion]
```