Use varsafe safely with coding agents

Harden Claude Code, Cursor or Codex around your secrets: keep values out of the conversation, narrow both the MCP grant and the CLI login, and add client-side guardrails.

CLI v7.7.0

A coding agent can do real secrets work for you: compare environments, generate keys, run your code with the right environment loaded. It also reads whatever lands in its context and acts on it. This guide shows how to set things up so that the agent gets the work done with as little access as possible, and so that secret values stay out of the conversation.

For connecting a client in the first place, see AI agents (MCP).

What can go wrong

Anything in the agent’s context can be logged. A value the agent reads through a tool, a file it opens or a command output it sees is sent to the model. It can be kept in your client’s history and in the model provider’s logs, outside varsafe’s control.
Content can steer the agent. A README, an issue, a code comment or a web page the agent reads can contain instructions written to make it do something else (prompt injection). varsafe tells agents to treat secret names and values as data, but it cannot stop an agent from following text it found elsewhere.
An agent with a shell has your CLI login. The MCP grant limits MCP tools only. When the agent runs varsafe in its shell, the CLI uses the credential stored on that machine, usually your own varsafe login, with everything that login allows. Those commands are audited as CLI activity under your name, not as agent activity.

The rest of this guide narrows each of these: what the agent asks for, what the MCP grant allows, what the CLI credential allows, and what the client lets it run.

Keep values out of the conversation

The hosted MCP endpoint sends every client a set of rules that point agents at the safe paths. Ask for work that follows them:

Instead of	Prefer	Why
The agent reading values to build a command	The agent runs `varsafe run -p <project> -e <environment> -- <command>` in its shell	The values reach that process as environment variables, not the conversation. Whatever the command prints still does, so it must not print secrets or dump the environment.
The agent writing a key or password into a secret	`varsafe_generate_secret`	varsafe generates and stores the value. The agent sees only its fingerprint.
Pasting a third-party key into the chat	You run `varsafe set <KEY>` yourself	The value goes from your terminal to varsafe and never passes through the agent.
Reading a value to check it	You run `varsafe get <KEY>` in your own terminal	The value is shown to you, not to the agent.

varsafe_get_secret_value, varsafe_get_secret_values and varsafe_export_secrets are the MCP tools that return plaintext values in the tool result. varsafe_export_secrets returns a whole environment’s values to the agent; it does not inject them into a process. A grant on Read only exposes none of them.

For example, a value only you have:

varsafe set STRIPE_SECRET_KEY -p my-api -e staging

At a terminal, varsafe set asks for the value with a masked prompt.

Narrow the MCP grant

You choose the grant on the consent screen when the client first connects. See Choose what the agent may do for every option.

Pick Read only when you can. The agent can list projects, environments and secret names and compare environments. It cannot read a value or change anything. Reading values comes only with Read & write; there is no separate switch for it.
Pick specific projects. Leave a team on all projects only if the agent needs all of them.
Pick specific environments. Narrow each project to the environments the agent works in, for example development and staging, and leave production out. An environment outside the grant is refused, and left out of every list the agent sees.
Cover only the teams the agent needs. One approval can cover several teams; select only those.

To change a grant later, revoke the connection on the Agents page and approve the consent screen again.

Narrow the CLI credential on the agent’s machine

Narrowing the MCP grant changes nothing for commands the agent runs in its shell. Check what the CLI on that machine can do:

varsafe whoami

whoami shows the type of credential in use (a CLI login or an API token), its scopes, and the projects and environments it covers.

varsafe login opens an approval page in your browser with three access levels:

Level	What the CLI can do
Read only	Browse projects, environments and secret names. `varsafe run`, `get` and `export` do not work.
Standard	What `varsafe run`, `get` and `export` need, values included. Nothing can change.
Full access	Adds creating, updating and deleting secrets, so `varsafe set` and `unset` work.

On a machine where an agent runs commands, approve Standard rather than Full access unless the agent has to change secrets, and narrow the teams, projects and environments on the same page. Keep varsafe set for yourself, from a terminal where you approved Full access, or from the dashboard.

To replace an existing login with a narrower one:

varsafe login --force

--force starts a new browser approval even though you are already signed in. Once the new credential is stored, the CLI revokes the one it replaced.

Standard still lets the agent run varsafe get or varsafe export --plain and see values. To stop that, use the client-side guardrails below, or a credential that does not reach the environments that matter.

Or give the machine a scoped API token

An API token can be limited to one project, chosen environments and Read secrets. Owners and admins create tokens in the dashboard under API tokens. The CLI reads it from VARSAFE_API_TOKEN:

export VARSAFE_API_TOKEN="vs_at_..."
varsafe whoami

varsafe run removes VARSAFE_API_TOKEN and VARSAFE_TOKEN from the environment of the command it starts, unless you pass --pass-credential, so the command cannot reuse the token.

Add client-side guardrails

Your client can refuse commands before they run. In Claude Code, permission rules in .claude/settings.json do this. For example, to block the commands that print values and reads of .env files:

{
  "permissions": {
    "deny": [
      "Bash(varsafe get:*)",
      "Bash(varsafe export:*)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

This is Claude Code’s configuration format; see Claude Code’s documentation on permissions for the full rule syntax. In Cursor, Codex and other clients, use their own command-approval settings to require your approval for varsafe get and varsafe export.

Review what the agent did

Audit log. In the dashboard, open Audit log. Entries made through MCP tools are marked Agent · MCP and attributed to you, or to the token the client used. Value reads, changes and secret-name listings are recorded; comparing environments is not. Commands the agent ran through the CLI appear as CLI under the credential that machine used. See Audit trail.
Agents. Open Agents in the sidebar to see every connection you approved: the app and its publisher, the teams it covers, its scopes, and when it was last used. Revoke cuts an agent off at once.
CLI Sessions. Your Profile lists every machine signed in with varsafe login as you. Revoke a machine you no longer trust.
API tokens. Revoke a token on the API tokens page when the machine no longer needs it.

Checklist

The MCP grant is Read only, or Read & write only where the agent has to change secrets.
The grant covers specific projects and environments, and leaves out production.
The CLI login on the agent’s machine was approved at Standard or narrower: varsafe whoami lists no write scope, and only the environments the agent works in.
If the machine uses an API token, no varsafe login is stored there, and whoami shows the token.
You ask the agent to use varsafe run and varsafe_generate_secret, and you set third-party values yourself with varsafe set.
Your client asks before running varsafe get or varsafe export, or denies them.
.env files with real values are not readable by the agent.
You check the audit log and the Agents page from time to time, and revoke what you no longer use.

AI agents (MCP): connect a client, access levels and audit
API Tokens: scoped credentials for machines
Authentication: CLI login, storage and sign-out
Roles & Permissions: what each role can do