Project → Project Settings → Project Vault. The Workspace Library has a Library Vault for secrets that several projects share. LLM provider keys are not vault secrets; configure them on each model under LLM Models.
Overview
Encrypted Storage
Secret values are encrypted before being stored. They cannot be read back through the UI or API, only updated or deleted.
Selective Assignment
Assign secrets to specific workflows, agents, and MCP servers, or make them available globally for all executions.
Environment Injection
Secrets are injected as environment variables at runtime. Reference them in MCP server configs using syntax.
LLM-Safe
Secret values are never sent to the AI model. They exist only in the execution sandbox as environment variables.
Creating a Secret
Open the Project Vault
Open the project, then go to Project Settings → Project Vault.
Add a new secret
Click New Secret and enter a name and value.
Name format
Secret names must start with an uppercase letter and contain only uppercase letters, numbers, and underscores. For example:
API_KEY, GITHUB_TOKEN, DB_PASSWORD_PROD.Set availability
Toggle Available for All Executions to make the secret accessible to every workflow and agent automatically. When disabled, you must explicitly assign the secret to specific workflows or agents.
Secret values have a maximum size of 10KB. Once created, the name cannot be changed, only the value can be updated.
Assigning Secrets
Secrets can be scoped in two ways:Global Availability
Toggle Available for All Executions on a secret to inject it into every workflow run in the project automatically. Use this for shared credentials that most workflows need, such as a third-party API key used across multiple MCP servers. On a Library secret the same toggle applies to every run in every project, and its tag reads Available for All Executions in All Projects.Per-Workflow, Per-Agent, and Per-MCP Server
For secrets that should only be available to specific workflows, agents, or MCP servers:Assign to a workflow
Open the workflow settings, scroll to the Secrets section, and add the secrets this workflow needs.
Assign to an agent
Open the agent settings, scroll to the Secrets section, and add the secrets this agent needs.
Assign to an MCP server
Open the MCP server settings, scroll to the Secrets section, and attach the secrets this server needs.
Referencing Secrets
Use the${VAR_NAME} syntax to reference vault secrets in MCP server configurations. At runtime, Overcut replaces each placeholder with the actual secret value.
Example MCP server config referencing vault secrets:
${FIGMA_API_KEY} is replaced with the decrypted value from the vault. The LLM never sees the actual key, only the tool interface exposed by the MCP server.
Project Vault and Library Vault
A project’s agents, MCP servers, and workflows can attach secrets from the Project Vault and from the Library Vault; Library secrets carry a Library badge in the picker. A Library MCP server or agent can attach Library secrets only. At run time Overcut collects secrets from both vaults, and a project secret with the same name as a Library secret wins in that project’s runs. The project secret’s row shows Overrides the library value in this project’s runs. To share a project secret with every project, select Promote to library on its row. The value is not re-entered and existing assignments keep working. See Workspace Library for promotion order and the all-executions warning.Context parameters and Vault secrets
Use a context parameter for visible, reusable plain-text configuration such as a base branch, a reviewer list, or naming conventions. Context parameter values appear in prompts and run logs. Use the Vault for anything that must stay hidden.Security Model
Encryption at Rest
All secret values are encrypted before being written to the database. Decryption only happens at execution time through an internal, authenticated endpoint.No Read-Back
Secret values cannot be read back through the UI or API. The vault only tells you whether a value exists (hasValue). To change a secret, you enter the new value; you cannot view the current one.
Audit Trail
Every vault operation (create, update, delete, toggle availability) is logged with the secret name (never the value), project ID, and the user who performed the action. Use Audit Trail to review secret-change events and understand why sensitive values may be redacted or omitted from event details.LLM Isolation
Secrets are injected as environment variables into the agent’s sandbox process. The AI model interacts with tools and APIs through those processes but never receives the secret values in its prompt or context.Output Filtering
Secret values are automatically filtered from tool outputs before they reach the model. If a tool accidentally returns a response containing a secret value, Overcut redacts it so the secret is never exposed in the conversation or logs.Best Practices
- Use the vault for all credentials: never place API keys, tokens, or passwords in MCP server configs, agent instructions, or context parameters.
- Prefer per-workflow/per-agent assignment over global availability when a secret is only needed by a few workflows. This follows the principle of least privilege.
- Use descriptive names that make it clear what the secret is for:
DATADOG_API_KEYis better thanKEY_1. - Rotate secrets by updating the value in the vault. All workflows and MCP servers referencing that secret will pick up the new value on their next execution. No config changes needed.
Next Steps
- Multi-Project Workspaces: where the Project Vault fits in the workspace-vs-project boundary.
- MCP Servers: connect external tools to your agents and reference vault secrets in their configuration.
- Workspace Library: the Library Vault and how shared secrets resolve.
- Context Parameters: plain-text values that are safe to show in prompts.
- Core Building Blocks: understand how agents, actions, and triggers connect.