Workspace and Team Settings

Configure workspace structure, roles, member access, security policies, encryption keys, and environment variables. The Workspace and Team settings are your control center for access, security, and runtime configuration. From here you manage who can do what, how data is protected, and what values agents use at runtime.

Navigation: Settings > Team
Required role: Owner or Admin

Workspace structure

The Agent Platform organizes resources across three levels. You don’t need all three - start with a workspace, add projects as your work grows, and only set up an organization if you need to manage multiple workspaces together.

Level	Description
Workspace	Your team’s dedicated environment. Contains all agents, models, connectors, secrets, and members. Each workspace is fully isolated - data in one workspace is never accessible from another.
Project	A group of related agents and resources for a specific use case, inside a workspace. Projects inherit the workspace’s AI model configuration but can override model tier assignments.
Organization	Optional. Sits above workspaces for shared billing and governance across multiple teams. A single-workspace setup doesn’t need this.

What the workspace controls:

Who has access and what they can do (team membership and roles).
Which AI models and providers are available (LLM policies, token budgets, rate limits).
Which features are unlocked (based on your plan tier).

What projects add:

Project members are drawn from workspace members and carry project-specific roles.
Environment variables and secrets can be scoped per project and per environment (development, staging, production).

Roles and permissions

The platform uses hierarchical role-based access control (RBAC). Each role inherits all permissions from the roles below it.

Workspace roles

Role	Description	Key Permissions
Owner	Full control. One owner per workspace.	Transfer ownership, delete workspace, manage billing, all admin operations.
Admin	Manages team members, models, and workspace settings.	Invite/remove members, configure models, manage secrets and connectors, view audit logs.
Operator	Manages agent deployments and monitors production.	Deploy agents, view analytics, manage environment variables, view sessions.
Member	Builds and tests agents within assigned projects.	Create/edit agents, run tests, manage project-level resources.
Viewer	Read-only access to workspace resources.	View agents, project configurations, and analytics dashboards.

Project roles

Role	Description	Key Permissions
Admin	Full control over the project’s resources and settings.	Manage all project resources, configure settings, oversee operations.
Developer	Creates and modifies agents, tools, workflows, and project assets.	Build and update agents, tools, workflows, and assets.
Tester	Reads project resources, runs simulations and evaluations.	Access project resources, execute tests, validate agent behavior.
Viewer	Read-only access to the project.	View project resources and configurations.

How workspace and project roles interact:

Workspace Owners and Admins have workspace-wide authority and can administer all projects without explicit project membership.
Non-admin workspace members need explicit project membership for project-scoped access.
When a workspace member creates a project, they automatically become that project’s Admin and can add other workspace members from Settings > Members.

Managing members

Only workspace Owners and Admins can manage team membership.

View current members

Go to Settings > Team > Members. The list shows name and email, workspace role, status (active, suspended, locked, or deactivated), and date joined.

Invite a member

Click Invite member.
Enter the invitee’s email address.
Select a role: Admin, Operator, Member, or Viewer.
Click Send invite.

The invitee receives an email with a unique link that includes the workspace name and their assigned role. Invitations expire after 7 days and are cleaned up automatically. Manage pending invitations from the Pending Invitations section on the Members page:

Action	What it does
Resend	Sends a fresh invitation email with a new token, resetting the 7-day expiry.
Revoke	Cancels the invitation so the link can no longer be used.

If a member reports not receiving the invitation email, check the pending list and resend - you don’t need to revoke first.

Change a member’s role

Find the member in the Members list.
Click the role dropdown next to their name.
Select the new role and confirm.

Role changes take effect immediately - permissions update on the member’s next page load or API call. Platform-enforced role hierarchy rules:

You can’t assign a role higher than your own. An Admin can’t promote a member to Owner.
Only the workspace Owner can promote a member to Admin.
Only the workspace Owner can transfer ownership.
You can’t demote yourself - ask another Owner or Admin to change your role.

Remove a member

Find the member in the Members list.
Click the three-dot menu next to their row.
Select Remove member and confirm.

