Workspace and team settings

Configure workspace structure, roles, member access, security policies, encryption keys, and environment variables. Workspace and Team settings are your control center for access, security, and runtime configuration. From here you decide who can do what, how the platform protects data, and which 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 set up an organization only when you need to manage several workspaces together.

Level	Description
Workspace	Your team’s dedicated environment. It holds all agents, models, connectors, secrets, and members. Each workspace stays fully isolated, so nothing in one workspace reaches another.
Project	A group of related agents and resources for a specific use case, inside a workspace. A project inherits the workspace’s AI model configuration but can override model tier assignments.
Organization	Optional. It sits above workspaces and carries shared billing and governance across several teams. A single-workspace setup doesn’t need one.

What the workspace controls:

Who has access and what they can do, through team membership and roles.
Which AI models and providers your team can reach, through LLM policies, token budgets, and rate limits.
Which features your plan tier unlocks.

What projects add:

Projects draw their members from workspace members and give them project-specific roles.
You can scope environment variables and secrets per project and per environment, covering development, staging, and production.

Roles and permissions

The platform uses hierarchical role-based access control. Each role inherits every permission the roles below it hold, so you grant the level someone needs rather than assembling one from parts.

Workspace roles

Workspace roles apply everywhere in the workspace. Assign the narrowest role that still lets someone do their job.

Role	Description	Key permissions
Owner	Holds full control. One person owns each workspace.	Transfers ownership, deletes the workspace, manages billing, and performs every admin operation.
Admin	Manages team members, models, and workspace settings.	Invites and removes members, configures models, manages secrets and connectors, and reads audit logs.
Operator	Manages agent deployments and watches production.	Deploys agents, reads analytics, manages environment variables, and views sessions.
Member	Builds and tests agents inside assigned projects.	Creates and edits agents, runs tests, and manages project-level resources.
Viewer	Reads workspace resources without changing them.	Views agents, project configurations, and analytics dashboards.

Project roles

Project roles apply inside one project. A member can hold different project roles in different projects.

Role	Description	Key permissions
Admin	Holds full control over the project’s resources and settings.	Manages every project resource, configures settings, and oversees operations.
Developer	Creates and modifies agents, tools, workflows, and project assets.	Builds and updates agents, tools, workflows, and assets.
Tester	Reads project resources and runs simulations and evaluations.	Reaches project resources, runs tests, and validates agent behavior.
Viewer	Reads the project without changing it.	Views project resources and configurations.

How workspace and project roles interact:

Workspace Owners and Admins hold workspace-wide authority and can administer every project without joining it.
Other workspace members need explicit project membership before they reach a project.
Whoever creates a project becomes its Admin and can add other workspace members from Settings -> Members.

Managing members

Only workspace Owners and Admins manage team membership. Everything in this section needs one of those two roles.

View current members

Go to Settings -> Team -> Members. The list shows each member’s name and email, workspace role, status, and join date. Status covers active, suspended, locked, and deactivated.

Invite a member

Invitations carry the role you choose, so decide the role before you send one rather than correcting it afterward.

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

The invitee receives an email holding a unique link that names the workspace and their assigned role. Invitations expire after 7 days, and the platform clears expired ones 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 and restarts the 7-day expiry.
Revoke	Cancels the invitation so nobody can use the link.

If a member reports that the invitation never arrived, find it in the pending list and resend. You don’t need to revoke it first.

Change a member’s role

A role change takes effect immediately. The member’s permissions update on their next page load or API call.

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

Rules the platform enforces:

You can’t assign a role above your own. An Admin can’t promote anyone to Owner.
Only the workspace Owner promotes a member to Admin.
Only the workspace Owner transfers ownership.
You can’t demote yourself. Ask another Owner or Admin to change your role.

Remove a member

Removing a member cuts their access at once, so confirm the person no longer needs the workspace before you start.

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

What happens when you remove a member:

