Secrets

Store sensitive configuration through Lleverage's dedicated secret-management path instead of ordinary project content.

Use Secrets for values that should be treated as credentials or sensitive runtime configuration.

The Lleverage application database stores the secret key and a pointer to the secret store, not the secret value itself. The current implementation supports both GCP Secret Manager and OpenBao-backed pointers while that storage migration is in progress.

The product describes the intended guarantee directly: Secrets are encrypted at rest and are never exposed in the UI. Multi-line values such as PEM private keys can be stored exactly as entered.

Scope and access

Secrets can exist at organisation or Project scope. The Project page presents the relevant organisation and Project secrets together.

The current Secrets router is organisation-member scoped, not Project-Builder scoped. An organisation member who can reach a Project can currently list, create, update and delete Secrets for that Project. Do not assume the Project role alone is the enforcement boundary.

The Secrets list does not currently show whether an entry is organisation- or Project-scoped, even though both scopes exist. If scope matters, inspect the entry rather than inferring it from the list.

Secrets is not shown in the Control navigation on the Free plan.

Use the intended secret path

Do not put credentials in:

• Variables;

• Skill instructions or helper files;

• Workflow prompts or ordinary node content;

• Project files or Knowledge Bases;

• documentation.

Those surfaces have different visibility and persistence characteristics and do not provide the same storage guarantee.

The Variables route also blocks plaintext database-connection-string shaped values and directs you to Secrets instead. See Secrets and variables reference for the practical choice between Secrets, Variables and ordinary operational data.