Overview  

 
An LLM Gateway acts as a secure bridge between Kernaro AI and your AI service provider. Rather than sending requests directly to the provider, Kernaro AI sends them through the gateway, which securely forwards them to the selected LLM. 

Gateway Configuration of Reasoning LLM  

Enabling the Gateway 

1. Go to Configuration → Reasoning LLM 

2. Select your LLM provider 

3. Enable the “Provider-Compatible Gateway or Proxy” toggle 

Once enabled, three configuration sections appear: Connection, Headers, and Authentication. 

Azure Foundry Anthropic (Model Type Toggle) 

When Azure is selected, a model type toggle appears: 

• OpenAI (default) — Standard Azure OpenAI models (GPT-4, GPT-5, etc.) 

• Anthropic — Claude models deployed via Azure AI Foundry 

Without gateway (direct mode): 

Azure Model Type	Required Fields
OpenAI	Endpoint, API Key, Deployment Name, API Version
Anthropic	Endpoint, API Key, Model (dropdown with Claude models)

With gateway enabled: 

Azure Model Type	Required Fields
OpenAI	Base URL, Model ID, Deployment Name, API Version
Anthropic	Base URL, Model ID

Note: The Anthropic toggle is only available in Reasoning mode. It is hidden for Embedding (Claude has no embedding models) and Batch (Anthropic Batch API is not supported on Azure Foundry 

Connection Tab 

Provider	Required Fields
Azure (OpenAI)	Base URL, Model ID, Deployment Name, API Version
Azure (Anthropic)	Base URL, Model ID
OpenAI	Base URL, Model ID
Anthropic-Claude	Base URL, Model ID

• Base URL: Your gateway endpoint URL. Must use HTTPS (except `localhost` for development). 

• Example: `https://your-apim.azure-api.net/your-api-path` 

• Model ID: The model’s name exposed by your gateway (may differ from the provider’s native model ID. 

Headers Tab 

• Add custom HTTP headers that your gateway requires on every request. Click + Add Header to add key value pairs. These headers are sent with every LLM request alongside any authentication headers. 

• Use this for any gateway-specific headers such as subscription keys, routing tokens, or custom identifiers required by your gateway. 

**Reserved headers** — the following headers are managed automatically by the authentication system and **cannot** be used as custom header names: 

• `authorization` — managed by the selected auth type (API Key, OAuth2) 

• `content-type` — set automatically to `application/json` 

• `host` — set automatically from the Base URL 

• `x-api-key` — managed by the Anthropic SDK and API Key auth 

Authentication Tab 

Four authentication types are available. The auth configuration is **common across all providers**. 

None 

No authentication headers are sent. Use when: 

• Your gateway handles auth at the network level (VPN, private endpoint) 

• Custom headers alone are sufficient (e.g., `Ocp-Apim-Subscription-Key` added in the Headers tab) 

API Key 

Use the configured Gateway LLM API key and click the save button. 

Certificate (mTLS) 

Mutual TLS authentication using a PFX/P12 certificate file. 

1. Upload a valid `.pfx` or `.p12` certificate file 

2. Enter the certificate password (if required) 

3. Certificate details (subject, issuer, expiry, key type) are displayed after upload 

OAuth 2.0 

OAuth2 authentication supports two grant types: 

Client Credentials 

A single application-level token shared across all users. 

• Enter **Identity Provider URL** and click **Discover** to auto-detect the token endpoint 

• Enter **Client ID** from your IdP’s app registration 

• Add required **Scopes** (e.g., `api://your-app-id/.default`) 

• Choose a client authentication method: 

• **Client Secret**: Enter the secret from your IdP’s app registration 

• **Certificate**: Upload a PFX certificate for JWT Bearer assertion (for IdPs that require certificate-based client authentication instead of a shared secret). The corresponding public certificate must be registered in your IdP. 

Authorization Code (Per-User Sign-In)

Each user authenticates individually via their browser. 

• Enter **Identity Provider URL**, **Client ID**, and **Scopes** 

• OIDC scopes (`openid`, `profile`, `email`, `offline_access`) are added automatically 

• Note the **Redirect URI** displayed — register this in your IdP’s app registration 

• Example: `https://your-kernaro-domain.example.com/oauth2/callback` 

• For Azure AD: App Registration → Authentication → Platform configurations → Web → Redirect URIs 

• Uses PKCE (Proof Key for Code Exchange) for security — no client secret needed 

• Click **Sign In** to test — a popup opens with your IdP’s login page 

When Authorization Code is configured, all users (admin and non-admin) must sign in before using the chat: 

1. User opens the chat page → a blocking modal appears: **“Sign in to {Provider}”** 

2. User clicks **Sign In** → IdP login popup opens (Microsoft login, etc.) 

3. User authenticates (username, password, MFA if required) 

4. Popup shows **”Sign-In Successful“** and auto-closes 

5. Chat becomes available 

After signing in: 

• The sidebar footer shows gateway connection status with the user’s email 

• A **Sign Out** button is available — sign-out only affects the current user; other users remain signed in 

• Tokens auto-refresh in the background; if refresh fails, the user is prompted to re-sign-in 

• For admin users: if signed out and blocked by the sign-in modal, a **“Go to Configuration”** link appears to access the LLM config page 

Gateway Configuration  of Embedding LLM

The Embedding LLM supports the same gateway features as Reasoning with these differences: 

**What’s the same:** Gateway toggle, connection, headers, and all four authentication types.  

**What’s different:** 

**No Azure Anthropic toggle** — Claude does not offer embedding models on any platform.  When Azure is selected, it defaults to OpenAI. 

**Client Credentials is recommended** — Embedding operations run as background tasks that process large volumes of data without user interaction. Client Credentials provides a single application-level token that doesn’t require user sign-in and won’t expire mid-operation. When Authorization Code is selected, an info banner appears with a **“Switch to Client Credentials”** button. 

Gateway Inheritance (Use From) 

When multiple LLM modes (Reasoning + Embedding) use the **same gateway**, you can configure it once and inherit: 

1. Configure the full gateway on one mode (e.g., Reasoning LLM — Base URL, Headers, Auth) 

2. On the other mode (e.g., Embedding LLM), check **“Use gateway from Reasoning LLM”** 

3. All gateway settings are inherited — only model information (Model ID, Deployment Name, API Version) differs 

4. For Authorization Code flow: one sign-in covers both modes (tokens are shared) 

Rules: 

• You cannot turn off the gateway on a mode if another mode is inheriting from it 

• Model ID, Deployment Name, and API Version are NOT inherited — each mode configures its own 

• Inherited configuration is read-only (shown as disabled fields) 

To modify inherited settings, go to the source mode or uncheck the inheritance option