They lose access to every workspace resource immediately.
The platform drops their project memberships inside this workspace.
Resources they created, such as agents and knowledge bases, stay in the workspace.
Sessions they started keep running, but they can’t start new ones.

Removing a member doesn’t delete their Agent Platform account. They keep access to any other workspace they belong to.

Transfer workspace ownership

Only the current workspace Owner transfers ownership, and the transfer changes both people’s roles at once.

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

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

Role management

Role Management decides what people can see and do across your workspace and projects. Roles come in two types.

Custom roles, which you define yourself.
System roles, which the platform provides and which cover the most common access levels.

Find Role Management under Settings -> Role Management.

Custom roles

Custom roles let you build access levels that match your team, such as a role that only reads configuration or one that releases to a limited set of environments. The Custom roles tab lists every custom role in your workspace, showing its name and description, how many permissions it carries, when someone created it, and quick actions to edit or delete it.

Creating a custom role

Select + Create Role to open the creation panel, then complete these fields.

Role name, a short identifiable name.
Description, optional context for what the role does. It earns its place once you hold several similar roles.
Parent role, optional. Base the role on an existing custom role to inherit its permissions, or choose No parent role to start from nothing. The panel shows the resulting parent chain, so you can see what you’re inheriting before you save.

Assigning permissions

The panel groups permissions by category. Select the actions this role may perform. A running count at the bottom tracks how many you’ve selected. The picker gives identifiers without describing them. See the Permissions reference for what each permission grants, which ones reverse a protection, and which ones to keep apart from one another.

The picker shows permissions outside your own role’s grant scope but won’t let you select them. You can’t grant access you don’t already hold.

Scoping release environments

Release scoping decides where a role may push configurations, which matters most for production. When the role includes the Workbench release permission, you can also restrict where it releases configurations, across Development, Staging, and Production. The scoping covers release actions only. It grants no production access on its own, and you must still select the underlying release permission separately. Select Create to save the role, or Cancel to discard it.

System roles

The System roles tab lists the built-in roles, grouped by where they apply. You can’t edit or delete them, but you can expand any role to see the grants it carries. Select View grants next to a role to read its full permission list.

When to use custom or system roles

Choose a system role whenever a built-in option already matches what someone needs. System roles need no setup and stay current on their own. Build a custom role when you need finer control, such as read-only access to a subset of permissions, a role scoped to specific release environments, or a role that extends another custom role through a parent chain.

Security and compliance

Go to Team -> Security & Compliance to manage authentication and access controls. The page carries two tabs: SSO and Audit Logs. Required role: Owner or Admin.

Single sign-on

SSO lets your users authenticate through an external identity provider. Plan requirement: Enterprise plan only.

Only organization owners or admins can manage SSO for a workspace. Other roles see the SSO tab as read-only.

Generated SSO URLs The platform generates these endpoints itself, so you create and edit nothing here. Use the URLs when you configure your identity provider’s SAML or OIDC application settings. Only organization owners and admins can see and use them. Selecting Refresh reloads the current values but neither regenerates nor changes them.

SSO protocol	URL	When to use it
SP Entity ID / Audience URI	`https://example.com/api/sso/saml/sp/spId`	Enter it as the Entity ID, Identifier, or Audience URI in your identity provider. It identifies the Agent Platform service provider and lets the identity provider confirm that a SAML assertion targets this application.
SP-initiated ACS URL	`https://example.com/api/sso/saml/callback`	Enter it as the Assertion Consumer Service URL or Reply URL in your identity provider for service-provider-initiated sign-ins.
IdP-initiated ACS URL	`https://example.com/api/sso/saml/callback`	Enter it as the Assertion Consumer Service URL in your identity provider for identity-provider-initiated sign-ins.
SAML metadata URL	`https://example.com/api/sso/saml/metadata?metadataId=<metadataId>`	Give it to your identity provider so it imports the service provider metadata automatically, covering the entity ID, ACS URLs, supported bindings, and signing certificates.
OIDC redirect URL	`https://example.com/api/sso/oidc/callback`	Enter it as the Redirect URI or Callback URL when you configure an OpenID Connect identity provider.

