LLM Configuration Management
The LLM Configuration Management module in Robility Manager provides a centralized way for Tenant Administrators to configure and manage AI/LLM providers for use across the tenant.
It provides a controlled connection between configured AI providers and AI-enabled capabilities in Robility Flow. Once an LLM configuration is created, supported components can use the configuration without requiring users to enter or access the underlying provider credentials.
Supported AI Providers
Robility Manager supports integration with the following AI providers:
1. Azure OpenAI
2. OpenAI
3. Anthropic
4. Google Vertex AI
5. Meta (Hosted Llama)
6. xAI Grok
7. Mistral
8. DeepSeek
9. AWS Bedrock
10. AI21 Labs
What does this page serve?
The LLM Configuration Management page provides Tenant Administrators with a centralized and secure way to configure AI/LLM providers for use across the tenant.
It acts as the controlled connection point between the configured LLM provider and AI-enabled capabilities in Robility Flow. Once an LLM configuration is created, users can directly configure and use it within supported components without being exposed to the underlying credentials or provider configuration.
This allows organizations to make LLM capabilities available to automation while keeping sensitive provider details under administrative control.
Purpose for Tenant Administrators
Only Tenant Administrators can authorize and configure the LLM on this page and have the following capabilities:
i. Register and configure LLM providers.
ii. Configure authentication details, such as API keys, required to establish the provider connection.
iii. Manage provider and model configurations required for AI execution.
iv. Update credentials or configuration when required, while keeping the underlying secrets protected.
Once a credential such as an API key is added, the value is not displayed again, including to the Tenant Administrator. If the credential needs to be changed, the administrator can replace it with a new value without exposing or retrieving the existing secret.
How does it work with Robility Flow?
The primary benefit of LLM Configuration Management is that Robility Flow does not require users to enter or expose the underlying LLM configuration within individual components.
When an LLM-enabled component is configured in Robility Flow, the user can select the required LLM configuration rather than entering sensitive provider details directly.
The component does not expose the configured:
i. API key or secret
ii. Provider credentials
iii. Sensitive connection details
iv. Underlying authentication information
The configured connection is securely encrypted at execution time.
This creates a separation between AI configuration and workflow development.
Why not configure the LLM directly in Robility Flow?
Allowing every workflow or developer to configure an LLM independently can result in credentials being exposed across workflows, duplicated configurations, and unnecessary consumption of AI resources.
With centralized LLM Configuration Management:
Configure once → Govern centrally → Consume securely across workflows
This approach helps prevent:
a. Credential exposure: Sensitive API keys are not displayed in workflow components.
b. Credential duplication: Developers do not need to copy provider credentials into individual workflows.
c. Uncontrolled AI usage: Workflows can use centrally configured and approved LLM connections rather than introducing independent provider connections.
d. Unnecessary token consumption: Centralized configuration helps ensure AI requests are routed through the intended provider/model configuration instead of allowing users to introduce unintended or additional AI resources.
e. Configuration inconsistency: Provider and model settings are maintained centrally rather than being recreated across multiple workflows.
f. Credential leakage through workflow sharing: Sharing or reviewing a Robility Flow does not expose the underlying LLM secret.
LLM Configuration Management vs. Credential Vault
A key distinction between LLM Configuration Management and Credential Vault is their scope.
| LLM Configuration Management | Credential Vault | |
|---|---|---|
| Scope | Tenant level | Project level |
| Primary Purpose | Configure and govern AI/LLM and embedding services | Securely store credentials and secrets |
| Configuration | Provider, model, endpoint, authentication, and AI-specific settings | Credential/secret values used by project resources |
| AI Models | Supports LLM and embedding model configuration | Not specifically intended for model configuration |
| Consumption | Designed to provide centrally managed AI connections to supported capabilities | Credentials are consumed within the project context |
| Secret Visibility | The secret is not displayed after it is configured | Secret values are securely managed within the vault |
| Administration | Tenant Administrator | Project-level administration/access |
How to Configure an LLM
1. Select Providers
Select a provider from the dropdown to display the available configuration options. For the list of supported providers, refer to Supported AI Providers.
2. Basic Configuration
The Basic Configuration section contains the connection and model details required to configure the selected AI provider.
| Field | Description |
|---|---|
| Endpoint | Specifies the endpoint URL used to connect to the selected AI provider service. |
| API Version | Specifies the API version used by the AI service. |
| Model ID | Specifies the identifier of the AI model available through the configured endpoint. |
| Deployment Name | Specifies the deployment name configured for the selected AI model within the provider platform. |
3. Authentication
The Authentication section defines the credentials required to authenticate the AI provider connection.
| Field | Description |
|---|---|
| Auth Type | Specifies the authentication method used to connect to the AI provider. API Key is currently supported. |
| API Key | Specifies the secret API key required to authenticate the connection with the AI provider. |
4. Advanced Settings
The Advanced Settings section provides additional controls for model behavior and network communication.
Model Parameters
Model parameters control how the AI model generates responses. The available parameters include Temperature, Max Tokens, and Top-P, depending on the configured model.
Tenant-level configuration provides the default values for these parameters. If a parameter is configured with a different value in the Robility Model component, the value configured in the component is used during execution.
For more information, see the Robility Model component documentation.
| Field | Default Value | Configuration Range | Description |
|---|---|---|---|
| Temperature | 0.7 | 0.0 – 1.0 |
Controls the randomness of the generated response. • Higher values (0.7–1.0): Generate more varied and creative responses. • Lower values (0.0–0.6): Generate more consistent and predictable responses. |
| Max Tokens | 2048 | 1 – 4096 |
Defines the maximum number of tokens that can be generated in a response. Generation stops when the specified limit is reached. • Higher values (2048–4096): Allow longer responses but may increase usage and cost. • Lower values (1–2047): Limit the response length and may cause the response to be truncated. |
| Top-P | 1.0 | 0.1 – 1.0 |
Controls response diversity by limiting the model's token selection to the most probable options. • Higher values (0.8–1.0): Allow a wider range of possible responses. • Lower values (0.1–0.7): Restrict token selection to more probable options, producing more focused and predictable responses. |
Network Settings
The Network Settings section configures network timeout and retry behavior.
| Field | Description |
|---|---|
| Timeout Seconds | Specifies the maximum time, in seconds, the system waits for a response before the request times out. |
| Retry Count | Specifies the number of times the system retries a request when a transient error or initial failure occurs. |
Enterprise Compliance
The Enterprise Compliance section provides controls for data residency, PII handling, and audit logging.
| Field | Description |
|---|---|
| Data Residency Region | Specifies the geographic region associated with data storage or processing. |
| PII Redaction Enabled | Enables or disables PII redaction before data is transmitted to the AI provider. |
| Audit Logging Enabled | Enables or disables audit logging for supported AI-related activities. |
| Audit Retention Days | Specifies the number of days for which audit records are retained. |
5. Configuration Actions and Security Controls
Configuration Workflow
After entering the required configuration details, complete the configuration using the following steps:
| Step | Action | Description |
|---|---|---|
| 1 | Validate | Click Validate to verify the configured connection and authentication details. |
| 2 | View Details | After successful validation, select View in the provider row to review the configured details. |
| 3 | Modify Settings | Select Edit in the provider row to update the configuration or credentials. |
Access and Security Controls
| Control | Description |
|---|---|
| Role Permissions | Only users with the Tenant Administrator role can view, add, or edit LLM configurations. |
| Credential Masking | API keys and other sensitive credentials are masked and are not displayed after configuration. |
