AI Gateway
DIAL Core is the AI gateway of the platform: the single layer that every request from users, applications and agents passes through on its way to models, applications and tools. It accepts requests in several industry-standard protocols, bridges between them with translators, and enforces connectivity, access control, guardrails, limits and logging in one place. The AI Gateway section of DIAL Admin manages the entities that DIAL Core serves.
What the gateway does
- Connects to models. Calls language and embedding models from cloud vendors, self-hosted and fine-tuned models, directly or through OpenAI-compatible adapters.
- Speaks industry-standard protocols. Accepts OpenAI Chat Completions and Responses, Anthropic Messages, MCP and A2A requests, so the coding assistants and workflow automation tools your teams already use can connect without a custom integration.
- Bridges between protocols. Translators convert a request from one LLM API to another, so a client can reach a model or an application even if the two do not support the same interface.
- Works with MCP in both directions. Toolsets connect applications to MCP servers, and other systems can reach DIAL through MCP.
- Controls access. Checks every request against roles and API keys, down to individual models, applications and toolsets, using claims from your identity provider.
- Applies guardrails. Passes requests and responses through interceptors for PII protection, data-leak prevention, prompt-injection defense and content filtering.
- Balances load and fails over. Routes and model upstreams spread traffic across models, regions and subscriptions, and fail over when a destination is unavailable.
- Limits usage and cost. Enforces limits per user, role or API key in real time.
- Logs and exports telemetry. Records every request and ships telemetry through OpenTelemetry. DIAL Analytics turns the logs into reports on usage and cost.
- Runs in your environment. Deploys in your cloud or on-premises, so data stays inside your boundary.
Every item in the AI Gateway section is an entity in the runtime configuration of DIAL Core. This page explains where an entity can be defined, how DIAL Core combines the definitions, and what happens when you create an entity in DIAL Admin, through the API, in the DIAL Core configuration file, or by publishing.
Entities
| Entity | What it is |
|---|---|
| Models | Language and embedding models that DIAL Core calls, directly or through an adapter. |
| Applications | Applications and agents that DIAL Core serves to clients alongside models. |
| Toolsets | Sets of tools that connect applications to MCP servers. |
| Routes | Paths that DIAL Core proxies to an upstream server, with rate limiting, role-based access and load balancing. |
| Translators | Services that convert a request from one LLM API to another, so a deployment can serve an API it does not speak itself. |
| Application runners | Definitions of application types: a JSON schema, and a factory that lets users create configured instances of an application, such as Quick Apps or Code Apps. |
| Catalog schemas | Declarations of the metadata a catalog entity exposes and how the DIAL Catalog shows it. |
Roles and API keys are also DIAL Core entities, and interceptors too. They are managed in the Governance section.
Where an entity can be defined
An entity lives in one of three places. DIAL Admin shows each place as a root folder.
| Source | Where it is stored | How an entity gets there | Shown in DIAL Admin |
|---|---|---|---|
| Config file | The DIAL Core configuration files (aidial.config.json, listed in the config.files setting). | By editing the file manually. | The file folder, read-only. You can't add, edit or delete entities in it from DIAL Admin or the API. |
| Platform storage | The platform folder of DIAL Core blob storage. | In DIAL Admin, or through the DIAL Core API. | The platform folder. You create, edit and delete entities here. |
| Public folder | The public folder of DIAL file storage. | Users publish their private entities, and an administrator approves them. Administrators can also add them. | The public folder, for applications and toolsets only. |
Users also have a private folder with their own applications and toolsets. They are visible only to the owner and are not shown in DIAL Admin.
Entities section is being deprecated
The former Entities section wrote entities directly into the DIAL Core configuration file. Entities created there are shown in the file folder of the AI Gateway. New entities are created in the AI Gateway instead, and go to the platform folder. When the Entities section is removed, the DIAL Core configuration file will be managed only manually.
How DIAL Core combines them
DIAL Core builds one runtime configuration from these sources and uses it to handle requests.
- Config file. DIAL Core reads the configuration files when it starts and then reloads them at the
interval set in
config.reload(60 seconds by default). You don't need to restart DIAL Core after you change a file. - Platform storage. The entities stored in the
platformfolder are equivalent to the entities in the file: they have the same fields and the same effect. DIAL Core merges them into the same runtime configuration, and applies a change made through DIAL Admin or the API without a restart. - Public folder. Published applications and toolsets are not part of this merged configuration. DIAL Core resolves them when a request refers to them, and checks the access rules of their folder.
- Same name. For models, interceptors, roles, applications and toolsets, the file and the platform storage share one list of names. If a platform entity has the same name as a file entity, the platform entity overrides it when the entity is used. Use distinct names to avoid surprises.
- Invalid definitions. DIAL Core validates entities when it reads them. An invalid definition is rejected, and the previous valid configuration stays in effect.
Only administrators can write to the platform storage. DIAL Core recognizes administrators by the
access.admin.rules setting, which matches identity token claims.
What happens when you…
| Action | Result |
|---|---|
| Edit the config file | After the next reload, the entity is active in DIAL Core and appears in DIAL Admin under the file folder. It is read-only in DIAL Admin: to change it, edit the file again. |
| Create or edit an entity in the AI Gateway | DIAL Admin calls the DIAL Core API with your identity. The entity is saved in platform storage and becomes part of the runtime configuration. The config file is not changed. |
| Create an entity through the DIAL Core API | It is saved in platform storage, in the same way as in DIAL Admin, and appears under the platform folder. |
| Create an entity in the deprecated Entities section | It is written to the DIAL Core configuration file and appears under the file folder. |
| Publish an application or a toolset | After an administrator approves the request, a copy is placed in the public folder and appears under the public folder. The original stays in the owner's private space. |
| Create the same entity in the file and in platform storage | The platform entity overrides the file entity. |
| Move a file entity to platform storage | Not automatic. An administrator can copy file-defined entities to platform storage on demand with the DIAL Core admin migration endpoint, which also has a dry run. Copying is not done on startup, because it would bring back entities that were deleted through the API. |
Note
Platform entities are stored in DIAL Core blob storage and not in the config file, so back them up with the storage or with Export Config in DIAL Admin. See Back up, restore and set global properties.
Access to entities
Models, applications, toolsets and routes can restrict access with roles. A role is matched against the claims of the user's token or the role of an API key. If an entity has no roles, it is available to all users. Folder access rules additionally control who can see published applications and toolsets.