What happens when a member is removed:

They lose access to all workspace resources immediately.
Their project memberships within this workspace are removed.
Resources they created (agents, knowledge bases) remain in the workspace.
Active sessions they initiated continue running, but they can’t start new ones.

Removing a member doesn’t delete their Agent Platform account. They can still access other workspaces they belong to.

Transfer workspace ownership

Only the current workspace Owner can transfer ownership.

Go to Settings > Team > Members.
Click the three-dot menu next to the target member.
Select Transfer ownership and confirm by typing the workspace name.

After the transfer, the previous Owner is demoted to Admin, and the new Owner gains full control, including the ability to delete the workspace.

Role management

Role Management lets you control what people can see and do across your workspace and projects. Roles are organized into two types:

Custom roles - roles you define yourself
System roles - built‑in roles that cover the most common access levels out of the box

You’ll find Role Management under Settings > Role Management.

Custom roles

Custom roles let you build access levels tailored to your team - for example, a role that can only read configuration, or one scoped to a specific set of release environments. The Custom roles tab lists every custom role in your workspace, showing the role name and description, how many permissions are assigned, when it was created, and quick actions to edit or delete it.

Creating a custom role

Click + Create Role to open the creation panel, then fill in:

Role name - a short, identifiable name (for example: “Analyst,” “QA Lead”).
Description (optional) - context for what the role is for, useful when you have several similar roles.
Parent role (optional) - base this role on an existing custom role to inherit its permissions. Choose No parent role to start from scratch. The panel shows the resulting parent chain so you can see what’s being inherited before you save.

Assigning permissions

Permissions are grouped by category. Select the specific actions this role is allowed to perform. A running count at the bottom shows how many permissions are selected.

Permissions outside your own role’s grant scope are shown for visibility but can’t be selected - you can’t grant access you don’t already have.

Scoping release environments

If the role includes the Workbench release permission, you can also restrict where it’s allowed to release configurations - Development, Staging, and/or Production. This scoping only applies to release actions; it doesn’t grant production access on its own, and the underlying release permission must still be selected separately. Click Create to save the role, or Cancel to discard it.

System roles

The System roles tab lists built‑in roles, grouped by where they apply. These roles can’t be edited or deleted, but you can expand any role to view the grants it includes. Click View grants next to any role to see its full permission list.

When to use custom vs. system roles

Use a System role whenever one of the built-in options already matches what someone needs - they require no setup and stay current automatically. Reach for a Custom role when you need finer-grained control, such as read-only access to a subset of permissions, an environment-scoped release role, or a role built on top of another custom role through a parent chain.

Security and compliance

Go to Team > Security & Compliance to manage authentication and access controls. The page has three tabs: MFA, SSO, and Audit Logs. Required role: Owner or Admin.

Multi-factor authentication (MFA)

MFA adds a verification step using a time-based one-time password (TOTP). Enable MFA for your account: Go to Team > Security & Compliance, click Enable MFA, complete the authenticator app setup, enter the verification code, and click Verify & Enable. Recovery codes are generated during MFA setup and let you access your account if you lose your authenticator app:

Each code can only be used once.
Store them securely.
Regenerating codes invalidates all previously issued codes.

Enforce MFA for the workspace: From the MFA tab, enable Require MFA for all members and select a grace period. When enforced:

New members must configure MFA before accessing the workspace.
Existing members must complete MFA setup within the grace period.
Members who don’t complete setup are locked out until MFA is configured.

Single Sign-on (SSO)

SSO lets users authenticate using an external identity provider (IdP). Plan requirement: Enterprise plan only. Generated SSO URLs The platform automatically generates these endpoints; there is no action to create or edit them manually. Use the URLs when configuring your identity provider’s SAML/OIDC application settings. Auto-generated SSO URLs are created automatically and aren’t user-configurable. Only organization owners or admins can view and use these URLs to configure SSO. Admins can select Refresh to reload the current URL values, but this doesn’t regenerate or change them.

