Why secrets must not enter model context
Pasting an API key, database password, or SSH key into a chat sends it into model requests, history, logs, and possibly exported files. LoneAct works the other way around: secrets are held in LoneAct secure storage, the model sees only a name or a reference, and the executing process receives the value when it needs it.
Secrets can drive tools but do not enter model context; the model can ask to use a secret but cannot read its value.
Two kinds of secrets, one boundary
Provider keys
Used for model services, your own model key, or external service connections. Managed by platform or LoneAct secure storage; the interface shows only status and a fingerprint.
Project Secrets
Environment variables and mounted files that you and your team maintain in Settings → Secrets for commands and tools the Agent runs.
Neither kind should appear in plaintext in conversations, rules, memory, or source repositories. The difference is only where they are managed and how they are used.
Add an environment variable or mounted file
Open Settings → Secrets
Choose the scope for the current project or all projects, then choose Environment variable or Mounted file.
Fill in name and value
The name is the variable name in the executing process, for example DATABASE_URL or DEPLOY_TOKEN. The value is entered only once, when you save.
Choose the scope
Enable it for the current project only, or let all projects use it. Once disabled, new processes no longer receive the variable.
Let the Agent use it
Reference the variable name in tools, terminal, or MCP configuration instead of writing the value into a prompt or script.
If you already have a .env file, use Import .env to bring values in bulk; for duplicate names you can choose to skip or overwrite. Imports follow the same secure storage and scope rules afterwards.
Reference secrets in a task
Enabled environment variables are injected into processes that LoneAct starts. Tools and terminals can read environment variables directly; when you need an explicit reference, use one of these forms:
$DATABASE_URL
${secret:DATABASE_URL}
secret://DEPLOY_TOKEN
${secretFile:SSH_KEY}| Form | Purpose |
|---|---|
$NAME | Process environment variable, for shells and tools that read environment variables |
${secret:NAME} | Explicitly reference an environment variable Secret |
secret://NAME | Resolved by tools or configuration that support Secret references |
${secretFile:NAME} / secretfile://NAME | Reference a read-only mounted file, such as a certificate or SSH key |
These references can appear in Agent instructions or tool arguments, but resolution happens on your computer at execution time. The model sees only the reference text, never the resolved value.
Rotation, disabling, and audit
Rotation
After you update a secret, new processes use the new value; already running processes usually keep the old one, so restart affected tasks if needed.
Disabling
Disabling stops new processes from receiving the variable; revoke the key at the provider as well when you need to cut access immediately.
Audit
Review who changed a Secret and when; never put values in tickets, screenshots, or conversation records.
Do not configure production databases, cloud platform master accounts, or organization-level root keys as Secrets shared by all projects. Split by project and environment, and grant the least privilege.