Secrets and the files an agent must never read

In Claude Code

File: deny rules and their 2 ways of being wrong

If you want to use gitignore-style patterns to define the files and directories the code is not allowed to read or edit, then you need to follow these in settings.json for both Read() and Edit(), but what can be tricky is the anchoring part:

{
  "permissions": {
    "deny": [
      "Read(*.env)",
      "Read(//Users/alice/.aws/**)",
      "Read(~/.ssh/**)",
      "Read(**/.env)",
      "Bash(cat *.env*)",
      "Bash(printenv *)",
      "Bash(env)"
    ]
  }
}

The anchoring is the first way to get this wrong. A single leading slash anchors at the settings source, not at the filesystem root — the docs give five different anchors depending on which settings file the rule sits in — so Read(/Users/alice/.aws/credentials) resolves under one of those instead of at /, and never matches the file you meant. Absolute needs //. A bare path or ./path is relative to the current directory, which is why Read(**/.env) sits next to Read(*.env) above rather than instead of it.

The last three entries are the shell and env routes (we can't do cat on these files, run printenv, and run env), and I did those in a specific way to make sure that they don't conflict with any reasonable usage of these commands. So I added a space after printenv so we cover both bare printenv and printenv FOO (it is defined like this in the docs: "prefix followed by space or end of string") and I left env as an exact match because I think it's reasonable to have 55 lines of output if you run env (which it does on my machine) and it's ok if you want to do env FOO=1 command, for example.

Also, what's important is that starting from v2.1.208 a Read deny also forbids Edit on this path (including creating a new file), so since Write and NotebookEdit aren't covered make sure to add an explicit Edit deny for paths you don't want any tool to edit.

Also, it's important to know that paths are only considered for Edit() and Read(). If you define a rule for Write or Glob or NotebookEdit it will be accepted but will produce a warning during the start up of Claude Code and will never be used. Except for Glob — if you provide it using the --allowedTools parameter it will be used, but in order for this to work you need v2.1.210 or newer.

Credentials: where we lock access to the environment

Starting from v2.1.187 there's a new section called sandbox.credentials that is intended for this purpose and it comes with an empty config (so by default it doesn't block access to any credentials, only entries you add will be locked):

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

This means we can't read the ~/.aws/credentials file or the ~/.ssh directory and the two variables will not be available before running any command. Re-running the canary from the shared section with exactly these settings: no output and exit status 1 — so the variable was definitely missing before the execution, not just refused after it.

Starting from v2.1.199 you can set the mode to mask for variables if removing them breaks sth. This way your command will be run with a special value set for this variable in the environment. What's more, thanks to it Claude Code's proxy will modify the requests you make to the hosts listed under injectHosts by replacing that special value with the real one so the authentication should work as usual, but nothing the tool writes to the logs (for example) will contain the token. It's important though to set network.tlsTerminate in such scenario because the proxy needs to see the requests' content in order to modify them.

Another option is setting CLAUDE_CODE_SUBPROCESS_ENV_SCRUB which is a general switch independent of the sandbox that removes Anthropic and cloud provider credentials from every subprocess. The downside is it's not as granular.

Two gotchas

The file half of credentials lives in the filesystem layer, so filesystem.disabled: true switches it off — while the environment half keeps working, because env scrubbing is independent of that layer. So if you turn filesystem isolation off to keep some stubborn tool happy, your credential files become readable again while the variables stay protected, which is not an obvious pairing. Two things narrow it: the key needs v2.1.216 or newer, and it's only honoured from user settings, managed settings or --settings, so a repository you checked out can't switch filesystem isolation off on you.

The second one is that the built-in file tools don't go through the sandbox at all — Read, Edit and Write use the permission system directly. So the path rules and the sandbox rules are protecting different callers, and a path that actually matters needs an entry on both sides.

In Codex CLI

The environment, first, because it's the cheapest win here.

This is the lowest effort and biggest effect you can get in Codex CLI. The configuration is defined using shell_environment_policy in the ~/.codex/config.toml file, here's a configuration for example:

[shell_environment_policy]
inherit = "core"
ignore_default_excludes = false

