Secrets store sensitive values such as API keys, tokens, passwords, and configuration values. They are the most commonly used resource in Secryn and are designed to be secure, versioned, and easy to manage across teams and environments.

Every secret belongs to a vault, and access to a secret is always evaluated through the project, vault, and role-based access rules.

What Secrets Are Used For

Secrets typically store:

• API keys and access tokens
• database credentials
• application configuration values
• third-party service credentials
• any value that should not be stored in source code

Secrets are treated as sensitive data at all times and are never exposed publicly.

Secret Structure

A secret consists of:

• a name (unique within the vault)
• a value
• optional metadata such as a description or expiration date

The name is used to reference the secret programmatically, while the value is securely stored and versioned.

Versioning and History

Every time a secret is updated, Secryn automatically creates a new version. All previous versions are preserved and can be reviewed or restored at any time.

Versioning allows you to:

• roll back accidental changes
• audit historical values
• safely rotate credentials

Restoring a previous version creates a new active version rather than deleting history.

Viewing and Masking

By default, secret values are masked in the web interface to reduce the risk of accidental exposure. Authorized users can choose to reveal values when needed. Read-only users can view secret metadata but cannot modify values.

Expiration and Notifications

Secrets can have optional expiration dates. When configured, Secryn monitors expiration and sends notifications to administrators, project managers, and the user who created the secret. Expiration reminders help prevent outages caused by expired credentials.

Accessing Secrets

Secrets can be accessed via:

• the Secryn web UI for manual management
• the REST API using a vault access key
• the MCP server for agent-based or automated access

API consumers can fetch full secret values or request only names and IDs to minimize exposure.

Public Access

Secrets cannot be made public. Unlike keys and certificates, secrets are always protected behind vault access controls and require authentication.

Permissions and Roles

• Administrators and Project Managers can create, update, restore, and delete secrets.
• Contributors can create and update secrets in vaults they can access.
• Read-only users can view metadata only.

Restricted vault rules apply on top of role permissions.

Best Practices

• store only sensitive values in secrets
• use meaningful names that reflect usage
• rotate secrets regularly using versioning
• apply expiration dates where possible
• use restricted vaults for highly sensitive data

Secrets form the core of Secryn’s value. Combined with versioning, access control, and audit logging, they provide a secure and reliable way to manage sensitive configuration data across your organization.