Your agent needs the secrets, not the file
A plaintext .env is the easiest thing for a coding agent to commit. Take the file away and inject values.
What is actually enforced
Envless removes the .env file. Values are stored encrypted and injected directly into the process, so the agent never has a secrets file to read or commit.
Full definition
An AI coding agent has read access to your working tree and the ability to run shell commands. Both are the point, and both are why a plaintext .env is now a liability rather than a convenience: it is a file, in the repository, containing production credentials, sitting inside the exact context window you are handing to a model. Envless removes the file. Values are stored encrypted, injected directly into the process that needs them, and reachable only by a key you scoped to read one thing. The agent still runs the command; it just never has a secrets file to read, summarize, paste into a chat, or commit.
Running a process with secrets injected
What envless run does with signals, exit codes and the names it refuses to inject.
Machine access
ENVLESS_TOKEN, ENVLESS_KEY and ENVLESS_PASSPHRASE, and why the raw key is the better machine credential.
API keys and scopes
Creating a narrowly scoped key, the project allowlist, and how rotation and revocation work.
Server vs client variables
Keeping a server secret out of anything that gets bundled and shipped to a browser.
Typed variables
Generating the declaration file that gives an agent names and types without values.
Roles and permissions
The 45 workspace permissions a key is clamped against, and what Viewer actually allows.
envless run touches no file
no fs writeThe run command imports child_process and os and nothing else. It decrypts in memory and spawns the child with the values in its environment, so there is no plaintext file produced at any point for an agent to find.
The only scope an agent needs
variables:readEvery mutating variable route requires variables:write, so a read-scoped key gets 403 auth.scope_missing on create, update, delete, bulk create and apply. Scopes cover 11 resources at three levels and every one defaults to none.
Required to read a single value
2 credentialsA stolen ENVLESS_TOKEN on its own decrypts nothing. Machine mode aborts unless ENVLESS_KEY or ENVLESS_PASSPHRASE is also present, and that material is used locally and never sent to the API.
Fence a key to one project
projectIdsA key can be restricted to a specific project list; anything outside it is refused with auth.key_project_restricted. A key also cannot outrank its creator, and is automatically re-clamped when that person's role changes.
What is safe to commit
names onlyenvless types writes an envless-env.d.ts of names and types with no values, and the .env.example export emits bare NAME= lines. Both give an agent everything it needs to write correct code, and nothing it could leak.
Never injected, whatever you store
26 namesPATH, NODE_OPTIONS, LD_PRELOAD and twenty-three others change how a process or its children execute code. They are refused injection and named in a warning, so a variable write cannot become code execution in an agent's shell.
AI agents FAQ
Yes, and it is important to be exact about this rather than sell you a guarantee that does not hold. envless run puts decrypted values into the child process environment, so anything that can execute the wrapped command can also read that environment. What changes is that there is no plaintext file in the repository: nothing for the agent to open while reading your code, nothing to include in a summary, nothing to commit. You are removing the accidental disclosure path, not sandboxing the process.
No. There is no MCP integration today, and we would rather say so than imply one exists. The integration surface an agent actually uses is the shell: it runs the commands in your package.json, and if those commands are wrapped with envless run, the agent gets working secrets with no further integration at all.
No. There is one machine credential shape, the ev_sk_ API key, and an agent key is a normal key you scoped narrowly. That means the controls you have are real ones: per-resource read/write scopes, a project allowlist, a clamp so a key can never outrank its creator, and immediate revocation. What it does not mean is a separate agent identity in the audit trail, which is the next question.
Not at key granularity. Events record the acting user, and a key's actions are attributed to the human who owns it, so two keys owned by the same person are indistinguishable in the record. If you need to tell agents apart, give each one a key owned by a distinct service account rather than by a shared human account. We would rather you design around this than assume a distinction the data does not carry.
No. Keys live until you deactivate or delete them; there is no TTL, no automatic rotation, and no expiry field. What you do get is lastUsedAt, stamped on every authenticated request, so you can see whether a key has gone quiet before revoking it. Revocation takes effect on the next request, with no grace period.
Nothing in Envless, and you should plan for that. There is no redaction layer over a child process's stdout, and nothing inspects model input or output for prompt injection. Envless narrows what the agent can reach, through read-only scopes and a project fence, and removes the file that makes casual disclosure easy. Treat the process environment itself as visible to whatever runs inside it.
A key with variables:read and nothing else, fenced with projectIds to the single project it works on, pointed at a development or staging environment rather than production, paired with ENVLESS_KEY rather than a passphrase so no human-chosen string is in the environment. Then wrap the project scripts so the agent never needs to reason about credentials, and keep the production environment on a key it does not hold.
A gitignored .env is still a plaintext file in the working directory, which is exactly what an agent reads. It also still has to reach every developer and every CI runner somehow, which in practice means a chat message or a shared vault entry. Envless removes both problems at once: no file in the tree, and one encrypted source of truth that a scoped key reads at run time.