> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vegalake.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Secret vaults

> Store workspace secrets in namespaces and reference them safely from product configuration.

# Secret vaults

Secret vaults organize sensitive workspace configuration without embedding values in product definitions. The API calls the container a **namespace**; the dashboard presents it as a **Secret Vault**.

## Resource hierarchy

```text theme={null}
Organization → Workspace → Secret Vault (namespace) → Secret
```

Vault and secret operations are scoped by `org_id` and `workspace_id`. Permissions can apply to the namespace collection or a specific namespace instance.

## Recommended workflow

1. Create a vault for one application, environment, or responsibility boundary.
2. Grant only the identities that must manage or reference it.
3. Create a secret with a descriptive name and purpose.
4. Select the resulting secret reference from a VegaFlow connection form.
5. Update or rotate the secret without copying its value into the QuickFlow definition.

## Safety rules

* Never place secret values in documentation, screenshots, Git, logs, issue comments, or connection descriptions.
* Prefer a secret reference over pasting a credential into another resource.
* Separate read/use access from secret-management access where permissions allow it.
* Remove unused secrets and permissions after consumers migrate.
* Treat IDs and metadata as sensitive when they reveal infrastructure structure.

## Permissions

Collection permissions govern listing and creating vaults. Instance permissions govern access to a particular vault. A connection form may show only vaults and secrets visible to the current identity.

If a reference selector is empty, verify organization/workspace scope, vault permission, and whether a secret exists before recreating anything.