Choose a protocol Under SSO Protocol, select the protocol your identity provider uses:

Protocol	Description
SAML 2.0	For enterprise identity providers like Okta, Azure AD, and OneLogin.
OpenID Connect	For OIDC-compatible identity providers.

Then select an Identity provider from the dropdown. Choosing Custom SAML 2.0 lets you enter the IdP SSO URL, entity ID, and certificate details manually. SAML Configuration

Field	Description
SSO Entry Point URL	Your identity provider’s SAML SSO URL.
Issuer / Entity ID	Your identity provider’s issuer or entity ID.
X.509 certificate 1	The signing certificate your identity provider uses.
X.509 certificate 2 (rotation)	Optional. A second signing certificate, used to rotate certificates without downtime.

Up to 2 signing certificates are accepted. Select Save Configuration to store the values. Once saved, use Test configuration to verify the connection, Activate SSO to turn it on, or Pause SSO to turn it off without deleting the configuration. Set up OIDC SSO Go to Team -> Security & Compliance -> SSO, select OpenID Connect, enter the configuration details, and select Save Configuration. Domain verification Use the Domain Verification section in the SSO tab to claim and verify your organization’s email domain before you enforce SSO. SSO Access Policy Control workspace access behavior after successful SSO authentication. These settings save separately from your provider credentials.

Setting	Description	Default
Force SSO	Require all users to sign in via SSO.	Disabled
Auto-accept pending invites	Automatically accepts a single pending invitation for a user who signs in via SSO but has no workspace membership yet.	Disabled

Once you enable Force SSO:

Verified domain users lose password-based login.
Users outside the verified domain carry on as before.
Workspace Owners keep password-based login as a fallback.

Select Save Access Policy to apply changes. Google authentication fallback Turn on Allow Google fallback so users can sign in with Google when your SSO provider is unavailable.

Audit logs

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

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

Select Refresh to reload the log, and Export CSV to download the view you’re currently filtering. Use the filter bar to narrow results by search text, date range, action type, preset, or category.

Summary metrics

These five figures sit above the log and describe the view your filters produce.

Metric	Description
Matching events	Counts every event your current filters match.
Failed on page	Counts the failed events on this page.
Actors on page	Counts the distinct actors on this page.
Active filters	Counts the filters you’ve applied.
Last event	Times the most recent event.

Event categories

Categories group actions by the part of the platform they touch, which is how you narrow a broad search quickly.

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

Log table columns

Each row records one action, and these columns tell you who did what, where, and when.

Column	Description
Timestamp	Times the action.
Category	Names the event category.
Action	Names the specific action, such as `agent.dsl_updated`.
Actor	Identifies the user or system that acted.
Target	Names the resource the action affected.
Project	Names the associated project.
Source	Names the origin, either Studio or runtime-store.
IP	Records the request IP address.
Trace	Records the trace ID when one exists.

Retention

Retention decides how far back an investigation can reach, so check it before you rely on the log for compliance evidence.

Audit logs follow the workspace retention policy.
Professional and Enterprise plans keep at least 90 days.
Contact support to extend retention.

Key management

The Key Management Service lets you control the encryption keys that protect sensitive workspace data. Rather than relying on platform-managed keys, you can supply 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 to configure the tenant-level KMS. The provider you choose decides which fields the page shows. 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

Use the platform-managed KMS provider. This mode stores no tenant-specific external key connection.

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

AWS KMS

AWS KMS signs and wraps with a customer managed key you already hold in AWS.

Field	Description
AWS Region	Names the AWS region that hosts the key.
KMS Key ARN	Holds the full ARN of the CMK, such as `arn:aws:kms:us-east-1:123456789:key/abcd-1234`.
Credential Overrides (JSON)	Optional. Overrides the platform’s default AWS credentials with a JSON object.

