Project Vault
The Project Vault provides per-project encrypted credential storage. Store API keys, tokens, certificates, and other secrets that project agents can access at runtime during tool execution.
Why Project Vault?
Cross-organization projects (federated via SLIM) often need credentials that don't belong to any single workspace. For example:
- An agent from Org 1 pushing to Org 2's GitHub repository needs a deploy token
- A project-specific API key for a third-party service shared across multiple participating organizations
- Milestone-scoped credentials that should only be available during a specific phase
The Project Vault solves this by storing credentials at the project level, isolated from both tenant-level and workspace-level secrets.
Security
| Feature | Description |
|---|---|
| Encryption | All values encrypted with AES-256-GCM before storage. Plaintext never touches the database. |
| Masked display | The UI and API always return masked values (e.g., sk-****abc). Full values are only decrypted at agent runtime. |
| Expiry enforcement | Expired secrets automatically return null when an agent attempts decryption. |
| Access control | Project members get access via OpenFGA. RACI roles map to authorization levels. |
| Cascade delete | When a project is deleted, all vault entries are automatically removed. |
Categories
| Category | Typical Use |
|---|---|
| API Key | Third-party service API keys |
| Access Token | OAuth tokens, personal access tokens |
| Secret | Generic secrets, signing keys |
| Certificate | TLS certs, client certificates |
| Password | Service account passwords |
| Webhook Secret | Webhook verification secrets |
| Other | Anything else |
Scoping
| Scope | Visibility |
|---|---|
| Project | All agents assigned to the project can access |
| Milestone | Only agents working on the specified milestone can access |
How Agents Access Vault Secrets
During coding sessions: When a coding session is started with a project ID, all non-expired vault entries are automatically injected as environment variables into the sandbox. BYOK (workspace-level) keys take priority -- project vault only fills gaps for keys not already provided.
During tool execution: Agent tools resolve secrets by name at execution time when they need a credential for an external service.
Managing Secrets
Adding a Secret
- Open a project and navigate to the Vault tab
- Click Add Secret
- Fill in the details:
| Field | Required | Description |
|---|---|---|
| Name | Yes | Unique identifier within the project (e.g., GITHUB_TOKEN). Agents reference secrets by this name. |
| Value | Yes | The secret value. Encrypted immediately on submission. |
| Description | No | Human-readable note about what this secret is for. |
| Category | No | Organizational label for filtering. |
| Scope | No | project (default) or milestone to restrict to a specific phase. |
| Expires At | No | Optional expiry date. After this date, agents cannot decrypt the secret. |
Rotating a Secret
Click the rotate icon on any secret row to replace its value. The old value is permanently overwritten. The name stays the same, so agents that reference it continue working without changes.
Deleting a Secret
Click the delete icon and confirm. The secret is permanently removed and agents lose access immediately.