SSO Protocol	URL	When to use it
SP Entity ID / Audience URI	`https://example.com/api/sso/saml/sp/spId`	Enter as the Entity ID, Identifier, or Audience URI in the Identity Provider (IdP). It uniquely identifies the Agent Platform Service Provider (SP) and allows the IdP to validate that SAML assertions are intended for this application.
SP‑initiated ACS URL	`https://example.com/api/sso/saml/callback`	Enter as the Assertion Consumer Service (ACS) URL or Reply URL in the Identity Provider (IdP) for Service Provider (SP)‑initiated sign‑ins.
IdP‑initiated ACS URL	`https://example.com/api/sso/saml/callback`	Enter as the Assertion Consumer Service (ACS) URL in the Identity Provider (IdP) for Identity Provider (IdP)‑initiated sign‑ins.
SAML metadata URL	`https://example.com/api/sso/saml/metadata?metadataId=<metadataId>`	Provide this URL to the Identity Provider (IdP) to automatically import the Service Provider (SP) metadata, including the Entity ID, ACS URLs, supported bindings, and signing certificates.
OIDC redirect URL	`https://example.com/api/sso/oidc/callback`	Enter as the Redirect URI or Callback URL when configuring an OpenID Connect (OIDC) identity provider.

Supported protocols:

SAML 2.0 - Supports Okta, Azure AD, and OneLogin.
OpenID Connect (OIDC) - Supports Auth0 and Keycloak.

Set up SAML SSO: Go to Team > Security & Compliance > SSO, select SAML 2.0, enter the required configuration details, and click Save Configuration. Set up OIDC SSO: Go to Team > Security & Compliance > SSO, select OpenID Connect, enter the required configuration details, and click Save Configuration. Domain verification: Use the Domain Verification section in the SSO tab to claim and verify your organization’s email domain before enforcing SSO. Force SSO: Enable Force SSO from the SSO tab to require users with verified domain email addresses to authenticate through SSO. When enabled:

Password-based login is disabled for verified domain users.
Users outside the verified domain are unaffected.
Workspace Owners retain password-based login as a fallback.

Google authentication fallback: Enable Allow Google fallback to let users sign in with Google if the configured SSO provider is unavailable.

Audit logs

Audit logs give you a tenant-scoped, filterable record of all significant workspace actions. Use them to investigate incidents, verify compliance, and review team activity.

Navigation: Settings > Team > Audit Logs
Required role: Owner or Admin
Export: Available on Professional and Enterprise plans

Use Refresh to reload the log. Use Export CSV to download the current filtered view. Use the filter bar to narrow results by search text, date range, action type, preset, or category.

Summary metrics

Metric	Description
Matching events	Total events matching the current filters.
Failed on page	Failed events on the current page.
Actors on page	Distinct actors on the current page.
Active filters	Number of filters applied.
Last event	Timestamp of the most recent event.

Event categories

Category	Examples
Auth & access	Login, logout, MFA, SSO, API keys.
Workspace governance	Member invites, role changes, ownership transfers.
Project, agent & workflow config	Agent creation, updates, deployments, workflow changes.
Tools, modules & credentials	Tool bindings, module updates, credential changes.
Data protection	KB updates, uploads, exports, retention events.
KMS	Key rotations, DEK creation, provider changes.
Connector configuration	Channel connections, SDK changes.
Archives, retention & Git	Archiving, retention policy changes, Git events.

Log table columns

Column	Description
Timestamp	When the action occurred.
Category	Event category.
Action	Specific action, for example `agent.dsl_updated`.
Actor	User or system ID.
Target	Resource affected.
Project	Associated project.
Source	Origin: Studio or runtime-store.
IP	Request IP address.
Trace	Trace ID, if available.

Retention

Follows the workspace retention policy.
Professional and Enterprise plans: at least 90 days.
Contact support for extended retention.

Key management

The Key Management Service (KMS) lets you control the encryption keys used to protect sensitive workspace data. Instead of relying on platform-managed keys, you can provide your own key material from a supported cloud provider.

Navigation: Settings > Team > Key Management
Required role: Owner
Plan requirement: Enterprise plan only