Azure Key Vault

Azure Key Vault holds the key, and the auth method you choose decides whether the platform reaches it through your own service principal or its own managed application.

Field	Description
Key Vault URL	Points at the vault.
Azure key version (optional)	Pins this scope to one Azure key version using the 32-character hexadecimal version ID. Leave it empty to follow Azure’s current key version.
Key Name	Names the key inside the vault.
Auth Method	Chooses Service Account / Service Principal or Platform workload identity.

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 through admin consent, then assign the Key Vault Crypto User role on the target key vault.

Field	Description
Tenant ID	Identifies the Azure directory.
Client ID	Identifies the application.
Credential type	Chooses Client secret or Certificate (PEM).
Client Secret	Required when you choose Client secret.

Platform workload identity Enter the customer Entra directory ID. The platform uses its own managed Azure application, so you supply no client ID, secret, or federated credential.

Field	Description
Customer Entra directory ID	Identifies the customer’s Azure directory.

Your Azure administrator must grant the platform’s managed Azure application access to the target key vault. Select Test Connection to verify the provider connection before you save the configuration.

Azure Managed HSM

Azure Managed HSM stores the key in dedicated hardware, which suits compliance regimes that won’t accept a software-backed vault.

Field	Description
Managed HSM URL	Points at your HSM instance endpoint.
Azure key version (optional)	Pins the scope to a specific Azure key version using the 32-character hexadecimal version ID. Leave it empty to follow Azure’s current key version.
Managed HSM Key Name	Names the key to use.
Auth Method	Chooses Service Account / Service Principal or Platform workload identity.

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 through admin consent, then assign the Key Vault Crypto User role on the target key vault.

Field	Description
Tenant ID	Identifies the Azure directory.
Client ID	Identifies the application.
Credential type	Chooses Client secret or Certificate (PEM).
Client Secret	Required when you choose Client secret.

Platform workload identity Enter the customer Entra directory ID. The platform uses its own managed Azure application, so you supply no client ID, secret, or federated credential.

Field	Description
Customer Entra directory ID	Identifies the customer’s Azure directory.

Google Cloud KMS

Google Cloud KMS holds the key, and the platform addresses it through its full resource path rather than a name.

Field	Description
Location	Names the GCP location.
Key Resource Name	Holds the full resource path, such as `projects/my-project/locations/us-east1/keyRings/my-ring/cryptoKeys/my-key`.
Auth Method	Chooses Default Credentials or Service Account / Service Principal.
Credential Overrides (JSON)	Optional. Overrides the default credentials with a JSON object.

External KMS

Connect any REST-compatible KMS, whether you host it yourself or consume it as a service.

Field	Description
External KMS Endpoint	Holds the base URL of the external KMS.
External Key ID	Identifies the key at the external provider.
Auth Method	Chooses API Key, mTLS, OAuth2 Client Credentials, or HMAC-SHA256.
Credential Overrides (JSON)	Optional. Holds a JSON object carrying provider-specific credential fields.

External endpoint validation Before you save the tenant KMS configuration, enter the endpoint, key ID, and auth method, then select Validate Endpoint to confirm that the platform reaches and authenticates with the external provider.

Policies

These two settings decide how the platform behaves when the KMS becomes unreachable and which compliance profile it applies.

Setting	Options	Default
Failure Policy	Fail Closed, which stops all encryption and decryption. Graceful Degradation, which continues with cached DEKs until the KMS reconnects.	Fail Closed
Compliance Level	Standard, PCI DSS, HIPAA, GDPR, SOC 2, NIST SP 800-57, FIPS 140-3	Standard

Rotation and re-encryption settings

