> ## Documentation Index
> Fetch the complete documentation index at: https://koreai-agentplatform-dev.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 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.
1. Select **Invite member**.
2. Enter the invitee's email address.
3. Select a role: Admin, Operator, Member, or Viewer.
4. 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.
1. Find the member in the Members list.
2. Select the role dropdown next to their name.
3. 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.
1. Find the member in the Members list.
2. Select the three-dot menu next to their row.
3. 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.
1. Go to **Settings** -> **Team** -> **Members**.
2. Select the three-dot menu next to the target member.
3. 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](/agent-platform/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=` | 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](/agent-platform/deployment)** 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.
1. Go to **Workspace Settings** -> **Env Variables**.
2. Select the project.
3. Select the target environment, or create a **global** variable that covers every environment.
4. 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.
5. 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**
```xml theme={null}
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**
```xml theme={null}
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**
```xml theme={null}
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.
1. Select **Import**.
2. Select the target environment.
3. Paste the keys in JSON format, as shown below.
```xml theme={null}
[
{"key": "API_KEY", "value": "sk-xxx", "isSecret": true},
{"key": "DB_URL", "value": "postgres://..."}
]
```
4. Review the import preview.
5. 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
1. Go to **Settings** -> **Environment Variables**.
2. Select **Namespaces**.
3. Select **New Namespace**.
4. Enter a namespace name, display name, description, and color.
5. Select **Create**.