Skip to main content

Documentation Index

Fetch the complete documentation index at: https://koreai.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Configure authentication, encryption, service integrations, data retention, and domain access for your AI for Work account.
FeatureDescription
Single Sign-On (SSO)Authenticate users through an external Identity Provider using SAML, WS-Federation, or OpenID Connect
Service AccountsConnect to Google, Azure, or LDAP directories for user and group management
Enterprise EncryptionUse platform-managed keys or bring your own encryption key (BYOK)
Data SettingsControl what conversation data is stored and how long it is retained
Domain ManagementAdd and verify company and partner domains for controlled account access
Personal API KeyGenerate and use a personal API key to authenticate API requests

Single Sign-On (SSO)

SSO lets users authenticate through an external Identity Provider (IdP) instead of the default sign-in flow. Only account admins can enable or disable SSO.
ProtocolProviders
SAMLOkta, OneLogin, Bitium, Other
WS-FederationWindows Azure, Other (ADFS)
OpenID Connect (OIDC)Google, Microsoft Azure

Enable SSO

  1. Go to Admin Console > Security > Single Sign-On.
  2. Turn on the Enable SSO toggle.
  3. Select a sign-on protocol.
  4. Select your identity provider and enter the configuration details.
  5. Click Save.

SAML

SAML uses signed XML tokens to authenticate users. The IdP authenticates the user and sends a signed response; the platform validates it using the certificate and grants access.

Okta

Configuration fields:
FieldDescriptionRequired
Okta Single Sign-On URLSSO endpoint for SP-initiated flowYes
Identity Provider IssuerEntity URL of the authenticating IdPYes
CertificatePublic certificate to validate user signatures (max 2)Yes
ACS URL for SP-Initiated SAML FlowAuto-generated redirect URLRead only
ACS URL for IDP-Initiated SAML FlowAuto-generated account-specific URLRead only
Configure Okta:
  1. Log in to the Okta Admin Dashboard.
  2. Go to Applications > Add Application > Create Application.
  3. Enter an App Name and click Next.
  4. Under Configure SAML, paste the ACS URL for SP-Initiated SAML Flow from the platform into the Okta Single Sign-On URL field.
    • For on-premise accounts, use https://idproxy-dev.<platform>.com/authorize/callback as the SSO URL and https://idproxy-dev.<platform>.com as the Audience URL.
  5. Click Finish.
  6. On the Sign On tab, click View Setup Instructions and copy:
    • Identity Provider Single Sign-On URLOkta Single Sign-On URL on the platform
    • Identity Provider IssuerIdentity Provider Issuer on the platform
    • X.509 CertificateCertificate on the platform
  7. Click Save.

OneLogin

Configuration fields:
FieldDescriptionRequired
SAML 2.0 EndpointHTTP SSO endpoint for SP-initiated flowYes
Issuer URLOneLogin issuer URLYes
X.509 CertificatePublic certificate to validate user signatures (max 2)Yes
ACS URL for SP-Initiated SAML FlowAuto-generated redirect URLRead only
ACS URL for IDP-Initiated SAML FlowAuto-generated account-specific URLRead only
Configure OneLogin:
  1. In the OneLogin Portal, go to Applications > Add Apps, search for your app, and save it.
  2. On the SSO tab, copy:
    • OneLogin SAML 2.0 Endpoint (HTTP)SAML 2.0 Endpoint on the platform
    • OneLogin Issuer URLIssuer URL on the platform
  3. Click View Details on the X.509 Certificate field. Copy the certificate data (between the header and footer lines) and paste it into the X.509 Certificate field on the platform.
  4. Copy the ACS URL for SP-Initiated SAML Flow and ACS URL for IDP-Initiated SAML Flow from the platform and paste them into the corresponding fields in OneLogin.
  5. Click Save in both the platform and OneLogin.

Bitium

