Configure authentication, authorization, encryption, API access control, and custom scripts for your Agent Platform account.
| Feature | Description |
|---|
| Authentication Settings | Authenticate users through an external Identity Provider using SAML, WS-Federation, or OpenID Connect |
| Authorization Profiles | Define how the Platform authenticates with external web services using OAuth and other token-based methods |
| Encryption Key Management | Configure platform-managed or bring-your-own-key (BYOK) encryption for account data |
| API Scopes | Create permission-limited API keys scoped to specific endpoints and integrations |
| Custom Scripts | Import, deploy, and manage custom scripts in isolated containers via API or tool flows |
Authentication Settings
Authentication Settings lets administrators configure how users sign in to the Platform. You can enable Single Sign-On (SSO) to authenticate users through your organization’s identity provider, and Multi-Factor Authentication (MFA) to add a second layer of verification for email/password sign-ins.
Only account owners and admins can configure Authentication Settings.
How SSO and MFA Work Together
The Platform supports two authentication paths, and MFA scope adjusts automatically based on which path is active:
| Authentication State | Who Signs In Via Email/Password | MFA Managed By |
|---|
| SSO Disabled | All users | Platform (applies organization-wide) |
| SSO Enabled | SSO-excluded users only | Platform (applies to excluded users only); the Identity Provider (IdP) manages all other users’ MFA |
Access Authentication Settings
- Log in to your account and click Settings on the top navigation bar.
- In the left menu, go to Security & Control > Authentication Settings.
The page is divided into two sections:
- Single Sign-On (SSO) Configuration
- Multi-Factor Authentication (MFA).
Single Sign-On (SSO)
SSO allows users to access their Platform accounts using credentials managed by an external IdP. Once authenticated with the IdP, users can access the Platform without a separate login.
Key benefits:
- Secure Access — Reduces password fatigue and the risk of phishing or weak passwords.
- Simplified User Management — Centrally grant or revoke access across all users.
- Improved User Experience — Eliminates repeated logins within the same session.
- Centralized Access Control — Enforce and monitor security policies across all applications from one place.
Supported SSO Protocols and Providers
| Protocol | Providers |
|---|
| SAML 2.0 | Okta, OneLogin, Other Provider |
| WS-Federation | Windows Azure, Other Provider |
| OpenID Connect | Google |
How SSO Works
- User attempts to access their account.
- The Service Provider (SP) redirects the user to the IDP login page.
- User authenticates with the IDP.
- IDP issues an authentication token.
- SP validates the token and grants access.
- User accesses the account without re-authenticating for the rest of the session.
SSO Status
The SSO Status toggle at the top of the SSO Configuration section controls whether SSO is active for your organization.
| Toggle State | Behavior |
|---|
| SSO Disabled (default) | All users authenticate via email and password. The SSO Protocol, Identity Provider, and SSO-Excluded Users sections are hidden. |
| SSO Enabled | Users authenticate through the configured identity provider. The SSO Protocol, Identity Provider, and SSO-Excluded Users sections appear. |
Enable SSO
- On the Single Sign-On page, click Enable SSO.
- Select a Sign-on protocol and SSO provider.
- Enter the configuration parameters for your selected protocol and provider (see Configuration Parameters).
- Add at least one SSO-excluded user (see SSO-Excluded Users).
- Select Save.
Disable SSO
Disabling SSO collapses the SSO Protocol, Identity Provider, and SSO-Excluded Users sections, and reverts all users to email/password authentication. The MFA section updates automatically to reflect organization-wide scope.
Steps:
- Go to Security & Control > Authentication Settings.
- Under SSO Status, toggle off SSO Enabled (it will show SSO Disabled).
- In the confirmation dialog, select Yes to confirm.
Previously configured SSO parameters are retained and visible if you re-enable SSO.
SSO-Excluded Users
When SSO is enabled, all users must sign in through the configured IdP by default. Use this section to designate specific users who can bypass SSO and sign in via email/password instead — useful when the SSO provider is unavailable, misconfigured, or the certificate has expired.
The account owner is excluded by default. It is strongly recommended to exclude at least one additional admin user as a fallback.
Add an Excluded User
- Enter a valid email address in the Add User Email field.
- Click Add User. The user appears as a chip in the Excluded Users list.
- Click Save.
Sign-In Flow for Excluded Users
Excluded users can sign in via email/password even when SSO is enabled. If MFA is configured, they are prompted to complete verification before access is granted.
Configuration Parameters
SAML
| Provider | Required Parameters |
|---|
| Okta | Okta Single Sign-On URL — SSO endpoint for SP-initiated flow
Identity Provider Issuer — Entity URL that authenticates users
Certificate — Public certificate to validate user signatures (up to 2) |
| OneLogin | SAML 2.0 Endpoint — SSO endpoint for SP-initiated flow
Issuer URL — Same role as Identity Provider Issuer (Okta)
X.509 Certificate — Same role as Certificate (Okta) |
| Other | Single Sign-On URL — IDP SSO endpoint
Issuer URL — Same role as Identity Provider Issuer (Okta)
Certificate — Same role as Certificate (Okta) |
| Provider | Required Parameters |
|---|
| Windows Azure | Azure AD Sign-On Endpoint URL — URL for sign-on/sign-off requests; responses go to the Reply URL in your Azure AD config
Azure AD Federation Metadata Document — URL for the federation metadata document |
| Other | AD Sign-On Endpoint URL — Same role as Azure AD Sign-On Endpoint URL
AD Federation Metadata Document URL — Same role as Azure AD Federation Metadata Document |
| Provider | Required Parameters |
|---|
| Google | None — users authenticate with their existing Google credentials |
When multiple certificates are added, the system uses the most recent valid one. If it’s invalid, it automatically falls back to other available certificates.
Multi-Factor Authentication (MFA)
MFA adds a second layer of verification during sign-in for users who authenticate via email/password. The Platform supports the following MFA methods: Email Verification, Authenticator App (TOTP), and SMS.
Enable MFA
- Go to Security & Control > Authentication Settings.
- Under MFA Status, toggle MFA Required.
- Under Allowed MFA Methods, select the methods to enable — Email Verification, Authenticator App, or SMS.
- Click Save.
Disable MFA
- Under MFA Status, toggle off MFA Required (it will show MFA Disabled).
- Click Save.
MFA for Users (First Login)
When MFA is enabled and a user signs in for the first time:
- The user enters their email address and password.
- The Platform prompts the user to set up an MFA method.
- On subsequent logins, the user is prompted to enter their MFA verification code.
- On successful verification, access is granted.
SSO Protocol Reference
SAML 2.0
Security Assertion Markup Language (SAML) is a protocol for web-based SSO that uses secure tokens instead of passwords. It allows IDPs and SPs to operate separately. When a user logs into a SAML-enabled app, the service provider requests authorization from the IDP, which authenticates the user and grants access to the application.
How SAML works
SAML SSO works by transferring the user’s identity from one place (the IDP) to another (the SP) through an exchange of digitally signed XML documents.
When a user logs into a system that acts as an IDP and tries to access his Platform account, the following happens:
- The user accesses the remote app on the IDP portal using the sign-on endpoint URL, and the application loads.
- The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the IDP, asking for authentication. This is the authentication request.
- The user either has an existing active browser session with the IDP or establishes one by logging into the IDP.
- The IDP builds the authentication response in an XML document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the SP.
- The SP, which already knows the IDP and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
- The user’s identity is established, and the user is provided with the Platform account access.
Okta
- Go to Single Sign-On → Enable SSO → select SAML and Okta.
- In the Okta Developer Portal, go to Applications → Create App Integration → select SAML 2.0 → click Next.
- Enter an App Name under General Settings → click Next.
- Under Configure SAML, paste values from the Platform’s SSO page:
- ACS URL for SP-initiated SAML flow → Single Sign-On URL
- ACS URL for IDP-initiated SAML flow → Audience URI (SP Entity ID)
- Click Next → Finish.
- On the Sign On tab, click View Setup Instructions and copy:
- Identity Provider Single Sign-On URL → paste into Okta Single Sign-On URL on the Platform
- Identity Provider Issuer → paste into Identity Provider Issuer on the Platform
- Go to Sign On → SAML Signing Certificates → click Download certificate under Actions.
- Open the certificate in a text editor and copy the data between
BEGIN CERTIFICATE and END CERTIFICATE.
- Paste the value into the Certificate field on the Platform’s SSO page. To add a second certificate, click + Add New.
- Click Save.
OneLogin
- Go to Single Sign-On → Enable SSO → select SAML and OneLogin.
- In the OneLogin Developer Portal, go to Applications → Add Apps, search for your Platform app, and save it.
- From SSO → Enable SAML 2.0, copy:
- OneLogin SAML 2.0 Endpoint (HTTP) → paste into SAML 2.0 Endpoint on the Platform
- OneLogin Issuer URL → paste into Issuer URL on the Platform
- Click View Details on the X.509 Certificate field → copy the certificate data (between
BEGIN CERTIFICATE and END CERTIFICATE).
- Paste into the X.509 Certificate field on the Platform’s SSO page. To add more, click + Add New.
- Copy 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.
- Click Save in both the Platform and OneLogin.
Other SAML Providers
- Go to Single Sign-On → Enable SSO → select SAML and Other.
- Fetch the SSO configuration parameters from your IDP’s developer portal.
- Paste the values into the relevant fields on the Platform’s SSO page.
- Copy ACS URL for SP-initiated SAML flow and ACS URL for IDP-initiated SAML flow from the Platform and paste them into your IDP app settings.
- Click Save.
WS-Federation
WS-Federation enables SSO by sharing signed security tokens across different domains. After the IDP authenticates the user, it issues a token that the relying party validates before granting access.
Windows Azure
- Go to Single Sign-On → Enable SSO → select WS-Federation and Windows Azure.
- On your AD FS server, open AD FS Management → go to ADFS → Service → Endpoints → Metadata to locate the Federation Metadata URL.
- Copy the IdP URL from the metadata and paste it into Azure AD Sign-On Endpoint URL on the Platform.
- Paste the Azure Federation Metadata URL into Azure AD Federation Metadata Document on the Platform.
- Click Save.
Other WS-Federation Providers
- Go to Single Sign-On → Enable SSO → select WS-Federation and Other.
- Copy the SSO endpoint URL from your IDP and paste it into AD Sign-On Endpoint URL.
- Copy the WS-Federation metadata document URL from your IDP and paste it into AD Federation Metadata Document URL.
- Click Save.
OpenID Connect
OpenID Connect (OIDC) is an authentication layer built on OAuth 2.0. The Platform currently supports Google as the OIDC provider.
Google
- Go to Single Sign-On → Enable SSO → select OpenID Connect and Sign in with Google.
- Click Save.
No further configuration is required. Users authenticate with their Google account credentials.
Authorization Profiles
Authorization (Auth) Profiles define how the Platform authenticates with external web services. Configure profiles once and reuse them across API nodes, AI nodes, and other integrations.
Key capabilities:
- Define auth methods such as OAuth tokens, passwords, and custom parameters
- Enforce consistent access control across multiple integrations
- Test connections before putting them into production
- Reuse profiles to reduce configuration effort
Access Authorization Profiles
- Go to Autonomous Agents → Settings.
- Click Security & Control → Authorization Profile.
Supported Auth Types
| Type | Description | Use Case |
|---|
| OAuth V2 | Token-based authorization supporting user-interactive flows | Third-party API access (e.g., “Sign in with Google”) |
| OAuth V2 Client Credential | Machine-to-machine flow using client ID and secret; no user interaction | Server-to-server communication, microservices |
Add an Auth Profile
- On the Authorization Profile page, click Create Authorization Profile (for your first profile) or Add New Auth.
- In the New Authorization Mechanism dialog, select the Authorization Type.
- Enter the Identity Provider Name (required).
- Fill in the required fields (see Field Reference below).
- Optionally click + Add Additional Field or + Add Authorization Field.
- Click Save New Auth.
Field Reference
| Field | Description | Required | Auth Type |
|---|
| Authorization Type | OAuth V2 or OAuth V2 Client Credential | Yes | Both |
| Identity Provider Name | Name of the IDP, e.g., Okta | Yes | Both |
| Description | Purpose of the auth profile | No | Both |
| Callback URL | Redirect URL after the user grants or denies permission | Yes | Both |
| Client ID | Unique app identifier used by the authorization server | Yes | Both |
| Client Secret | Confidential key for authenticating the app with the server | Yes | Both |
| Authorization URL | Endpoint where users authenticate and grant permissions | Yes | OAuth V2 only |
| Subdomain (Tenancy URL) | Tenant-specific URL in multi-tenant systems | Yes | OAuth V2 only |
| Token Request URL | Endpoint to exchange an auth code for an access token | Yes | Both |
| Scope | Level of access requested, e.g., read_profile | No | Both |
| Refresh Token URL | Endpoint to get a new access token when the current one expires | No | OAuth V2 only |
| Auth Error Status Code | HTTP status code returned on authorization failure | No | Both |
| Additional Fields | Extra key-value pairs for the end user (e.g., PIN code) | No | OAuth V2 only |
| Authorization Fields | Token-passing fields: Header, Payload, Query String, or Path Param | No | OAuth V2 only |
If the Refresh Token URL or refresh token expires, the auth profile will fail wherever it is used. The admin receives an email notification to reconfigure.
Add Additional Fields
Use additional fields to collect supplemental authorization data from end users alongside standard credentials — for example, a PIN code or device ID.
- Click + Add Additional Field in the New Authorization Mechanism window.
- Enter a Field Key (name, e.g.,
Pin code) and Field Value (e.g., 2344567).
- Click Done.
The field appears in the Additional Fields list where you can edit or delete it.
Add Authorization Fields
Authorization fields define how token data is passed in API requests.
| Parameter | Options | Required |
|---|
| Field Type | Header, Payload, Query String, Path Param | Yes |
| Field Key | Name of the auth field, e.g., Profile_id | Yes |
| Field Value | Value for the field, e.g., 123_xyz | No |
- Click + Add Authorization Field in the New Authorization Mechanism window.
- Fill in the fields and click Done.
Test an Auth Profile
Click Test next to a configured profile to verify it establishes a connection with the external service. If the test fails, edit the profile with the correct values and retest.
Manage Auth Profiles
Edit: Click the ellipsis (⋯) menu → Edit → update fields in the Update Authorization Mechanism window → click Update New Auth.
Authorization Type and Name cannot be changed after the profile is created. All other fields are editable.
Encryption Key Management
The Platform encrypts all account data. You can use the platform’s built-in key management or integrate with your organization’s external Key Management System (KMS) using Bring Your Own Key (BYOK).
Encryption is configured at the account level. All apps within an account share the same encryption key.
Bring Your Own Key (BYOK)
Use keys stored in your own KMS to control encryption and decryption. The Platform communicates with your external KMS for all cryptographic operations. If your KMS is unavailable, the Platform falls back to default encryption.
Supported providers: AWS KMS, Azure Key Vault
- Go to Settings → Key Management.
- Click Configure BYOK.
- Select your cloud provider and enter the required configuration details.
Azure Key Vault
Required service principal permissions:
Key Vault Crypto Service Encryption UserMicrosoft.KeyVault/vaults/keys/encrypt/actionMicrosoft.KeyVault/vaults/keys/decrypt/actionMicrosoft.KeyVault/vaults/keys/wrap/actionMicrosoft.KeyVault/vaults/keys/unwrap/actionMicrosoft.KeyVault/vaults/keys/read
Configuration fields:
| Field | Description |
|---|
| Key Vault URL | Endpoint of your Azure Key Vault instance |
| Tenant ID | Microsoft Entra ID tenant identifier for the Azure subscription where the Key Vault resides |
| Key Nickname | User-defined label to identify the key in the Platform |
| Activation Date | Date from which the key becomes active and available for use |
AWS KMS
Required IAM permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:DescribeKey",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:*:*:key/*",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:tenant_id": "${aws:RequestedRegion}"
}
}
}
]
}
| Field | Description |
|---|
| ARN | Amazon Resource Name that uniquely identifies your AWS KMS key |
| Role ARN | ARN of the IAM role that grants the Platform permission to use the KMS key |
| Key Nickname | User-friendly label to identify the key in the Platform |
| Activation Date | Date from which the key can be used for encryption and decryption |
API Scopes
API Scopes replace unrestricted management API keys with permission-limited, scoped keys. Create API apps with specific scopes so each integration only accesses the endpoints it needs.
Key rules:
- API keys are restricted to assigned scopes; requests to other scopes are automatically rejected.
- Multiple API keys can exist per app.
- An API key cannot be shared across multiple apps.
- API keys cannot be modified after creation — only deleted.
- Each key can only be copied once (copy-once policy).
Access API Scopes
- Go to Autonomous Agents → Settings.
- Click Security & Control → API Scopes.
Supported Scopes
| Scope | Description |
|---|
| Deploy Tool | Deploy a specific tool into an environment (sync or async) |
| Undeploy Tool | Remove a deployed tool from an environment |
| Deploy Model | Deploy an open-source or fine-tuned model in Ready to Deploy state |
| Undeploy Model | Remove a deployed model from an environment |
| Import Model | Import a model into the Platform in chunks |
| Import Tool | Import a new tool into the system |
| Export Model | Export a trained AI model from the system |
| Export Tool | Export a tool’s configuration and associated data |
| Deploy Guardrails | Deploy guardrails for security and content moderation |
| Undeploy Guardrails | Remove previously deployed guardrails |
| View Connections | View connection details |
| Manage Connections | Create and update connections |
Create an API App
- On the API Scopes page, click Create an API App.
- Click Untitled App and enter an app name.
- Select the required scopes from the list.
- Click Next.
Create an API Key
This step completes the app setup. At least one API key is required.
- Click Create API Key.
- Enter a key name and click Generate Key.
- Click Copy and Close to copy the key.
The API key is shown only once. Save it in a secure location. If lost, you must revoke it and generate a new one — this may disrupt any services currently using the key.
- Click Done.
The app summary displays: app name, assigned scopes, creator, and creation date.
Manage Apps and Keys
Rename or update scopes: Hover over the app → click Edit → update the name or select/deselect scopes → click Save.
Delete an API key: In the app’s API Keys tab, hover over the key → click Delete → confirm.
Deleting a key that is actively in use will immediately break any services relying on it. Generate a replacement key before deleting if the key is in production use.
Custom Scripts
Admins can import, deploy, and manage custom scripts directly from Settings → Manage Custom Scripts. Scripts run in isolated containers and can be invoked via the API node endpoint or embedded in the Function node of a tool flow.
| Capability | Description |
|---|
| Task Automation | Automate repetitive or complex tasks without manual intervention |
| Secure API Integration | Call scripts via API endpoints with key-based authentication |
| Customization | Implement business-specific logic and custom workflows |
| Data Processing | Transform, filter, or validate data for operational requirements |
| Error Handling | Define custom error-checking and fallback mechanisms |
Access Custom Scripts
- Go to Autonomous Agents → Settings.
- Click Manage Custom Scripts in the left menu.
Import and Deploy a Script
Click + Import or + Import New, then complete the four-step wizard.
Step 1: General Details
| Field | Details |
|---|
| Script Name | A unique name for the script |
| Description | Purpose and capabilities of the script |
| Base Language | JavaScript (v20.19.0) or Python (v3.10.15) |
| Project File | .zip, .gz, or .tar file — max 1 GB |
- Include
main.py (Python) or main.js (JavaScript) at the archive root — only functions defined in this file are exposed via API.
- Include
requirements.txt (Python) or package.json (JavaScript) at the root if your script has external dependencies.
- Use relative imports when referencing files within the project.
- Access environment variables using
os.getenv('<key>') in Python or process.env.<key> in JavaScript.
Download the sample project from the wizard to verify your file matches the required structure. Structure differs by language, so use the correct sample for your chosen language.
Step 2: Runtime Settings
| Setting | Description | Range / Default |
|---|
| Environment Variables | Key-value pairs accessible from the script at runtime | Custom |
| Execution Timeout | Maximum time the script is allowed to run | 30–600 seconds |
UPLOADS_DIR — Read-only access to files uploaded via Public APIs.WORKSPACE_DIR — Read-write directory for the script’s file operations.
Both directories are only accessible while the container is deployed.
Step 3: Resource Allocation
Scaling parameters:
| Parameter | Range | Default |
|---|
| Min Replicas | 1–10 | 1 |
| Max Replicas | 1–10 | 1 |
| Average Compute Utilization | 1–100% | 75% |
| Profile | Actual CPU & Memory | Credits/Hour |
|---|
| 1 vCPU / 2 GB | 0.7 vCPU / 1.1 GB | 0.077 |
| 2 vCPUs / 4 GB | 1.5 vCPUs / 2.5 GB | 0.154 |
| 2 vCPUs / 8 GB | 1.5 vCPUs / 6.5 GB | 0.144 |
| 4 vCPUs / 8 GB | 3.5 vCPUs / 6 GB | 0.308 |
| 4 vCPUs / 16 GB | 3.5 vCPUs / 13.5 GB | 0.288 |
Step 4: Review and Deploy
- Review all sections — General Details, Runtime Settings, and Resource Allocation. Click any section to go back and edit.
- Accept the Terms and Conditions.
- Optionally click Save as Draft to deploy later.
- Click Deploy.
After successful deployment, a confirmation email is sent to the admin with the subject “Custom script deployed successfully — API Endpoint Available”, including remaining credits and total allocation.
Script Statuses
| Status | Description | Can Redeploy? |
|---|
| Draft | Saved but not yet deployed | No |
| Deploying | Deployment in progress | No |
| Ready to Deploy | Configured and ready for deployment | Yes |
| Deployed | Running successfully in the environment | Yes |
| Deployment Failed | Deployment did not complete successfully | Yes |
Actions
| Action | Available When | Description |
|---|
| Export | All statuses | Downloads the project as a .zip file to your local system |
| Undeploy | Deployed | Removes the script from all deployed locations; status changes to Ready to Deploy |
| Delete | Not deployed | Permanently removes the script and all its data — cannot be undone |
| Redeploy | Deployed, Ready to Deploy | Re-runs the import flow so you can update description, project file, runtime settings, or resource allocation (name, language, and version cannot be changed) |
You cannot delete a deployed script. Undeploy it first, then delete.
Script Detail Pages
Each script entry has four tabs:
| Tab | What It Shows |
|---|
| Overview | Current configuration (General Details, Runtime Settings, Resource Allocation) and available actions based on deployment status |
| Deployment History | Full history of deployments and undeployments — version, timestamp, duration, deployed by, and final status. Expand any row for detailed configuration at that point in time |
| Endpoint | The activated endpoint in cURL, JavaScript, and Python formats. Copy any format directly into your application. Only available when the script is in Deployed status |
| API Keys | Create and manage secret API keys for authenticated access to the script’s endpoint |
API Keys for Scripts
- Go to the script’s API Keys tab.
- Click Create a New API Key.
- Enter a name and click Generate Key.
- Click Copy and Close.
Secret keys are shown only once. Store the key securely. If lost, delete the key and generate a new one.
Use a Script via the API Node
- In the API node configuration, click Define Request.
- On the script’s Endpoint tab, copy the cURL code.
- Paste it into the Edit Request dialog.
- Select an Auth Profile if the endpoint requires authentication (or select None).
- Add headers (e.g.,
Content-Type: application/json) and body parameters as needed.
- Click Test to validate the request, then Save.
For full API node configuration options, see API Node. 