Keeping credentials out of your coding agent’s model context

I always had a slightly bad feeling about the credentials my coding agent could access. Did I secure things enough? Probably not. But I also didn't want to cripple it by blocking access to files it needed to understand my project.

That left me doing nothing about it.

When I learned about hooks in coding agent harnesses, I wondered: could I let the agent read the files, but remove the secret values from the output before it reaches the model?

This became ContextVeil, a small, local, open-source tool.

Why

When debugging an application, reading .env.local can be quite useful. The model might need to know which database you connect to or whether a feature flag is enabled. But the API token next to these settings usually isn't needed.

Of course, credentials should generally live in a credential store. In practice, projects also have .env files, configuration files and environment variables containing secrets. And these are not necessarily limited to disposable development credentials.

I see this as sensible hygiene: if the model doesn't need the credential, why put it into its context? A value that never reaches the model cannot accidentally be repeated by it in a generated example or a response.

Let the command run

For example, Claude Code might run cat .env.local and receive:

DATABASE_URL=postgres://localhost/my_app
API_TOKEN=cv_example_canary_not_a_real_token
LOG_LEVEL=debug

If you have selected API_TOKEN for protection, ContextVeil changes the supported tool result before it reaches the model:

DATABASE_URL=postgres://localhost/my_app
API_TOKEN=<SECRET:API_TOKEN>
LOG_LEVEL=debug

The command still runs and the file is still read. Your application can still use the actual token. The model gets the remaining configuration and can see that an API token is configured.

This was the important part for me: I wanted something I would actually enable, without worrying about it refusing legitimate file reads or commands.

Smartness during setup

There are two parts to ContextVeil:

1. During setup, heuristics suggest likely secrets from environment variables, .env files and supported configuration and credential files. You review the suggestions and choose what to protect.
2. During agent use, ContextVeil reads the selected values and does literal search and replace in supported text headed to the model.

There is no runtime classifier deciding whether some arbitrary output looks suspicious. Matching is exact and deterministic, runs locally, and needs no network connection or additional model.

The configuration stores references, such as “the API_TOKEN entry in .env.local”, rather than copies of the credentials. When that file's value changes, ContextVeil picks it up on the next turn.

When you add credentials in new entries or files, rerun setup to include them.

Try it

ContextVeil supports Linux (including WSL) and macOS. Install it with:

curl -fsSL https://raw.githubusercontent.com/daniel-sc/contextveil/v1.0.0/install.sh | bash

Then, from your project directory, run the interactive setup in your terminal:

contextveil setup

Review the suggested sources and select your integration, e.g. Claude Code. Restart the agent and check the installation:

contextveil doctor

Claude Code is the production-supported integration. Codex CLI, GitHub Copilot CLI and OpenCode are also available as experimental integrations. I personally use it with Codex and OpenCode. For Codex, approve the installed hook through /hooks or the Hooks need review screen before running the check.

Scope

ContextVeil reduces accidental exposure of selected, exact secret values. It does not sandbox the agent or prevent commands from using credentials directly, and transformed values such as Base64 are outside its matching scope. Coverage depends on the harness integration; see the support details.

If you've also been uneasy about credential access but reluctant to restrict your coding agent, give ContextVeil a try. I'd especially like feedback on the setup suggestions and whether it fits into your daily workflow. What would make you keep it enabled—or turn it off?

Comments

[Mihai Perdum]

This is a genuinely useful category of tool - exact match-and-replace beats a runtime classifier for something security-adjacent, deterministic over probabilistic is the right call here. One thing I'd want to know: does it catch things on the way out too, not just in? If the agent decides on its own to run something like curl -H "Authorization: Bearer $API_TOKEN" as a generated command, the token's already in the agent's own written output before any tool result comes back through the hook. Scrubbing results protects against accidental echo but not against the agent constructing a command that embeds the secret directly. We ran into a version of this building Sentinel Vault - full disclosure, that's ours - and ended up needing to gate at the command-construction boundary too, not just the read boundary. Curious if that's already covered by the hook point you're using or if it's a known gap.