Configuration fields:
FieldDescriptionRequired
Single Sign-On URLHTTP SSO endpoint for SP-initiated flowYes
Issuer URLBitium issuer URLYes
CertificatePublic certificate to validate user signatures (max 2)Yes
ACS URL for SP-Initiated SAML FlowAuto-generated redirect URLRead only
ACS URL for IDP-Initiated SAML FlowAuto-generated account-specific URLRead only
Configure Bitium:
  1. In Bitium, go to Manage Organization > Manage Apps > App.
  2. On the Single Sign-On tab, select SAML Authentication.
  3. Copy:
    • Bitium Login URLSingle Sign-On URL on the platform
    • Bitium Logout URLIssuer URL on the platform
    • X.509 CertificateCertificate on the platform
  4. Click Save.

Other SAML Providers

Use this option for any SAML 2.0-compliant provider not listed above. Configuration fields:
FieldDescriptionRequired
Single Sign-On URLHTTP SSO endpoint for SP-initiated flowYes
Issuer URLIdP issuer URLYes
CertificatePublic certificate to validate user signatures (max 2)Yes
ACS URL for SP-Initiated SAML FlowAuto-generated redirect URLRead only
ACS URL for IDP-Initiated SAML FlowAuto-generated account-specific URLRead only
Fetch the SSO parameters from your IdP portal, paste them into the platform, then copy the ACS URLs from the platform back into your IdP app settings.
When multiple certificates are added, the platform uses the most recent valid certificate. If it’s invalid, it falls back to the other certificate.

WS-Federation

WS-Federation uses signed security tokens to authenticate users across security domains. Commonly used with Active Directory Federation Services (ADFS).

Windows Azure

