Secrets and variables reference

Choose between Secrets, Variables and ordinary operational data based on sensitivity and purpose.

Choose the storage surface based on what the value is, not on which editor is most convenient.

The current Secret and Variable creation dialogs side by side: Secrets explicitly promise encrypted-at-rest storage and support multi-line sensitive values, while Variables are ordinary single-line configuration.

Value	Use	Why
API key, password, bearer token, client secret	Secret	Dedicated secret-management path; value is not stored in the application database
Non-sensitive reusable configuration	Variable	Easy to reference, but stored as ordinary plaintext application data
Business records and structured operational state	Table / connected system	Keeps operational data in a surface designed for records and queries
Documents and reference material	Files / Knowledge	Appropriate for content the Agent or Workflow needs to read
Process instructions	Skill / Workflow configuration	Appropriate for behaviour, not credentials

The product-level distinction

A Secret has no ordinary value field in the Lleverage application database; the record points to dedicated secret storage. The Secret dialog therefore states that Secrets are encrypted at rest and never exposed in the UI, and it accepts multi-line values such as PEM private keys.

A Variable is ordinary reusable configuration. Its value is stored as plaintext application data and the creation dialog is a normal single-line value input.

Lleverage also enforces one important boundary: a database-connection-string shaped value cannot be stored as a Variable. The Variables API directs you to Secrets so the value can be mounted from the secret-management path at runtime.

A simple test

If exposing the value to a Project user, model context, trace or export would create a credential leak, store it as a Secret and reference it from the configuration that needs it.

Do not make a secret “temporary” by putting it in a Variable, prompt, Skill file or Project document. Those surfaces have different access and persistence behaviour even when the value is used only once.

Scope and current access boundary

Both Secrets and Variables can exist at organisation and Project scope, and their Project pages merge the relevant entries from both levels.

The current Secrets and Variables routes are organisation-member scoped. An organisation member who can reach a Project can currently list, create, update and delete entries on these surfaces. That is broader than a simple “Builder/Owner only” mental model, so treat the page-specific permission as the source of truth.

The Variables list displays its scope explicitly; the Secrets list currently does not. Use names that make purpose clear and verify the intended scope when similarly named keys exist at both levels.