> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/administer-and-govern/control/secrets/reference.md).

# 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.](https://3370306531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlgSglJDQZxDZdn20CUcl%2Fuploads%2Fgit-blob-d5452466c07f59d8e8687d7d369c25d1ac258719%2Fcontrol-secrets-vs-variables.png?alt=media)

| 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.lleverage.ai/administer-and-govern/control/secrets/reference.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.