[shell_environment_policy.filters]
"AWS_*" = "exclude"
"AZURE_*" = "exclude"

This is how it works:

• inherit can be set to all, core or none

• setting ignore_default_excludes to false actually enables default exclusions of names containing KEY, SECRET or TOKEN — by default they're disabled

• filters is a list of globs — they work case-insensitive and you can use * and ? wildcards in there

• if you add a single include entry, the entire policy works as an allowlist instead of a denylist (but you cannot include what you've already excluded)

• the configuration is processed in the following order: default exclusions, user exclusions, set values, include allowlist

That means that due to the fact that set is being applied after the exclusions, you might be setting some variable that was actually excluded.

The shell route, verifiable without a model call.

The second layer of security is the shell itself and can be configured using Codex's execpolicy feature which doesn't require any model call to explore. The files with rules are located under rules/ in the ~/.codex directory, like ~/.codex/rules/secrets.rules for example:

prefix_rule(
    pattern = ["cat"],
    decision = "forbidden",
    justification = "Reading files through the shell bypasses path rules.",
)

• the cat prefix is marked as forbidden, and the justification says why: it's a way to read a file through the shell despite the path rules

• if you want to explore a file with execpolicy rules, you can use the codex execpolicy check subcommand — it's good to get used to running it

codex execpolicy check --pretty --rules ~/.codex/rules/secrets.rules -- cat .env

{
  "matchedRules": [
    {
      "prefixRuleMatch": {
        "matchedPrefix": ["cat"],
        "decision": "forbidden",
        "justification": "Reading files through the shell bypasses path rules."
      }
    }
  ],
  "decision": "forbidden"
}

• it will print all the rules that are being applied for a given command and an outcome (forbidden or prompt)

• forbidden — as the name suggests — forbids running the command, prompt asks for confirmation

• if there are both an allow and a forbidden rule with the same prefix, both of them will appear in matchedRules and the outcome is forbidden anyway, regardless of the order in which they're defined

What the sandbox does and doesn't cover.

The last thing is the sandbox, and it isn't the tool for this job — it's there to stop a command writing somewhere it shouldn't, not to stop a secret being read. It's not about what you can see, but what you can do: as long as it's set to read-only, you can read the .env file and list ~/.ssh contents, but you can't touch anything — you'll get Operation not permitted.

codex sandbox -c sandbox_mode='"read-only"' -- /bin/cat .env       # SECRET=hunter2
codex sandbox -c sandbox_mode='"read-only"' -- /bin/ls ~/.ssh      # the directory listing
codex sandbox -c sandbox_mode='"read-only"' -- /usr/bin/touch ./x  # Operation not permitted

Note the shape of that invocation: if you try using -s (or --sandbox) instead of -c here, it will throw an error, as the codex sandbox subcommand takes config overrides with -c and has no -s of its own.

The transcript.

You can also configure whether the sessions are being recorded by changing history.persistence in the ~/.codex/config.toml file. It accepts save-all or none values and decides if the session transcripts are being persisted to history.jsonl or not. You can also set history.max_bytes to limit the size of the file, removing oldest entries automatically once it reaches this size.

But setting persistence to none will only change where a potentially leaked secret ends up — it won't change the fact that it's already been sent during the request.

In Cursor

.cursorignore is the mechanism, and Cursor documents its own two holes.

We could use .cursorignore for this, it's a kind of single source of truth when it comes to what is being ignored by Cursor. It goes in the project root and uses gitignore syntax, so you can list files there like .env or its variants, a secrets folder, .pem files, or credentials.json no matter what level it sits on:

.env
.env.*
secrets/
*.pem
**/credentials.json

.gitignore is covered too (there's also a built-in default list which Cursor ignores automatically), and everything listed won't be accessible from the code via Agent, Tab, Inline Edit or via @-mentions.

But there are two gaps, and both of them are in the official docs. First, the terminal and MCP server tools that the Agent uses cannot block access to code governed by .cursorignore — that's the shell route from the shared section, named by the people who built it. Second, the docs say that while Cursor blocks ignored files, complete protection isn't guaranteed due to LLM unpredictability. So it's not a perfect solution.

The second thing you can do is creating a .cursorindexingignore file which will remove all the files from the indexing process but won't block them from being used by the AI features, they'll just not be visible in codebase search; it's not about not having access to them.

The shell route goes through permissions.json.

The terminal path is defined in the permissions.json file which is placed in two places:

• user-level ~/.cursor/permissions.json

• project-level <project>/.cursor/permissions.json

(they are being merged) and contains natural language instructions that you can put there to not allow Cursor to run specific things. Here's an example:

{
  "autoRun": {
    "allow_instructions": [],
    "block_instructions": [
      "Any command that reads a .env file or a credentials file should go through approval first.",
      "Any command that prints the environment, such as env or printenv, should go through approval first."
    ]
  }
}

As you can see, you can define there for example that in order to run commands that use the .env file or read the credentials file (or even the one that dumps the environment — env, printenv) you need to ask me first. Under the hood there's a classifier reading these instructions so it can understand more than a glob pattern, but it's less predictable than a glob, and it understands "commands like this" rather than "this specific path and nothing else".

The sandbox will not do this job.

What's more, we cannot achieve that with the sandbox as it only allows to add permissions (the type, additionalReadwritePaths, additionalReadonlyPaths and network policy), there's no such thing as a read-deny key in it. The reference states plainly that SSL certificate paths and ~/.ssh are always readable, and the default sandbox behaviour for terminal commands is read and write access inside the workspace, with .cursorignore named as the thing that can hide files from the agent.

So ultimately for Cursor the only reasonable thing you can do in such scenarios is to just go with the first step I've mentioned in the shared section and remove the secret from the workspace and the environment.

The gotcha. Run Modes — the Auto-review classifier included — are described in the docs as best-effort guardrails rather than a hard security boundary, and the same page says outright that the classifier can make mistakes. Cloud Agents are a separate story again: the docs say they don't use Run Modes at all, because they run on their own dedicated machine and never stop to ask you to approve anything.

In Antigravity CLI

As it uses its own permission for reading files, it's actually more convenient to define the permissions for it than for most of the other tools.

The config file can be found at ~/.gemini/antigravity-cli/settings.json and is the following:

{
  "permissions": {
    "deny": [
      "read_file(.env)",
      "read_file(/home/user/.ssh)",
      "read_file(/home/user/.aws)",
      "command(cat .*env.*)",
      "command(printenv)",
      "command(env)"
    ],
    "ask": ["command(*)"]
  }
}

Here I've listed a few sensible defaults like denying access to .env, ~/.ssh and ~/.aws as well as to the printenv and env commands that can be used to output the environment variables. You should also have an ask entry here that covers every single command you use.

The way it works is that:

• read_file — this permission takes paths as targets, and:

  • either absolute or relative to the workspace's root

  • recursive — if you put a directory here, everything inside of it will be denied as well

  • wildcard — if you enter * here, all files on the machine will be denied

• the precedence is fixed by the type of the list:

  • deny comes before ask

  • ask comes before allow

  • allow cannot override deny, not even with a narrower entry

• if you deny access to read_file for some path, you'll automatically deny access to it using write_file as well

One thing that may be surprising here is that in the workspace everything is allowed by default (unless you say otherwise). That means that all read and write operations within the active project will work without a prompt. That in particular means that if you create a .env file inside of your working project, it'll be accessible unless you define it in either deny or ask.

Also, the secure fallback the docs describe is only used when there's no entry for some action in any of these lists.

The opposite is true outside of the workspace:

• by default the allowNonWorkspaceAccess property in the same settings file is set to false, which means that file tools generally can't access anything outside of the workspace

• if you don't define a path in any of these lists, it'll fall back to "ask"

That's why as I said earlier it's crucial to keep your secrets outside of your projects.

Command patterns — here we have another layer for the command permission, where we can specify separate commands and match them per token. This means that every single whitespace-separated word of a command is evaluated as an anchored regex. So for example if you set the following pattern: command(npm run (build|lint|test)) it will catch only these 3 alternatives.

The thing is, that as with everything connected with string matching this only works if someone uses the commands that are similar to the ones you've listed. If they create a script that reads the file themselves, the file won't be safe.

The terminal sandbox doesn't close that either, and it's set to false by default in the same settings file — enableTerminalSandbox, which underneath is:

• nsjail on Linux

• sandbox-exec on macOS

• AppContainer on Windows

The official docs say that it's used to prevent destructive things being done with the shell and unauthorised network requests. There's also no word there about scoping reads, so I'd rather enable this for the reasons mentioned in the three-gates lesson than for hiding credentials.

Last but not least, whenever you're prompted by Antigravity CLI for any file, URL or MCP permission, the target input is editable before you approve it. If you alter it, the access will be granted for all its occurrences during the current turn, so as I mentioned earlier when it comes to files — if you change it from let's say /my-file.txt to my-dir, all actions that operate on this file or any file from this directory won't be prompted.

In Kimi Code CLI

If you want to set up permissions in Kimi Code CLI, the most crucial thing is the order of rules defined in config.toml (in ~/.kimi-code/) under [[permission.rules]]. These are being evaluated in order from top to bottom and the first matching rule is applied. The other solutions like Claude Code or Antigravity have a hardcoded order in which they're checked, for example denials are checked first, then asks and finally allowances — that way if you were to add eg a general ask at the very beginning of your config and then add a specific deny further down it will not work as it'll be shadowed by the ask and will not be applied without any notification. The config below denies the env files, the Bash route to the same place, and config.toml with the plaintext provider keys in it, using a general ask for Bash at the very end:

[[permission.rules]]
decision = "deny"
pattern = "Read(**/.env)"
reason = "Secrets never reach the model"

[[permission.rules]]
decision = "deny"
pattern = "Bash(cat *.env*)"
reason = "Same file, other route"

[[permission.rules]]
decision = "deny"
pattern = "Read(**/.kimi-code/config.toml)"
reason = "This file holds provider API keys in plain text"

[[permission.rules]]
decision = "ask"
pattern = "Bash"

In config.toml's [[permission.rules]] you can define the rules in the following format:

• decision: (allow | deny | ask)

• pattern: ToolName (or ToolName(arg-pattern)) — the argument part is optional and describes what the argument is. It's the responsibility of every tool to decide what it matches against, for example in the case of Bash it's commands and for Read it's paths

• reason: (optional, but recommended) — especially if you're setting up a denylist, and after some time, when you'll be tired of no. 100 denials in a row you'll just remove it from the config without a reason

The doctor subcommand runs some checks before actually using the config so it can tell you if everything's alright with the config file:

kimi doctor

It prints an OK line for each config file it read, a SKIP line for each one that doesn't exist, and finishes with All checked config files are valid. The sample config above is being validated correctly, ofc, but it validates the syntax not the intent — it's happy with an inverse order of these rules if you were to swap the positions.

Protecting the config file itself. That's the third rule in the block above, and it's there because the config file is the only place where provider keys are stored — they're not being read from any env variables — and according to the docs the api_key for example is stored there as plain text. So it's obvious that we want it on a never-read list. The OAuth credentials are being handled better though: there's the credentials directory under ~/.kimi-code/ with 0700 permissions and inside of it files with 0600 permissions.

Two gaps. There are also 2 things that aren't supported by this system:

• The MCP tools, custom tools and AgentSwarm are only matchable based on tool name, so if you were to use a tool that takes paths for example, you won't be able to secure some of them without affecting the entire tool (allow or deny the tool).

• There's no sandbox in this system — it's the empty cell in the Academy table. It means that there's no operating system level separation and therefore it's up to the user to make sure their project is being isolated by using a container or a VM for example.

The trap. The last thing (and most important tbh) is that every turn of a session is being recorded in a wire.jsonl file located in ~/.kimi-code/sessions/<workDirKey>/<sessionId>/agents/main/ and is described as a full communication log of the main agent so it can be used for resume or replay of sessions. That means any secret that reached one turn is sitting in that file, and every sub-agent maintains their own such file next to it.