Configuration

Select a Provider from the dropdown to configure the tenant-level KMS. The fields shown depend on the provider selected. Supported KMS providers

Provider	Key type	Region support
Platform Managed	Platform-governed keys	Managed by platform
AWS KMS	Symmetric CMK (AES-256)	All AWS regions
Azure Key Vault	RSA or AES keys	All Azure regions
Azure Managed HSM	Symmetric AES-256 keys	All Azure regions
Google Cloud KMS	Symmetric AES-256 keys	All GCP regions
External KMS	Any REST-compatible KMS	Self-hosted or SaaS
Platform Managed	Platform-governed keys	Managed by platform

Platform Managed

Use the platform-managed KMS provider. No tenant-specific external key connection is stored in this mode.

Platform Managed encryption is governed by Kore. You can select it, but its policy, compliance, rotation, and re-encryption settings are read-only. To bring your own key, choose a different provider.

AWS KMS

Field	Description
AWS Region	The AWS region hosting the key, for example `us-east-1`.
KMS Key ARN	The full ARN of the CMK, for example `arn:aws:kms:us-east-1:123456789:key/abcd-1234`.
Credential Overrides (JSON)	Optional. Override the platform’s default AWS credentials with a JSON object (for example `clientId` / `clientSecret`).

Azure Key Vault

Field	Description
Key Vault URL	The vault’s URL, for example `https://your-vault.vault.azure.net`.
Key Name	The name of the key within the vault.
Auth Method	Service Account / Service Principal or Workload Identity Federation (secretless).

Service Account / Service Principal Use the Azure app registration or service principal that can read, wrap, and unwrap this key.

For cross-tenant access, register this application in the customer Azure tenant via admin consent and assign the Key Vault Crypto User role on the target key vault.

Field	Description
Tenant ID	The Azure directory (tenant) ID.
Client ID	The application (client) ID.
Credential type	Client secret or Certificate (PEM).
Client Secret	Required when Credential type is Client secret.

Workload Identity Federation (secretless) Secretless auth for a vault in this or another Azure directory. The customer directory trusts this platform’s workload identity - nothing to store, expire, or rotate.

Field	Description
Tenant ID	The Azure directory (tenant) ID.
Client ID	The application (client) ID.

Under Federated credential setup (customer side), register these exact values as a federated credential on the app registration in the customer’s Azure directory: OIDC issuer, Subject, and Audience (each has a Copy button).

Create (or pick) an app registration in the customer’s Azure directory and note its Directory (tenant) ID and Application (client) ID.
On that app, add a federated credential with the issuer, subject, and audience shown above.
Grant the app the Key Vault Crypto User role scoped to the target vault only - never subscription-wide.
Enter the two IDs here, then use Test connection before saving.

A newly created federated credential can take several minutes to propagate in Microsoft Entra ID. If the connection test fails right after setup, wait a few minutes and retry.

Use Test Connection to verify the provider connection before saving configuration.

Azure Managed HSM

Field	Description
Managed HSM URL	The HSM’s URL, for example `https://your-hsm.managedhsm.azure.net`.
Managed HSM Key Name	The name of the key within the Managed HSM, for example `tenant-kek-primary`.
Auth Method	Service Account / Service Principal or Workload Identity Federation (secretless).

Service Account / Service Principal Use the Azure app registration or service principal that can read, wrap, and unwrap this key.

For cross-tenant access, register this application in the customer Azure tenant via admin consent and assign the Key Vault Crypto User role on the target key vault.

Field	Description
Tenant ID	The Azure directory (tenant) ID.
Client ID	The application (client) ID.
Credential type	Client secret or Certificate (PEM).
Client Secret	Required when Credential type is Client secret.

Field	Description
Tenant ID	The Azure directory (tenant) ID.
Client ID	The application (client) ID.

Create (or pick) an app registration in the customer’s Azure directory and note its Directory (tenant) ID and Application (client) ID.
On that app, add a federated credential with the issuer, subject, and audience shown above.
Grant the app the Key Vault Crypto User role scoped to the target vault only - never subscription-wide.
Enter the two IDs here, then use Test connection before saving.

