Vaults are containers within a project that store secrets, cryptographic keys, and certificates. They provide an additional layer of organization and access control beyond projects, allowing you to group sensitive resources by purpose, environment, or security level.

Every vault belongs to exactly one project, and all access to secrets, keys, and certificates is evaluated through the vault.

Purpose of Vaults

Vaults exist to:

• group related secrets, keys, and certificates
• separate concerns such as environments or services
• apply tighter access controls when needed
• provide clear audit and access boundaries

A project can contain multiple vaults, each serving a distinct purpose.

What a Vault Contains

Each vault can store:

• Secrets – sensitive values such as API keys and credentials
• Keys – cryptographic material for encryption, signing, or authentication
• Certificates – TLS or identity certificates and their private keys

All resources within a vault support versioning, expiration tracking, and audit logging.

Vault Access Model

Access to a vault is determined by:

1. user membership in the project
2. user role within the project
3. whether the vault is restricted

By default, users who belong to a project can access all vaults in that project, subject to their role permissions.

Restricted Vaults

A restricted vault is a standard vault with an additional access rule enabled. When a vault is marked as restricted, project membership alone is no longer sufficient to access its contents. Only users explicitly added to the restricted vault can view or manage the resources inside it.

Restricted vaults are useful when certain secrets, keys, or certificates require tighter control than the rest of the project.

When to Use Restricted Vaults

• the vault contains highly sensitive credentials
• access should be limited to a small subset of users
• regulatory or compliance requirements demand stricter separation
• you want to isolate production or security-critical resources

Restricted vaults do not change how resources are stored or accessed programmatically; they only affect who is allowed to access them.

Access Evaluation Order

When accessing a vault, Secryn evaluates permissions in the following order:

1. project membership
2. user role within the project
3. restricted vault membership (if enabled)
4. resource visibility (for public keys and certificates)

This layered approach ensures predictable and secure access behavior.

Vault Lifecycle

Vaults are created within a project and persist for the lifetime of that project. Access rules can be modified at any time, and resources within a vault can be added, updated, archived, or restored without affecting the vault itself.

Vaults provide a stable, auditable boundary for managing sensitive data over time.

Vaults are the primary workspace in Secryn. By combining projects, vaults, and restricted access rules, you can design a security model that scales from simple setups to complex, highly controlled environments.