Keys rotate automatically when your provider supports scheduled rotation, or manually when you create a new key version on demand from the Encryption Keys tab. Tune how often the platform generates DEKs, how long a KEK may live, and whether retired DEKs are ever destroyed.

Setting	Description
DEK Epoch Interval (hours)	Sets how often the platform generates a DEK, in hours.
DEK Max Usage Count	Caps how many times a DEK is used before it rotates.
KEK rotation policy (days)	Sets how often the KEK rotates, in days.
Last KEK rewrap completed	Read-only. Times the most recent KEK rewrap, or reads `Never` when none has run.

Re-encryption also carries Concurrency, which sets parallel jobs, Batch Size, which sets records per batch, and Max Retries, which sets how many times a failed job retries. Select Save Configuration to apply your changes.

Scopes

Scopes let you run different KMS providers for tenant environments, projects, and project environments, so one project can hold its own key without changing the rest.

Environment variables

Environment variables are key-value pairs that inject configuration into your agents and tools, so you don’t hardcode values in ABL definitions. Use them for endpoints, feature flags, timeouts, and anything else that differs between environments. The platform resolves them at runtime and scopes them by environment and project. A variable takes its identity from its key within a project. It can carry a Global value that every environment shares, plus optional values for Development, Staging, and Production. When a key holds both a global value and an environment-specific one, the environment-specific value wins. Environment variables behave as follows:

Environment-specific. One key carries different values in development, staging, and production.
Encrypted at rest. The platform encrypts stored values using AES-256-GCM.
Resolved at runtime. The agent resolves values when it runs.
Immediately effective. Changes reach new agent sessions without a redeploy.

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

Add environment variables

Adding a variable takes five steps, and the namespace you choose at step 4 is the one decision you can’t change afterward without recreating the variable.

Go to Workspace Settings -> Env Variables.
Select the project.
Select the target environment, or create a global variable that covers every environment.
Select Add Variable. The platform adds the variable to the Default namespace. To use a different namespace, select it from the Namespace dropdown before you create the variable.
Enter the following details, then select Save.

Field	Description
Key	Names the variable uniquely within the selected project and environment. The key must start with a letter, contain only letters, numbers, and underscores, and stay unique inside the project and environment.
Value	Holds the value the variable carries for the selected environment.
Description	Tells project collaborators what the variable is for.
Secret	Masks the value after you save it. Turn it on for anything sensitive.

Reference environment variables

Reference a variable using {{env.KEY}} syntax. The agent resolves it at runtime based on the active deployment environment. You can reference environment variables in these constructs:

HTTP tool endpoint, headers, auth, and request body
MCP tool call arguments
RESPOND text and rich content, covering quick replies, cards, forms, and KPI or chart widgets
ESCALATE and handoff messages, GATHER re-prompts, and guardrail block or redirect messages
Agent persona, goal, and limitations, meaning the 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

Select the Edit icon next to a variable to change its value, description, or secret setting. Your change reaches new agent sessions immediately.

Sessions already running keep the values they resolved when they started, and only new sessions pick up your change. HTTP tools and MCP tools are the exception and use the updated values as soon as you save.

Delete a variable

Select the Delete icon and confirm.

Before you delete a variable, confirm that nothing references it. Anything that references a deleted variable hits a runtime resolution error.

Import or export environment variables

A bulk import creates or updates many variables at once, which saves you entering them one by one when you set up a new environment.

Select Import.
Select the target environment.

Paste the keys in JSON format, as shown below.

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

Review the import preview.
Select Import.

You can also export environment variables as a .json or .env file.

Variable namespaces

Namespaces organize environment variables into groups, which keeps a large set navigable. Every project holds a default namespace, and you can create up to 25 namespaces per project.

Create a namespace

Go to Settings -> Environment Variables.
Select Namespaces.
Select New Namespace.
Enter a namespace name, display name, description, and color.
Select 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 or system roles

​Security and compliance

​Single sign-on

​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 or system roles

Security and compliance

Single sign-on

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