> ## Documentation Index
> Fetch the complete documentation index at: https://koreai.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# AI configuration

> Configure LLM providers, model pricing, Arch settings, voice services, guardrails, and auth profiles.

The **AI Configuration** settings control how your workspace connects to AI models and services. From here you register provider credentials, manage the model catalog, configure safety guardrails, and set up authentication profiles that tools and agents use at runtime.

* **Navigation**: Settings > AI Configuration
* **Required role**: Owner or Admin

***

## LLM providers

The Agent Platform is provider-neutral. Agents can use models from multiple LLM providers, and you can switch between them without changing agent definitions.

* **Navigation**: Settings > AI Configuration > LLM Providers
* **Required role**: Owner or Admin

The page is organized into three tabs: **Credentials**, **Model Catalog**, and **Project Access**.

### Credentials

The **Credentials** tab lists all provider credentials registered in your workspace, grouped by provider. Each credential card shows the name, provider, creation date, and the number of models using that credential.

**Add a credential:**

1. Go to **AI Configuration > LLM Providers > Credentials**.
2. Click **+ Add Credential**.
3. Enter a **Name** (for example, *Production OpenAI*), select a **Provider**, and enter the **API Key**.
4. Click **Add Credential**.

> [!NOTE]
>
> API keys are encrypted at rest and never displayed in plaintext after the initial entry.

**Delete a credential:**

Click the delete icon on the credential card. Deleting a credential disconnects all models linked to it. Those models display a **No Keys** status in the Model Catalog until a new credential is connected.

### Model catalog

The **Model Catalog** tab lists all models registered in your workspace. Each row shows the provider, model name, model ID, linked credentials, and status.

**Workspace tier defaults**

A model becomes a workspace default only when a workspace admin selects it here for a routing tier. It must be ready, active, inference-enabled, and backed by a Workspace-shared connection. Configured models may remain without a default, and a tier default never grants project access.

Defaults are one-per-tier workspace catalog metadata - they don't grant or automatically apply project access. Each project must separately select an authorized binding in **Selected models** (see [Project Access](#project-access)).

For each tier (**Fast**, **Balanced**, **Powerful**, **Voice**), the panel shows the tier's intended use, its associated operation tags (for example Fast: Extraction, Validation, Tool selection), and a **Workspace default** dropdown to assign a model.

Below the tier defaults panel, the model table lists every registered model with its provider, model name and ID, connections, a star (favorite) icon, and **Ready** status.

**Add a model from the catalog:**

1. Go to **AI Configuration > LLM Providers > Model Catalog**.
2. Click **+ Add Model**, browse or search for a provider model.
3. Review and configure the available model settings.
4. Click **Add to Workspace**.

