Security

Use encryption, narrow access scopes, version history, and audit evidence together to reduce secret exposure.

Storage model

Secret values are encrypted on the server before storage. The data model retains encrypted values and a non-sensitive preview so the dashboard can identify a credential without displaying the complete value.

Stored
├── encrypted_value
├── value_preview
├── version metadata
└── audit metadata

Not stored
└── plaintext database copy

Encryption is one layer

Encryption at rest does not replace access control, careful token handling, output hygiene, or regular credential rotation.

Access boundaries

Workspace roles

Limit administrative actions and membership management to the people responsible for them.

Project scope

Keep unrelated services in separate projects so credentials are not shared by default.

Environment scope

Separate development and production values and verify the selected environment before writes.

Audit history

Review reads, changes, rollbacks, token activity, and project events without logging secret values.

Token practices

Create a distinct token for each automation or deployment system.
Grant only the project, environment, and access mode it needs.
Pass ephemeral tokens through UNBE_TOKEN; do not print them.
Rotate or revoke tokens when a system or owner changes.
Never commit local .unbe/ configuration.

Operational safety

Prefer runtime injection with unbe run. If a legacy tool requires a file, write it only to an ignored path, limit file permissions, and remove it when the process no longer needs it. Avoid--values and secret-pull commands in verbose CI logs.

Incident response

Rotate the exposed credential at its upstream provider.
Update the affected Unbe secret and restart dependent workloads.
Revoke any exposed Unbe token or remove compromised membership.
Use audit history to determine the access window and affected scope.
Remove leaked values from logs or repositories where possible.