Configuration fields:
FieldDescriptionRequired
Azure AD Sign-On Endpoint URLWS-Federation passive endpoint for sign-on/sign-off (e.g., https://login.microsoftonline.com/<tenant-id>/wsfed)Yes
Azure AD Federation Metadata DocumentURL for the Azure federation metadata XML document (e.g., https://login.microsoftonline.com/<tenant-id>/FederationMetadata/2007-06/FederationMetadata.xml)Yes
Configure Windows Azure:
  1. Log in to the Azure Portal and go to Microsoft Entra ID > Enterprise Applications > New Application > Create your own application.
  2. Enter the application name and click Create.
  3. Go to Single sign-on and select WS-Fed.
  4. Configure the Identifier (Entity ID) and Reply URL provided by the platform.
  5. Go to Users and Groups and assign users or groups.
  6. Go to App Registrations > Endpoints and copy:
    • WS-Federation Sign-On EndpointAzure AD Sign-On Endpoint URL on the platform
    • Federation Metadata Document URL → Azure AD Federation Metadata Document on the platform
  7. Click Save.

Other WS-Federation Providers (ADFS)

Configuration fields:
FieldDescriptionRequired
AD Sign-On Endpoint URLWS-Federation passive endpoint (e.g., https://adfs.yourcompany.com/adfs/ls/)Yes
AD Federation Metadata Document URLURL for the ADFS federation metadata XML (e.g., https://adfs.yourcompany.com/FederationMetadata/2007-06/FederationMetadata.xml)Yes
Configure ADFS:
  1. Open ADFS Management on your ADFS server. Right-click Relying Party Trusts and select Add Relying Party Trust.
  2. Choose Enter data about the relying party manually and click Next.
  3. Select AD FS profile and skip certificate configuration.
  4. Enable WS-Federation Passive protocol and enter the Relying Party WS-Federation Passive protocol URL provided by the platform.
  5. Enter the relying party trust identifier provided by the platform.
  6. In Edit Claim Rules, click Add Rule, select Send LDAP Attributes as Claims, and map:
    • E-Mail-Addresses → E-Mail Address
    • Given-Name → Given Name
    • Surname → Surname
    • User-Principal-Name → UPN
  7. Add another rule: select Transform an Incoming Claim, set Incoming claim type to E-Mail Address, Outgoing claim type to Name ID, and Outgoing name ID format to Email.
  8. In Service > Endpoints, copy:
    • WS-Federation Passive Endpoint (/adfs/ls/) → AD Sign-On Endpoint URL on the platform
    • Federation Metadata URL → AD Federation Metadata Document URL on the platform
  9. Click Save.

OpenID Connect (OIDC)

OIDC is an authentication layer on top of OAuth 2.0 that supports identity verification and user profile access. Supported providers are Google and Microsoft Azure.

Google

Configuration fields:
FieldDescriptionRequired
Client EmailService account email from your Google Cloud JSON key fileYes
Admin EmailGoogle Workspace administrator emailYes
Private KeyPrivate key from your Google service account JSON fileYes
Configure Google:
  1. Log in to Google Cloud Console.
  2. Go to IAM & Admin > Service Accounts > Create Service Account. Enter a name, click Create and Continue, then Done.
  3. Click the service account → Keys > Add Key > Create New Key → select JSONCreate. Save the downloaded file securely.
  4. In the service account details, enable Google Workspace Domain-wide Delegation and note the Client ID.
  5. Log in to Google Admin Console.
  6. Go to Security > API Controls > Domain-wide Delegation > Add new.
  7. Enter the Client ID and add the following OAuth scopes as a comma-separated list:
    • https://www.googleapis.com/auth/admin.directory.user.readonly
    • https://www.googleapis.com/auth/admin.directory.group.readonly
    • https://www.googleapis.com/auth/admin.directory.orgunit.readonly
    • https://www.googleapis.com/auth/admin.directory.domain.readonly
  8. Click Authorize.
  9. In the platform, select Sign in with Google, enable Configure service account for your G-Suite domain, and enter the values from the JSON key file:
    • client_emailClient Email
    • private_keyPrivate Key
    • Admin email → Admin Email
  10. Click Save.

Microsoft Azure

Configuration fields:
FieldDescriptionRequired
Client IDApplication (client) ID from your Azure app registrationYes
Tenant IDDirectory (tenant) ID from your Azure app registrationYes
Client SecretClient secret value from your Azure app registrationYes
Redirect URLAuto-generated — copy this to use when registering your Entra ID appRead only
Configure Microsoft Azure:
  1. Log in to the Azure Portal and go to Microsoft Entra ID > App Registrations > New Registration.
  2. Enter an application name and add the Redirect URL from the platform as the redirect URI. Click Register.
  3. Under Authentication, enable ID Tokens under Implicit grant and hybrid flows.
  4. Under Certificates & Secrets, create a new client secret. Copy the Value immediately — it is shown only once.
  5. Under API Permissions, add Microsoft Graph delegated permissions: User.Read, email, openid, profile. Click Grant Admin Consent.
  6. From the app Overview page, copy the Application (client) ID and Directory (tenant) ID.
  7. In the platform, select Microsoft Azure, enter the credentials, and click Save.

Service Accounts

Service accounts connect the platform to external identity providers to access user directories, groups, and organizational data. You can configure multiple accounts and designate one as the default for system-wide operations. Go to Admin Console > Security > Connections > Service Account. Supported providers:
ProviderUse Case
GoogleConnect to Google Workspace for user and group management
Microsoft AzureIntegrate with Azure Active Directory
LDAPConnect to on-premises directory services
OktaConnect to Okta for user and group management

Add a Service Account

Click the provider type to open the configuration form.

Google

Before configuring, complete the Google Cloud setup (see Configure Google under OIDC for the required service account and domain delegation steps).
FieldDescription
Account NameA descriptive name for this service account
Client EmailService account email from the Google Cloud JSON key file
Admin EmailGoogle Workspace administrator email
Private KeyComplete private key from the JSON key file (including BEGIN and END markers)
Click Save.

Microsoft Azure

Before configuring, complete the Azure app registration (see Configure Microsoft Azure under OIDC, or follow the steps below).
FieldDescription
Account NameA descriptive name for this service account
Client IDApplication (client) ID from your Azure app registration
Tenant IDDirectory (tenant) ID from your Azure app registration
Client SecretClient secret value from your Azure app registration
Click Save. Required Microsoft Graph permissions (Application permissions, not Delegated):
PermissionPurposeRequired
User.Read.AllRead user profile attributesYes
Group.Read.AllRead group metadata and membershipYes
Directory.Read.AllTraverse directory relationshipsYes
AuditLog.Read.AllDetect group membership changes via audit logsYes
People.Read.AllSearch for people by name via People APIOptional
GroupMember.Read.AllEnumerate group members directlyOptional
User.ReadBasic.AllRetrieve basic user identity fieldsOptional
After adding permissions, click Grant Admin Consent in the Azure Portal. Azure app registration steps:
  1. Log in to the Azure Portal and search for App Registrations.
  2. Click New Registration, enter an application name, select the tenant type (Single or Multi-tenant), and click Register.
  3. Go to API Permissions > Add a Permission > Microsoft Graph > Application Permissions and add the required permissions above.
  4. Click Grant Admin Consent for [Your Organization].
  5. Go to Certificates & Secrets > New Client Secret. Select an expiration period and click Add. Copy the Value immediately.
  6. From the app Overview, copy the Application (client) ID and Directory (tenant) ID.
Set calendar reminders to rotate client secrets before they expire — 30 days before to plan, 7 days before to create and test a new secret, and 2 days before to update production.

LDAP

FieldDescription
Account NameA descriptive name for this service account
URLLDAP server URL
Base DNBase distinguished name for directory searches
Authentication TypeLDAP authentication method
Person FilterLDAP filter to identify user objects
Group FilterLDAP filter to identify group objects
Click Save.

Okta

FieldDescription
Account NameA descriptive name for this service account
Okta DomainYour Okta domain URL (for example, https://your-domain.okta.com)
Admin API TokenAdmin API token generated from the Okta Admin Console (masked input)
All fields are required. The platform validates the Okta Domain format and tests the credentials through the Okta API before saving.
  • If the credentials are valid, the service account saves successfully.
  • If the credentials are invalid, the platform displays an error message and does not save the account.
Error messages display for invalid credentials, network or API failures, expired API tokens, and expired service accounts. Click Save.

Manage Service Accounts

Click the three-dot menu next to any service account to access these options:
ActionDescription
EditUpdate configuration fields and save changes
Set as DefaultDesignate this account for system-wide operations (e.g., user suggestions during account invitations). Only one account can be the default at a time.
DeletePermanently remove the service account
You cannot delete a service account linked to active user enrollment. The platform displays a warning if you attempt this.

Enterprise Encryption

All account data is encrypted by default. You can use the platform-managed default key or bring your own encryption key (BYOK) for full organizational control. Go to Admin Console > Enterprise Encryption.

Default Key

The platform automatically manages encryption — no configuration required. You can:
  • Copy — Copy the current key to your clipboard.
  • Refresh — Generate a new default key.
Default key actions are disabled once BYOK is activated.

Bring Your Own Key (BYOK)

BYOK lets you use your own Customer Master Keys (CMKs) from AWS KMS or Azure Key Vault for all encryption operations. The platform communicates with your external KMS for cryptographic operations. Supported providers: AWS KMS, Azure Key Vault
BYOK is permanent. Once activated, you cannot revert to the default key, and the configuration cannot be modified. Contact Kore.ai support if changes are needed.

Configure BYOK

  1. Go to Admin Console > Enterprise Encryption.
  2. Under Bring Your Own Key, click Create Key.
  3. Select your cloud provider (AWS or Azure).
  4. Note the pre-populated values shown by the platform — these are required when configuring your cloud provider.
  5. Enter the required identifiers (see provider sections below).
  6. Click Test Connection to validate key access and permissions.
  7. Click Next, then Proceed to activate.

AWS KMS

For detailed guidance on AWS KMS, refer to the AWS KMS Developer Guide. Values the platform provides: When you initiate the BYOK setup, the platform displays these values for you to copy. You will need them when configuring your IAM role.
ValueHow It’s Used
Service Role ARNAdd to your IAM role trust policy so the platform can assume the role
External IDAdd to your IAM role trust policy to securely restrict who can assume the role
Values you provide:
FieldDescription
Key ARNYour KMS Customer Managed Key ARN (e.g., arn:aws:kms:<region>:<account-id>:key/<key-id>)
Assume Role ARNThe IAM role ARN you create for the platform (e.g., arn:aws:iam::<account-id>:role/<role-name>)
AWS setup steps:
  1. Locate your Customer Managed Key (CMK) ARN. The platform uses this key for all encryption operations. In the AWS KMS console, open your CMK’s details page and copy the CMK ARN (e.g., arn:aws:kms:<region>:<account-id>:key/<key-id>).
  2. Create an IAM role for the platform. This role allows the platform to securely access your KMS key without sharing credentials. Go to IAM > Roles > Create Role, select Another AWS account, enter the Service Role ARN provided by the platform, and name the role (e.g., AIforWorkByokAccessRole). Note the Role ARN after creation.
  3. Configure the trust policy on the role. The trust policy restricts who can assume this role. By specifying the platform’s Service Role ARN and the External ID, you ensure that only the platform’s verified service can use it. Go to IAM > Roles > Your role > Trust Relationships > Edit Trust Policy and set the following (replace placeholders with actual values):
    {
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Principal": { "AWS": "<Service-Role-ARN>" },
        "Action": "sts:AssumeRole",
        "Condition": { "StringEquals": { "sts:ExternalId": "<External-ID>" } }
      }]
    }
    
  4. Create and attach a permissions policy. This policy defines which KMS actions the role is allowed to perform on your key. Go to IAM > Policies > Create Policy > JSON and add the following:
    {
      "Version": "2012-10-17",
      "Statement": [{
        "Sid": "AllowKMSActions",
        "Effect": "Allow",
        "Action": ["kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey"],
        "Resource": "<your-cmk-arn>"
      }]
    }
    
    Name the policy (e.g., AIKMSPolicy), create it, then attach it to the role via IAM > Roles > Your role > Add Permissions > Attach Policies.
  5. Grant the IAM role access in the CMK key policy. This authorizes the role to perform cryptographic operations on the key from the KMS side. In the KMS console, select your CMK, go to the Key Policy tab, switch to edit mode, and add the following statement to the existing policy’s Statement array:
    {
      "Sid": "AllowAIAccess",
      "Effect": "Allow",
      "Principal": { "AWS": "<your-role-arn>" },
      "Action": ["kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey"],
      "Resource": "*"
    }
    
  6. Validate the configuration (optional). Run the following AWS CLI commands to verify that your IAM role and CMK key policy are set up correctly. This step does not validate the full BYOK integration.
    aws sts assume-role \
      --role-arn arn:aws:iam::<your-account-id>:role/<role-name> \
      --role-session-name test-session
    
    aws kms describe-key \
      --key-id <your-cmk-arn> \
      --region <your-region>
    
  7. Share your details with Kore.ai. Contact Support and provide your CMK ARN (from step 1) and Role ARN (from step 2). The team will configure the service side to assume the role and securely access your KMS key. Once this is done, the BYOK configuration and test connection will complete successfully.

Azure Key Vault

For detailed guidance on Azure Key Vault, refer to the Azure Key Vault documentation. Values the platform provides: When you initiate the BYOK setup, the platform displays these values for you to copy. You will need them when granting access to the platform’s service principal.
ValueHow It’s Used
Client IDIdentifies the platform’s application when granting Key Vault access
App NameThe platform’s registered application name, used to search for the service principal in role assignments
Values you provide:
FieldDescription
Key Vault URLYour Azure Key Vault URI (e.g., https://<vault-name>.vault.azure.net/)
Tenant IDYour Azure Directory (tenant) ID
Azure setup steps:
  1. Authorize the platform in your Azure tenant. This step registers the platform as a service principal in your tenant, allowing it to interact with your Key Vault securely. Sign in to the Azure portal as a Global Administrator and grant admin consent for the platform’s application using one of:
    • Admin Consent URL: Navigate to https://login.microsoftonline.com/<your-tenant-id>/adminconsent?client_id=<platform-client-id> (replace <your-tenant-id> with your tenant ID, found in Microsoft Entra ID > Properties).
    • Azure CLI: Run az ad sp create --id '<platform-client-id>' (replace <platform-client-id> with the Client ID provided by the platform).
  2. Prepare your Key Vault and encryption key. Ensure you have a Key Vault and an RSA key in your Azure subscription. Note the following details, which you will share with the team:
    • Key Vault URI (e.g., https://<vault-name>.vault.azure.net/)
    • Key Name for the specific key the platform will use
  3. Grant the platform access to your Key Vault. This authorizes the platform’s service principal to perform the cryptographic operations required for BYOK. In your Key Vault, go to Access Control (IAM) > Add Role Assignment and assign the following roles to the platform’s service principal (search by the App Name or Client ID provided by the platform):
    • Key Vault Crypto User — allows cryptographic operations like wrapping and unwrapping keys, required for BYOK functionality
    • Key Vault Reader — allows reading metadata about the Key Vault and its resources
  4. Share your details with Kore.ai. Contact Support and provide: your Tenant ID (found in Microsoft Entra ID > Properties), the Key Vault URI, and the Key Name.
  5. Approve the private endpoint connection. After the team configures the connection on their end, a private endpoint request will appear in your Key Vault. Go to Key Vault > Networking > Private Endpoint Connections, find the pending request, and approve it. This establishes a secure private link between the platform and your Key Vault.

Data Settings

Control what conversation data is stored and how long it is retained. Go to Admin Console > Security > Data Settings.

Conversation Data Storage

OptionWhat Is Stored
Store full conversation dataComplete records: questions, responses, and context
Do not store full conversation dataMetadata only: timestamps, user IDs, and technical details
When Do not store full conversation data is selected, apply the policy at one of three levels:
LevelScope
All AgentsNo-storage policy applies to all agents
All Agents Except SelectedAll agents use no-storage by default; selected agents retain full data
Only Selected AgentsNo-storage policy applies only to designated agents

Data Retention Period

OptionDescription
Default (7 years)Data is automatically deleted after 7 years
CustomSet a specific retention duration before automatic deletion

Domain Management

Add and verify company and partner domains to enable controlled account access via SSO. Go to Admin Console > Security > Domain Management.

Domain Types

TypeDescription
Company DomainDomains owned by your organization
Partner DomainExternal domains used by trusted partners, vendors, or collaborators

Add a Domain

  1. Click Add New.
  2. Select the domain type (Company or Partner).
  3. Enter the domain details and submit for verification.
  4. Verified domains are added to the account. Rejected domains remain listed with a Rejected status.

Access Rules

RuleCompany Domain UsersPartner Domain Users
SSO enrollment accessYes, when domain-based enrollment is enabledNo, even when domain enrollment is enabled
Multiple accountsRestricted to one tenantCan access multiple tenants
Account accessAutomatic once domain enrollment is configuredBy explicit invitation only
Label in User ManagementShown with a Partner label

Switching Accounts (Partner Users)

Partner domain users with access to multiple accounts can switch between them by clicking the profile icon in the top-right corner and selecting Switch Account. This option is available from both the Admin Console and the application UI.

Personal API Key

A personal API key identifies and authorizes users for API access, replacing username and password credentials in each request. To generate your key, go to My Profile — accessible via the profile icon in the lower-left of the Admin Console or the upper-right corner of the application homepage — then open the Personal API Key section and click to generate.

Manage Your Key

ActionDescription
CopyCopy the key for immediate use
RegenerateGenerate a new key, replacing the current one
DeleteRemove the key when no longer needed

Authenticate API Requests

Include the key in the auth header of every API request:
--header 'auth: {{Admin's Personalkey}}'