For more information, see [supported models](https://koreai.mintlify.site/agent-platform/supported-models).

For information about configuring models from Microsoft Foundry, see [Microsoft Foundry](https://koreai.mintlify.site/agent-platform/administration/microsoft-foundry).

**Add a custom model**

1. Go to **AI Configuration > LLM Providers > Model Catalog**.

2. Click **+ Add Model**, then select the **Custom Model** tab.

3. Fill in the following fields:

   | Field | Description |
   | - | - |
   | Display Name | A label for the model in the platform. |
   | Model ID | The model identifier, for example `gpt-4o` or `claude-sonnet-4-20250514`. |
   | Provider | The provider this model belongs to. |
   | Tier | Assign the model to a tier: Fast, Balanced, Powerful, or Voice. |
   | Temperature | Controls response randomness. Default: 0.7. Available fields vary by the selected model. |
   | Max Tokens | Maximum tokens the model can generate per response. Default: 4096. Available fields vary by the selected model. |
   | Endpoint URL | Optional. For custom or self-hosted endpoints. |

   > [!NOTE]
   >
   > Available fields in the Custom Model dialog depend on the selected model and provider - not every model exposes Temperature or Max Tokens.

4. Click **Add to Workspace**.

**Configure model settings:**

Expand any model row to view and edit its settings.

**Connections**

Shows credentials linked to this model, with connection visibility and health controls.

* Click **+ Add Key** to connect a credential. In the **Add Connection** dialog, choose one of two connection methods:

  | Method | Description |
  | - | - |
  | **Credentials** | Select an existing credential from the **Credential** dropdown. |
  | **Use Auth Profile** | Select an **Auth Profile** instead of a direct credential. Credentials are resolved at runtime via the selected profile, which must have an **Active** status and a compatible auth type for this provider. |

  Optionally check **Set as primary connection**, choose **Connection visibility** (default: **Workspace-shared** - the compatibility-safe default; restrict a connection only when its project allowlist is known), then click **Create Connection**.

* Each connected credential is listed with its name, type (for example **API Key**), whether it's the **Primary** connection, and the date it was added. Click **Test** to verify the connection, or the delete icon to remove it.

* When multiple connections use the same model, each connection is assigned a stable label, such as Connection 1, Connection 2, or Connection 3. These labels help distinguish connections in the model catalog and other model-selection interfaces.

* Change a connection's **Connection visibility** at any time and click **Save access** to apply.

A model with no credentials shows **No Keys** status and can't serve requests.

**Settings** - Configure Verbosity, Temperature, Top P, Max Completion Tokens, Compaction Threshold, Tier, OpenAI API Mode, and Response Mode. Available fields vary by provider and model capabilities - for example, reasoning models show **Verbosity** instead of Temperature and Top P.

**Reasoning**

For reasoning-capable models, this panel runs diagnostic checks and lets you set the reasoning effort:

| Check | Description |
| - | - |
| **Connection and credentials** | Whether a working, credentialed connection is available. |
| **Boolean thinking** | Whether the model supports a simple on/off thinking mode. Shows **Not applicable** for models that use effort levels instead. |
| **Reasoning effort levels** | Whether the model supports configurable reasoning effort, and which levels it supports (for example: none, minimal, low, medium, high, xhigh). |

Select the **Reasoning Effort** level from the dropdown to control how much reasoning the model applies before responding.

**Capabilities**

Enable supported capabilities: **Default for Tier**, **Tools**, **Vision**, **Streaming**, and **Realtime Voice**. Available capabilities are model-dependent - unsupported ones appear disabled.

Click **Save** to apply changes, or **Delete** to remove the model from the workspace.

### Decision providers

Decision providers use small, fast models to handle specific decisions during agent execution. For an overview of decision models and configuration instructions, see [Decision Models](https://koreai.mintlify.site/agent-platform/administration/decision-models).

> [!NOTE]
>
> To use decision models in your workspace, a platform administrator must first enable the feature in the Admin Console. The Decision providers section in **AI Configuration > LLM Providers > Model Catalog** is visible only after **Decision Models** is enabled for the workspace.

### Model tiers

Tiers decouple agent definitions from specific model choices. Agents reference tiers, and the platform resolves the tier to a specific model at runtime:

| Tier | Intended use | Typical models |
| - | - | - |
| Fast | Classification, routing, quick responses. | Claude 3.5 Haiku, GPT-4o mini, Gemini 2.0 Flash. |
| Balanced | General-purpose tasks balancing quality and cost. | Claude 4 Sonnet, GPT-4o, Gemini 2.5 Flash. |
| Powerful | Complex reasoning, analysis, content generation. | Claude 4 Opus, o3, Gemini 2.5 Pro. |
| Voice | Real-time voice interaction. | GPT-4o Realtime, Gemini 2.0 Flash (Live). |

### Project Access

The **Project Access** tab inspects and manages a single project's model bindings and feature routing, from the same authoritative configuration used by Studio and Runtime.

* Select the project from the **Project** dropdown.
* The tab has three sub-tabs: **Selected models**, **Feature config**, and **Resolution diagnostics**.

> [!NOTE]
>
> Secret values and binding identifiers are never shown on this page.

**Selected models**

Shows which workspace-catalog models this project is allowed to use.

* **Model access rollout** banner - indicates whether the project uses selected model bindings only, or has unresolved legacy references.
* **Imported default model unavailable** banner (when applicable) - shows a legacy project default that was imported but can't run until its workspace model and credential are configured, tagged **Project default** and **Workspace model not configured**.
* **Selected models** / **Eligible models** counts.
* The **Selected models** list shows each bound model with its provider, connection type (for example `Workspace-shared`), status (for example **Ready**), and whether it's the **Project default**. Click the **X** to remove a model.
* Click **+ Add models** to open **Add models from the workspace catalog**. Search, then click **Add** next to any workspace-shared or project-restricted connection - each entry shows its provider, connection type, and readiness (for example **Not tested** or **Ready**).
* Use the **Project default (this project only)** dropdown to set which selected model is this project's default, then click **Save selection**.

**Feature config**

Controls how individual platform features (operations) resolve to a model, either by tier or by per-feature override.

* Toggle **Per-operation routing** to switch between "every feature follows its tier" (off) and per-feature overrides (on).

* Banners:
  * **Some features need attention** - lists features whose model binding needs a fix.
  * **Model access rollout** - same as in Selected models.
  * **Catalog features not available for execution** - lists newer catalog features not yet executable (for example: Query rewriting, Retrieval reranking).

* **Tier bindings** - **Fast**, **Balanced**, **Powerful**, and **Voice** cards, each showing the feature count on that tier, a model dropdown (or **No model bound**), and a short description of the tier's intended use. Each tier draws only from this project's selected models.

* Below the tier bindings, the full feature list is grouped by category:

  | Category | Purpose | Example features |
  | - | - | - |
  | **Arch** | Designing, diagnosing, and generating. | Arch assistant |
  | **Runtime** | Serving live conversations. | Default runtime model for agents, Entity extraction, Validation, Intent detection |
  | **Knowledge** | Answering from your content. | Progressive summarization, Question synthesis, Knowledge graph extraction |
  | **Insights** | Computing conversation insights. | Insight intent classification, Insight quality evaluation |
  | **Evals** | Testing before release. | Evaluation suite generation, Simulated user, Eval remediation |
  | **Pipelines** | Tuning how content is ingested. | Pipeline LLM stages |

  Each feature row shows an enabled checkbox, its name, description, and operation code; a tier-or-override control (a tier dropdown, or **Override with a model** to pin a specific model, plus a **Why this model?** link explaining the resolution); which model it **Resolves to**; the source it came **From** (for example **Project default**); and its **Status** (for example **Ready**).

  > [!NOTE]
  >
  > Overrides can use selected project bindings only.

* Click **Save feature config** to apply changes. \[!WARNING] Select a ready model binding or repair the connection before releasing this project.

**Resolution diagnostics**

A read-only preview of the model and credential source Runtime actually selects for each operation. Secret values and binding identifiers are never shown.

* Choose the **Resolution context** to preview - for example **Project working configuration**, or a specific deployment (for example `dev · 1.0`).
* The table lists each **Operation** (for example Extraction, Validation, Tool selection, Response generation) with:

  | Column | Description |
  | - | - |
  | **Requested Tier** | The tier the operation asks for, and whether it's using the feature's default tier. |
  | **Resolves To** | The model and provider that actually serves the operation. |
  | **Credential** | Whether a usable credential was found (for example **Credential ready**) and the connection type. |

  Click **View resolution details** on a row to see the full precedence trail - for example whether a **Deployment override**, **Project feature override**, **Project model selection**, or **Workspace tier default** was applied.

### Troubleshooting

| Issue | Potential causes | Resolution |
| - | - | - |
| Model shows **No Keys** status | No credential linked to the model. | Expand the model row and click **+ Add Key** in the Connections section. |
| Model validation fails | Invalid API key, incorrect endpoint URL, or blocked outbound connections. | Confirm the API key with the provider directly. For Azure, verify the endpoint includes the deployment name. Check that outbound HTTPS connections to the provider are allowed. |
| Agent can't find a model for the requested tier | No active model assigned to the tier, or the linked credential is inactive. | Verify at least one active model is assigned to the tier with a **Ready** status. Check that the model's linked credential is active. |
| Token budget exceeded | High token consumption across operations. | Review consumption in **Account > Billing & Usage**. Switch high-volume operations to a Fast-tier model to reduce usage. |

***

## Model Pricing

Manage workspace-level LLM pricing overrides and inspect inherited project and platform prices.

* **Navigation**: Settings > AI Configuration > Model Pricing
* **Required role**: Owner or Admin

The page shows four summary counts: **Pricing rows**, **Workspace overrides**, **Project overrides**, and **Platform defaults**.

**Add a workspace pricing override:**

1. Go to **Settings > AI Configuration > Model Pricing**.
2. Click **+ Add pricing**.
3. In the **Add workspace pricing** dialog, enter:

| Field | Description |
| - | - |
| **Provider** *(required)* | The LLM provider, for example `openai`. |
| **Model ID** *(required)* | The model identifier, for example `gpt-5-mini`. |
| **Input price** *(required)* | Price per unit of input tokens. |
| **Output price** *(required)* | Price per unit of output tokens. |
| **Cache read price** *(optional)* | Price per unit for cached-input reads. |
| **Cache write price** *(optional)* | Price per unit for writing to the cache. |
| **Reasoning output price** *(optional)* | Price per unit for reasoning-token output, for models that bill reasoning separately. |
| **Currency** | The currency for all prices on this row. Default: USD. |
| **Effective from** *(required)* | The date this pricing override takes effect. |
| **Effective to** *(optional)* | The date this pricing override stops applying. Leave blank for no end date. |
| **Active override** | Whether this row is used during cost resolution. Inactive rows are retained for history but skipped during resolution. |
| **Notes** *(optional)* | Free-text context, for example a commercial source, approval note, or pricing tier. |

4. Click **Save pricing**.

Workspace overrides apply to every project unless a project-specific override exists.

**Import workspace pricing:**

Use **Import** to bulk-load effective-dated pricing rows, previewing them before committing.

1. Go to **Settings > AI Configuration > Model Pricing**.
2. Click **Import**.
3. In the **Import workspace pricing** dialog, provide the rows either by:
   * Clicking **Choose File** to upload a **CSV or JSON file**, or
   * Pasting JSON rows or CSV with headers directly into **Import content**.
4. Optionally, check **Allow overlapping windows** to permit pricing rows with overlapping effective-date ranges. \[!WARNING] Overlapping rows can make effective-price resolution depend on the latest start date.
5. Click **Preview import** to validate the rows before committing.
6. Click **Commit import** to apply the previewed rows as workspace overrides.

Use **Refresh** to reload the page's counts and rows from the latest data.

***

## Arch

Arch is the AI Architect component of the Agent Platform. It manages the model and credentials used for agent specification generation and chat-based orchestration.

* **Navigation**: Settings > AI Configuration > Arch
* **Required role**: Owner or Admin

The page is organized into two tabs: **Settings** and **Audit Logs**.

### Settings

**Current source:**

The **Current Source** banner displays the active credential source and the model that Arch is using, for example `Model Hub · OpenAI · gpt-5.2`.

**Credential source:**

Choose how Arch authenticates with the LLM provider:

| Option | Description |
| - | - |
| Platform Credits | Use platform-provided API credits. Select which model to use in the Settings tab. |
| Model Hub | Use a model that's configured with credentials in your Model Hub. |

> [!NOTE]
>
> Arch works best with models that support tool calling and have large context windows.

**Select model:**

Select the model Arch uses from the dropdown. The selected model displays its provider, model ID, capability tags, and tier. If the model hasn't been tested with Arch, a warning appears.

**Parameters:**

Fine-tune generation behavior for chat and spec generation:

| Parameter | Description | Default |
| - | - | - |
| Reasoning Effort | Controls how much reasoning the model applies before responding. Slide between none and high. | Low |
| Verbosity | Controls the length and detail of generated responses. Slide between low and high. | Medium |
| Max completion tokens | Maximum tokens Arch can generate per response. | 6,000 |
| Compaction Threshold | Auto-compaction condenses earlier conversation content once context usage reaches the **Compaction Threshold**, so long-running sessions don't exhaust the model's context window. | |

Click **Save Changes** to apply updates.

### Audit logs

The **Audit Logs** tab shows Arch session activity for the selected time range, including cost, error count, and a browsable session list.

**Summary metrics:**

| Metric | Description |
| - | - |
| Sessions (24h) | Number of Arch sessions in the last 24 hours. |
| Total Cost (24h) | Estimated cost of Arch sessions in the last 24 hours. |
| Errors (24h) | Number of sessions that encountered errors in the last 24 hours. |
| Listed Sessions | Total number of sessions shown in the current session list. |

**Sessions list:**

The list displays all Arch sessions. Use **Has Errors** to show only sessions with errors, or **Today** to show only today's sessions. Each session row shows the session ID, timestamp, number of turns, and current phase. Click a session to view the full execution flow in the detail panel.

### Traces

Use the **Traces** tab on the **Arch** page to inspect execution traces from Arch AI sessions. Traces appear after Arch AI runs an execution with tracing enabled. Until then, the **Sessions** panel shows **No traces yet**.

**Navigation**: **Settings** → **Arch** → **Traces**

The summary cards at the top of the tab show the following:

| Card | Description |
| - | - |
| **Sessions (24h)** | Number of Arch AI sessions in the last 24 hours. |
| **Total Cost (24h)** | Total cost of Arch AI sessions in the last 24 hours. |
| **Errors (24h)** | Number of errors in the last 24 hours. |
| **Listed Sessions** | Number of sessions that match the current filters. |

Use the filters to narrow the session list:

| Filter | Description |
| - | :- |
| **Project** | Limits sessions to a single project. Default: **All projects**. |
| **Time range** | Limits sessions to a time window. Default: **Last 24h**. |
| **Phase** | Limits sessions to a phase of the Arch AI workflow: **Interview**, **Blueprint**, or **Build**. Default: **Any phase**. |

The Traces view has three panels:

| Panel | Description |
| :- | :- |
| **Sessions** | Lists the sessions that match the current filters. Select **Refresh** to reload the list. |
| **Select a session** | Shows the execution tree for the session you select. |
| **Select a span** | Shows the metadata and payload references for the node you select in the trace tree. |

***

## Voice services

Voice Services manages credentials for speech-to-text (STT) and text-to-speech (TTS) providers that power voice-enabled agent interactions.

* **Navigation**: Settings > AI Configuration > Voice Services
* **Required role**: Owner or Admin

> [!NOTE]
>
> Voice testing requires at least one STT (ASR) provider and one TTS provider configured; any supported provider combination works. For Realtime Voice, configure a realtime model (S2S).

### Configure a provider

1. Go to **Settings** > **AI Configuration** > **Voice Services**.
2. Find the provider you want to configure and click **Configure**.
3. Enter the provider credentials in the configuration dialog.
4. Click **Save**.

Configuration fields vary by provider. The following table shows an example for Google Cloud Speech:

| Field | Description |
| - | - |
| Display Name | A label to identify this credential set, for example *Google Cloud Speech Credentials*. |
| Service Account JSON | Paste the full Google service-account JSON used for Speech-to-Text. |
| STT Model ID | Optional. The Google STT model to use, for example `chirp_3`, `chirp`, `latest_long`, `telephony`. Default: `chirp_3`. |

### Bring your own custom speech providers

Tenant-scoped custom STT/TTS adapters available to voice pipeline channels. Use this when you want to host your own speech recognition or synthesis adapter instead of a built-in provider. You write and run the adapter; the platform routes call audio to it.

> [!WARNING]
>
> Caller audio and transcripts are sent to the endpoints you configure below. Only register endpoints you trust.

**Add a BYO speech provider:**

1. Go to **Settings** > **AI Configuration** > **Voice Services** > **BYO custom speech providers**.
2. Click **+ Add provider**.
3. Enter the provider details:

| Field | Description |
| - | - |
| Display Name | A label to identify this provider, for example *Acme Speech*. |
| Provider slug | A short identifier for the provider. |
| API key | One key for the whole provider. KoreVG sends it as a Bearer token to every enabled endpoint. Encrypted at rest. |

4. Configure the **Speech-to-text (ASR)** and/or **Text-to-speech** adapters (see below).
5. Click **Save**.

> [!NOTE]
>
> Use the **Adapter contract** panel to open the STT or TTS contract while filling in URLs, so you can see what your adapter needs to implement.

**Speech-to-text · ASR**

Streaming recognizer endpoint and optional picker metadata. Toggle **Enabled** to make the adapter available.

| Field | Description |
| - | - |
| STT WebSocket endpoint | The public `wss://` endpoint for your streaming recognizer, for example `wss://speech.example.com/stt`. Private IP ranges are blocked server-side. |
| Languages *(optional, Studio only)* | Languages your adapter supports, for the Studio language picker. Select **+ Add** to add more. |
| STT options (JSON) | Provider-specific options forwarded to your adapter verbatim, for example `{"model":"nova-2","endpointing":300}`. |

**Text-to-speech**

Streaming synthesis endpoint, languages, voices, and options. Toggle **Enabled** to make the adapter available.

| Field | Description |
| - | - |
| TTS streaming WebSocket endpoint | The public `wss://` endpoint for your streaming synthesizer, for example `wss://speech.example.com/tts`. Streaming is the only supported TTS path - batch HTTP TTS is not supported. |
| Languages *(optional, Studio only)* | Languages your adapter supports, for the Studio language picker. Select **+ Add** to add more. |
| Voices *(optional, Studio only)* | Voices your adapter supports, for the Studio voice picker. Select **+ Add** to add more. |
| TTS options (JSON) | Provider-specific options forwarded to your adapter verbatim, for example `{"model":"v2","style":"narration"}`. |

> [!NOTE]
>
> Options entered in the JSON fields are forwarded to your adapter as-is - the adapter decides what they mean.

After saving, verify the adapter with a test call. A registered credential isn't proof the adapter works.

***

## Guardrails

Guardrails provide content safety controls for your workspace and projects. Workspace administrators can configure guardrail providers and their available scanners, while guardrail policies are configured at the project level to evaluate agent inputs and outputs against defined safety rules.

* **Navigation**: Settings > AI Configuration > Guardrails

* **Required role**: Owner or Admin

The page contains two sections: **[Guardrail Providers](#guardrail-providers)** and **[Guardrail Policies](#guardrail-policies)**.

### Guardrail providers

Guardrail providers are the evaluation services that assess content against your policies. Workspace administrators can add and configure guardrail providers for use across projects. Configure at least one provider before creating policies.

Project authors can select which configured providers the project can use. For more information, see [Select guardrail providers](https://koreai.mintlify.site/agent-platform/safety-and-guardrails.md#select-guardrail-providers).

**Add a provider:**

1. Go to **Settings > AI Configuration > Guardrails**.
2. Click **Add Provider**.
3. In the dialog, configure the provider using the **Form** or **YAML** tab.
4. Click **Add Provider** to save.

**Form tab fields:**

| Field | Description |
| - | - |
| Name | A unique internal identifier for the guardrail provider, for example *OpenAI Moderation*. |
| Display Name | A human-readable label, for example *Content Safety (OpenAI)*. |
| Adapter Type | The integration type for the guardrail provider, such as OpenAI Moderation or Self-hosted / Gateway (OpenAI-compatible). |
| Response format | Available when Self-hosted / Gateway (OpenAI-compatible) is selected. Specifies how the provider response is interpreted: Llama Guard (safe / unsafe + scores), Qwen3Guard (Safety / Categories / Refusal), or Generic classifier (platform prompt → safe / unsafe). |
| Endpoint URL | The provider API endpoint URL. |
| Model | The model used for guardrail evaluation. |
| Authentication | Enable authentication for the provider. Use an Auth Profile for providers that require credentials. Raw API keys aren't accepted. |
| Default Category | The default content category evaluated by the provider. |
| Default Threshold | Sensitivity threshold from 0.0 to 1.0. Default: 0.7. Lower values flag more content; higher values flag only high-confidence violations. |
| Circuit Breaker | Configure failure handling. **Max Failures** sets the number of consecutive provider failures that activates the circuit breaker; **Reset Timeout** sets the time, in milliseconds, before the platform attempts to recover the provider. |
| Retry Configuration | Configure retry behavior. **Max Retries** sets the maximum number of retry attempts when a provider request fails; **Backoff Strategy** sets the delay, in milliseconds, between retry attempts. |
| Enabled | Enable the provider for guardrail evaluation. |
| Synthetic health checks | Enable periodic health checks for the provider using its configured credentials. |

**Configure scanners**

After adding a guardrail provider, workspace administrators can configure the scanners available for that provider.

1. In **Guardrail Providers**, find the provider you want to configure.
2. Click **Scanners** in the provider's **Actions** column.
3. In the **Scanners** panel:
   * Add scanners as needed.
   * Enable or disable individual scanners.
   * Set the threshold for each scanner. A lower threshold is stricter and causes the scanner to trip sooner.
4. Click **Save scanners**.

**Provider health monitoring:**

The platform periodically checks provider health. When a provider becomes unhealthy, its circuit breaker activates. After repeated failures, the circuit breaker opens and stops sending requests. After the reset timeout, it allows a test request through.

When a provider's circuit breaker is open, the platform follows the configured fail mode:

* **Fail-open** - Content is delivered without guardrail evaluation. Violations may go undetected.
* **Fail-closed** - Content is blocked until the provider recovers. Safer, but may interrupt service.

### Guardrail policies

The **Guardrail Policies** section displays the policies configured for a selected project. Select a project from the **Project** dropdown to view its guardrail policies.

Policies are configured at the project level and attached to guardrail providers. For information about creating and configuring guardrail policies, see [Guardrail policies](https://koreai.mintlify.site/agent-platform/safety-and-guardrails.md#guardrail-policies).

***

## Auth profiles

Auth profiles store authentication configurations that agent tools use to call external services securely. Profiles are managed centrally at the workspace level and reused across all projects.

* **Navigation**: Settings > AI Configuration > Auth Profiles
* **Required role**: Owner or Admin

The page displays auth profiles by deployment environment. Use the **Default**, **Dev**, **Staging**, and **Production** tabs to view and manage profiles for each environment.

### Add auth profiles

Click **Add Profile**. Two profile types are available:

| Type | Description |
| - | - |
| Custom Profile | Configure a custom authentication scheme with manually specified credentials and settings. |
| Integration Profile | Configure authentication for a supported third-party integration. For a list of available integrations, see [Integrations](https://koreai.mintlify.site/agent-platform/integrations.md#actions-and-triggers-integrations). |

### Supported auth types

Auth types are organized into four categories.

**Basic authentication**

| Type | Description |
| :- | :- |
| API Key | Static API key sent via header or query parameter. |
| Bearer Token | Static bearer token in Authorization header. |
| Basic Auth | HTTP Basic authentication with username and password. |
| Custom Header | Send one or more custom auth headers. |

**OAuth 2.0**

| Type | Description |
| :- | :- |
| OAuth 2.0 App | Authorization code OAuth with PKCE and metadata discovery support. |
| Client Credentials | Machine-to-machine OAuth via client credentials grant. |
| Password Credentials (ROPC) | Legacy OAuth 2.0 Resource Owner Password Credentials (ROPC) flow. Use only when the provider requires resource-owner credentials. |

**Advanced**

| Type | Description |
| :- | :- |
| Custom Authentication | Describes a provider's authentication scheme when no built-in type fits. |
| AWS IAM (SigV4) | Signs requests with AWS Signature Version 4. |
| Azure AD | Authenticates through Microsoft Entra ID (Azure Active Directory) for enterprise single sign-on (SSO). |
| Kerberos-SPNEGO Auth | Authenticates enterprise systems with SPNEGO/Kerberos. |
| SAML | Uses a SAML assertion-based authentication flow. |
| WS-Security | Authenticates SOAP services with a WS-Security UsernameToken or certificate. |
| GCP Workload Identity Federation | Gives keyless access to Google Cloud services using short-lived tokens. |
| GCP Service Account Key | Exchanges a Google service-account key for short-lived access tokens. |

**Transport security**

| Type | Description |
| :- | :- |
| mTLS | Mutual TLS with client certificate and private key. |

Auth profile credentials are encrypted at rest and never exposed in logs or agent responses.

> [!NOTE]
>
> Guardrail providers that require credentials must reference an auth profile. Raw API keys are not accepted directly in the guardrail provider configuration.

### Use auth profiles

Once created, reference an auth profile by name in tool configurations and guardrail provider settings. The platform resolves the profile at runtime and injects the correct credentials without exposing them in agent definitions, logs, or traces.

When a tool runs in the Default, Dev, Staging, or Production environment, the platform resolves the auth profile configured for that environment.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.