Workspace and project secrets

Give chats and scheduled jobs the credentials they need to reach the outside world.

What a secret is for

When a chat or a scheduled job has to reach something outside app.evriq.ai -- a mailbox, an API, a database -- give it the credential as a secret. A job that fires at 07:10 has its credential at 07:10, with nobody there to unlock anything.

Two scopes

• A workspace secret reaches every chat, session and job in the workspace. Administrators set it under Settings → Secrets.
• A project secret reaches only the sessions and jobs of that project. An administrator, or anyone who works in the project, sets it in the project's Secrets section.
• If both scopes hold a secret of the same name, the project's value wins for that project.

What a turn gets, and what is hidden

Each secret arrives as an environment variable of its own name in every agent turn and job run it applies to. That means an agent running in that session can read the value: give a secret only to work you would trust with it.

Values are write-only in the app: once saved, a value is never shown again, in the page, the API or the audit log, and replacing one means typing a new value over it. Values are stored encrypted. Agents receive each secret as a plain environment variable. The exact value, and its base64 and percent-encoded forms, are masked out of what a chat says or prints, on a best-effort basis: a value shorter than four characters cannot be masked, and an agent that splits, hashes or otherwise re-encodes a value can still print it in a form that is not recognised. Every change and every read into a turn is recorded by name, never by value.

A public identifier is not a secret

Some values a job needs are not credentials: a public social handle, an account id. If such a value is also written into a file, the check that stops a push from publishing a secret would refuse it. An administrator can tick This is not a secret when saving it (or run evriq secrets set NAME --not-secret): it is still delivered as an environment variable, but it is not masked out of output and it is allowed in commits. Turning that protection off is audited.

If a push is refused because a value appears in a file, the message names the secret, the file and the line, and one decision is filed for you: remove the value from the file, or mark that secret as not sensitive if it is a public identifier.

How this differs from the Vault

Settings → Vault is the older, passphrase-locked store: its secrets are handed to a repo's agents only while an administrator has it unlocked (unless a secret is marked long-lived), and are granted repo by repo. Secrets need no passphrase and no grant: they are for anything that has to work unattended. Use Secrets unless you specifically want the passphrase lock.

Providers & keys holds the credentials the product itself uses to pay for models (Provider API keys, Model providers) and to reach git hosts. Secrets are for the credentials your own work needs.

From a terminal

evriq secrets list|set <NAME>|delete <NAME> [--project <name>], the value read from standard input, never from the command line.