Where Atrahasis Keeps Your API Secrets
Every API client asks you for secrets. A bearer token, a basic-auth password, an API key, a set of OAuth client credentials. You paste them into a field, hit send, and move on. The question nobody asks until it is too late is: where did that secret just go?
In most tools, the answer is simple and dangerous. It went into a file on your disk, in plain text, right next to the request that uses it.
The problem: a secret you typed is a secret you saved
The moment a credential lands in a saved request, it stops being something you typed and becomes something your machine stores. That file is now a liability, and it travels further than you think.
You commit your collection to Git so a teammate can use it. The token goes with it, into the repository, into the history, forever. Someone attaches the file to a bug report. Now the secret is in your issue tracker. You push a personal project to a public repo to show it off, and a scanner finds the key before you finish your coffee.
None of this requires a mistake. It is the default behavior working exactly as designed. And the cleanup is worse than the leak: rotating a credential that is already in Git history means force-rewriting history or, more honestly, revoking the key and hoping nothing broke. One careless save turns into an afternoon of damage control.
The safe habit, "just remember to strip your secrets before you commit," is not a solution. It is a tax you pay on every single save, and you only need to forget once.
The Atrahasis approach: the value never enters the file
Atrahasis starts from a different premise. A secret's value should never be written into the document you share in the first place. Not encrypted in it, not hidden in it. Not in it at all.
Instead of storing values, Atrahasis stores references. Your requests, flows, and specs point at a variable by name. The real value lives somewhere designed to hold secrets, your operating system's keychain or a dedicated secrets manager, and is resolved at the last possible moment, right before the request goes out.
This flips the safety model. You do not have to remember to keep secrets out of your files, because they were never in them. Sharing a spec, committing it, or handing it to a new teammate is safe by default, not safe if you were careful.
Here is what that looks like in practice.
References, not values
Anywhere Atrahasis accepts text, a URL, a header, a request body, a query parameter, or an auth field, you can write a variable reference with double curly braces:
Authorization: Bearer {{api_token}}
Nothing about {{api_token}} is sensitive. It is a pointer. Atrahasis resolves it at send time from the active environment, substitutes the real value into the outgoing request, and leaves your saved file holding only the reference. Switch environments and the same reference resolves to a different value, dev on your laptop, prod in your pipeline, without touching the file.
What the environment file actually stores
Open the file Atrahasis writes to disk for an environment and you will find, for a secret variable, its name, whether it is enabled, a flag marking it as secret, and where its value comes from. What you will not find is the value.
Non-sensitive things, like a base URL, can sit in the file as plain values, because they are not secrets and having them in Git is useful. Everything sensitive is stored by reference only. The file becomes a map of what your setup needs, never a container of the secrets themselves.
Three sources for a value
Each variable declares where its value comes from:
- Manual. The value lives in the environment file. Right for base URLs, IDs, and other non-sensitive configuration. Not for secrets.
- OS Secret. The value is written to your operating system's native secret store, macOS Keychain, Windows Credential Manager, or Linux Secret Service. It never touches the environment file and never enters Git. Atrahasis keeps these in their own isolated keychain namespace so they do not mix with anything else.
- Vault. The value lives in HashiCorp Vault. The file stores only the binding: which connection, which path, which key. Nothing else.
You pick the source per variable, so the base URL can stay readable in the file while the token beside it is backed by the keychain.
Plain-text auth: used in memory, never written down
This is the part that matters most, and it is easy to miss.
When you type a raw password or token directly into an auth field, not a {{variable}}, Atrahasis will happily use it to send the request. It lives in memory for as long as your session needs it. But the instant that request, flow, or load-test spec is saved, Atrahasis strips the raw secret out before the file is written. The structure stays, the auth type, the field names, the URLs, the scopes, but the secret value is blanked.
The one exception is a value that is already a reference. If you typed {{api_token}}, that is kept, because a reference is not a secret.
The result is a clean division of labor. A pasted credential works for the live request in memory, but it is never persisted to disk and never shared through Git. To keep a value across sessions, you promote it to an OS Secret or point a variable at Vault. The same rule covers OAuth: the access and refresh tokens Atrahasis manages for you, and the username and password in a password-grant flow, are runtime state only. They are never written into your saved project files.
Vault: a reference on disk, a value at runtime
Vault deserves a closer look because it is where teams keep their real production secrets.
You configure a connection once, its name, URL, and auth method. On the desktop, the session token that connection returns is cached in your OS keychain, and the connection details live there too, not in your project. In the environment, you point a variable at that connection with a path and a key. On disk, that is all that is stored: a name, a path, a key.
When a request needs the value, Atrahasis fetches it from Vault at that moment, uses it, and moves on. The secret is never cached into your files. Rotate it in Vault and the next run picks up the new value with no change on your side.
One file, two machines
The same environment file runs on your desktop and in CI, and it resolves secrets differently in each place, without any edits.
On the desktop, OS Secrets come from your keychain and Vault values come from your cached session. In a pipeline, there is no keychain, so atra, the Atrahasis CLI, resolves the very same variable names from the shell environment instead. You export your CI secrets as environment variables, and Vault credentials as a simple credentials@url string, and the run resolves exactly the references it did on your laptop. If something required is missing, the CLI tells you up front, before any request goes out, exactly which variables to set.
The value never travels. It stays on the machine that holds it, the keychain on your desk or the secret store in your CI. Only the references move.
Where this leaves you
Because the value is never in the file, the file is safe to move. Diffs of an auth change show that the auth type switched, not what the token is. Onboarding a teammate means they clone the spec and fill in their own credentials, every secret field arriving empty by design. Publishing a project to a public repository becomes a choice rather than a risk audit.
That is the whole idea behind how Atrahasis handles secrets. Not a warning label telling you to be careful, but a design where the careless path is already the safe one.