Overview 

An “Provider-Compatible Gateway or Proxy” (LLM Gateway) allows Kernaro AI to communicate with an LLM provider through your organization’s gateway. Instead of sending requests directly to the provider, all requests pass through the gateway, helping organizations apply their own security, authentication, and network policies before the requests reach the AI service. 

Adding the LLM Model with Gateway or Proxy

• Enabling the “Provider-Compatible Gateway or Proxy” toggle shows the following steps to configure the Gateway step by step according to the selected provider. 

Connection 

• The Base URL and the Model ID are the required fields once the fields been and click next once the fields are valid it will

For Azure Foundry Provider “Open AI” 

We will need to configure the following Connection fields for Azure Foundry provider “Open AI” Model type 

• Base URL 

• Model ID 

• Deployment 

• API Version 

Use Responses API 

The Use Responses API toggle determines which OpenAI-compatible endpoint Kernaro Assist uses when communicating through the configured LLM Gateway. 

When enabled, Kernaro Assist sends requests using the Responses API, which supports the latest OpenAI features and is recommended for modern AI models. 

When disabled, Kernaro Assist uses the Chat Completions API, which is intended for gateways or proxy servers that only support the legacy chat completions endpoint. 

Example 

• Azure OpenAI (latest API versions) → Enable Use Responses API. 

• proxy or custom gateway supporting only /chat/completions → Disable Use Responses API 

For Azure Foundry provider “Anthropic” Model type

• Base URL 

• Model ID 

Custom Headers 

• Configure any additional HTTP headers that your LLM gateway requires for every request. Click + Add Header to add key value pairs. These headers are included with every LLM request, in addition to the authentication of headers generated by the selected authentication method. 

• Use custom headers for gateway-specific requirements such as subscription keys, routing tokens, tenant identifiers, or any other custom values expected by your gateway. 

Reserved Headers 

The following header names are managed automatically by the authentication system and cannot be added as custom headers: 

• authorization : Generated automatically based on the selected authentication method (API Key or OAuth2).  

• content-type : Automatically set to application/json.  

• host : Automatically set to application/json.  

• x-api-key : Managed automatically by the Anthropic SDK and API Key

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) 
  by clicking the “verify and Save” button to complete configuration once verified. 

API Key 

Use the configured Gateway LLM API key and click the Verify and 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. 

Configure the following settings: 

• Enter the Identity Provider URL, then click Discover to automatically retrieve the OAuth 2.0 token endpoint.  

• Enter the Client ID from your identity provider’s application registration.  

• Enter the required Scopes (for example, api://your-app-id/.default).  

• Choose a client authentication method:  

• Client Secret – Enter the client secret associated with your application registration.  

• Certificate – Upload a PFX certificate to authenticate using a JWT Bearer assertion. Use this method if your identity provider requires certificate-based authentication instead of a client secret. Ensure the corresponding public certificate is registered with your identity provider. 

Authorization Code (Per-User Sign-In) 

Each user authenticates individually via their browser. 

Configure the following settings: 

• Enter the Identity Provider URL, Client ID, and the required Scopes. 

• Standard OIDC scopes (openid, profile, email, and offline_access) are added automatically and do not need to be specified. 

• Copy the displayed Redirect URI and register it in your identity provider’s application configuration. 

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

• Azure AD: Navigate to App Registrations → Authentication → Platform configurations → Web → Redirect URIs. 

• This authentication flow uses PKCE (Proof Key Code Exchange), so a client’s secret is not required. 

• Click Sign In to verify the configuration. A browser popup will open, allowing you to authenticate with your identity provider. 

• Once authenticated Sign-in complete page will be shown 

now getting back to the assist will display the signed user before proceeding the configuration, once the expected configuration is added proceed with verify and Save button