Managing Secrets

Secrets in Secryn store sensitive values such as API keys, database credentials, tokens, and configuration data. Secrets belong to a vault and are governed by project-level access and optional restricted vault rules.

Secrets are versioned and immutable. Every change creates a new version while preserving history.

Creating a Secret

To create a secret:

• Navigate to a Project
• Open a Vault
• Click New Secret
• Provide:
  • Name (unique within the vault)
  • Value
  • Optional tags
  • Optional activation / expiration settings
• Save

Once created:

• The secret becomes active immediately unless scheduled.
• The initial version is recorded.
• An audit log entry is created.

Secret Versioning

Secrets support full version history.

How Versioning Works

• Every update creates a new immutable version.
• Previous versions are permanently retained.
• Restoring a version creates a new version.
• Versions cannot be deleted.

Versioning ensures:

• Rollback safety
• Audit traceability
• Operational confidence

Only the current active version is returned via API or UI by default.

Updating a Secret

When updating a secret:

• The existing version remains unchanged.
• A new version is created with the updated value.
• The previous version is preserved.
• An audit log entry records the change.

There is no "in-place editing."

Restoring a Previous Version

To restore:

• Open the secret
• View Version History
• Select a previous version
• Click Restore

Restoring:

• Does not overwrite history
• Creates a new version using the selected value
• Preserves all previous versions

Enabling and Disabling Secrets

Secrets can be enabled or disabled.

• Enabled -> available via UI and API
• Disabled -> not returned by API

Disabling does not delete versions.

Activation and Expiration

Secrets may have:

• Activation time (when the secret becomes active)
• Expiration time (when it should no longer be used)

Expiration:

• Does not delete the secret
• Can trigger notifications (if configured)
• Is recorded in logs

Tags

Secrets can be tagged for organization and filtering.

Tags:

• Do not affect access control
• Improve search and grouping
• Help with environment separation

Access Control

Access to secrets is determined by:

• Project membership
• User role (Admin, Project Manager, Contributor, Read-only)
• Vault rules (including Restricted Vaults)

Secrets do not support public URLs.

Accessing Secrets via API

Secrets can be retrieved using:

• Vault-scoped access keys
• Authenticated API requests
• MCP clients

By default:

• All secrets and their values are returned.

If only names are required, the API supports name-only responses.

Access is fully logged.

Security Model

Secrets in Secryn are designed with:

• Immutable version history
• No hard deletion
• Full audit logging
• Explicit access control
• Vault-level isolation

Secryn prioritizes auditability and operational safety over convenience.

Best Practices

• Store production secrets in restricted vaults
• Rotate secrets periodically
• Use access keys for automation, not user credentials
• Monitor audit logs regularly
• Avoid embedding secrets directly in code