Google Cloud KMS

Field	Description
Location	The GCP location, for example `us-east1`.
Key Resource Name	Full resource path, for example `projects/my-project/locations/us-east1/keyRings/my-ring/cryptoKeys/my-key`.
Auth Method	Default Credentials or Service Account / Service Principal.
Credential Overrides (JSON)	Optional. Override the default credentials with a JSON object (for example `clientId` / `clientSecret`).

External KMS

Connect any REST-compatible KMS, self-hosted or SaaS.

Field	Description
External KMS Endpoint	The base URL of the external KMS, for example `https://kms.example.com`.
External Key ID	The key identifier at the external provider, for example `tenant-kek-primary`.
Auth Method	API Key, mTLS, OAuth2 Client Credentials, or HMAC-SHA256.
Credential Overrides (JSON)	Optional JSON object with provider-specific credential fields (for example `clientId` / `clientSecret`).

External Endpoint Validation Before saving the tenant KMS configuration, enter the endpoint, key ID, and auth method, then click Validate Endpoint to confirm the platform can reach and authenticate against the external provider.

Policies

Setting	Options	Default
Failure Policy	Fail Closed - all encryption/decryption stops Graceful Degradation - continue with cached DEKs until KMS reconnects	Fail Closed
Compliance Level	Standard, PCI DSS, HIPAA, FIPS 140‑3	Standard

Rotation and re-encryption settings

Key rotation can happen automatically (if the provider supports scheduled rotation) or manually, by creating a new key version on demand from the Encryption Keys tab.

Setting	Description
DEK Epoch Interval	Frequency of DEK generation.
DEK Max Usage Count	Maximum DEK usage before rotation.
Destroy retired DEKs	Enables automatic destruction after the retention period.
KEK Rotation Period	Frequency of KEK rotation.
Enable automatic re-encryption	Automatically queues re-encryption jobs after rotation.

Re-encryption also includes Concurrency (parallel jobs), Batch Size (records per batch), and Max Retries (retry attempts for failed jobs). Click Save Configuration to apply.

Scopes

Manage different KMS providers for tenant environments, projects, and project environments.

Environment variables

Environment variables are key-value pairs that allow you to inject configuration into your agents and tools without hardcoding values in your ABL definitions. Environment variables are typically used for defining endpoints, feature flags, timeouts, and other environment-specific configuration. They’re resolved at runtime and scoped by environment and project. A variable is defined by its key within a project. The variable can have a Global value that is shared across all environments and optional environment-specific values for Development, Staging, and Production. When both a Global value and an environment-specific value exist for the same key, the environment-specific value takes precedence. Environment variables are:

Environment-specific - The same key can have different values in development, staging, and production environments.
Encrypted at rest - Encrypted values are stored using AES-256-GCM encryption.
Resolved at runtime - Values are resolved when the agent runs.
Immediately effective - Changes apply to new agent sessions without requiring redeployment.

Environment variables are scoped to a project.
Manage variables centrally from Workspace Settings > Env Variables or from the project’s Deployments > Environments page.

Add environment variables

Navigate to Workspace Settings > Env Variables.
Select the project.
Select the target environment from the environment selector or create a global variable that applies to all the environments.
Click Add Variable. By default, platform adds the variable to the Default namespace. To add the variable to a different namespace, select the desired namespace from the Namespace dropdown before creating the variable.
Enter the following details and Save.

Field	Description
Key	Specifies the unique variable name for the selected project and environment. The key name must: start with a letter and contain only letters, numbers, and underscores. be unique within a project and environment.
Value	Specifies the value assigned to the variable for the selected environment.
Description	Provides additional information about the variable for project collaborators.
Secret	Masks the variable’s value after it’s saved. Enable this option for sensitive values.

Reference environment variables

You can reference environment variables using {{env.KEY}} syntax. Environment variables are resolved at runtime based on the active deployment environment. You can reference environment variables in the following constructs:

HTTP tool endpoint, headers, auth, request body
MCP tool call arguments
RESPOND text, rich content (quick replies, cards, forms, KPI/chart widgets)
ESCALATE / handoff messages, GATHER re-prompts, guardrail block/redirect messages
Agent persona / goal / limitations (system prompt)

Example: HTTP Tool Endpoints

TOOLS:
  lookup_customer(customer_id: string) -> {name: string, tier: string}
    description: "Look up customer details"
    type: http
    endpoint: "{{env.API_URL}}/customers/{customer_id}"
    method: GET
    auth: bearer
    timeout: "{{env.TIMEOUT}}"

Example: Response templates

COMPLETE:
  - WHEN: ticket_created IS SET
    RESPOND: |
      Your ticket has been created.
      Expected response time: {{env.SLA_HOURS}} hours.
      Support portal: {{env.SUPPORT_PORTAL_URL}}

Example: Memory

MEMORY:
  PERSISTENT:
    - PATH: user.preferences
      TTL: "{{env.MEMORY_TTL_DAYS}}d"

Edit a variable

Click the Edit icon next to a variable to update its value, description, or secret setting. Changes take effect immediately for new agent sessions.

Existing agent sessions continue using the environment variable values that were resolved when the session started. Updated values are applied only to new sessions. HTTP tools and MCP tools are an exception and use the updated values immediately after they are saved.

Delete a variable

Click the Delete icon and confirm the deletion.

Before deleting a variable, ensure it’s no longer referenced. Referencing a deleted variable results in a runtime resolution error.

Import or export environment variables

You can perform a bulk import of environment variables. This allows you to create or update multiple environment variables simultaneously.

Click Import.
Select the target environment.

Paste the key in JSON format as shown below.

[
  {"key": "API_KEY", "value": "sk-xxx", "isSecret": true},
  {"key": "DB_URL", "value": "postgres://..."}
]

Review the import preview.
Click Import.

Similarly, you can also export the environment variables in .json or .env file formats.

Variable namespaces

Namespaces organize environment variables into logical groups. Every project includes a default namespace, and you can create up to 25 namespaces per project.

Create a namespace

Navigate to Settings > Environment Variables.
Click Namespaces.
Click New Namespace.
Enter Namespace name, Display name, Description, and Color.
Click Create.

​Workspace structure

​Roles and permissions

​Workspace roles

​Project roles

​Managing members

​View current members

​Invite a member

​Change a member’s role

​Remove a member

​Transfer workspace ownership

​Role management

​Custom roles

​Creating a custom role

​Assigning permissions

​Scoping release environments

​System roles

​When to use custom vs. system roles

​Security and compliance

​Multi-factor authentication (MFA)

​Single Sign-on (SSO)

​Audit logs

​Summary metrics

​Event categories

​Log table columns

​Retention

​Key management

​Configuration

​Platform Managed

​AWS KMS

​Azure Key Vault

​Azure Managed HSM

​Google Cloud KMS

​External KMS

​Policies

​Rotation and re-encryption settings

​Scopes

​Environment variables

​Add environment variables

​Reference environment variables

​Edit a variable

​Delete a variable

​Import or export environment variables

​Variable namespaces

​Create a namespace

Workspace structure

Roles and permissions

Workspace roles

Project roles

Managing members

View current members

Invite a member

Change a member’s role

Remove a member

Transfer workspace ownership

Role management

Custom roles

Creating a custom role

Assigning permissions

Scoping release environments

System roles

When to use custom vs. system roles

Security and compliance

Multi-factor authentication (MFA)

Single Sign-on (SSO)

Audit logs

Summary metrics

Event categories

Log table columns

Retention

Key management

Configuration

Platform Managed

AWS KMS

Azure Key Vault

Azure Managed HSM

Google Cloud KMS

External KMS

Policies

Rotation and re-encryption settings

Scopes

Environment variables

Add environment variables

Reference environment variables

Edit a variable

Delete a variable

Import or export environment variables

Variable namespaces

Create a namespace