All blog posts

There is a file on your laptop right now that contains your AWS secret access key, your database password, and probably your Stripe API key.

It is called .env.

Your coding agent can read it.

This is not a bug. It is not a misconfiguration. It is how Claude Code, Codex, Cursor, and every other coding agent works. They operate as your local user, with access to your filesystem, your shell, and your environment. That access is what makes them useful. It is also what makes them dangerous in ways most developers have not thought through yet.

---

What Gets Exposed

When a coding agent starts a task, it needs context. It reads files to understand your project. It explores directories to find configuration. It checks your shell environment to understand how your toolchain is set up.

Along the way, it routinely touches:

.env and .env.local

Every web framework tutorial tells you to put secrets in .env. Every project has one. It typically contains database URLs, API keys, OAuth secrets, and service tokens — the entire runtime credential surface of your application.

~/.ssh/

SSH private keys live here. If your agent is helping you with git operations, shell commands, or infrastructure work, it may read from your home directory. Your id_rsa, id_ed25519, or deploy keys are in that path.

~/.aws/credentials and ~/.aws/config

If you have ever run aws configure, your AWS access key ID and secret key are stored in plaintext in ~/.aws/credentials. The same is true for ~/.azure/, ~/.config/gcloud/, and similar provider credential stores.

.netrc

Stores plaintext credentials for FTP, Git over HTTPS, and other network services. Widely used, rarely audited.

*.pem, *.key, *.p12

Certificate files, private keys, and PKCS bundles used for TLS, code signing, and service authentication. They may be scattered across your project directory or home folder.

~/.gitconfig

Can contain personal access tokens stored as credentials for Git remotes — especially common for GitHub, GitLab, and Bitbucket HTTPS authentication.

Browser session and credential stores

Depending on your OS and which tools your agent can call, it may be able to reach local session data or credential stores your user account has access to — Chrome’s Login Data SQLite file, or a keychain entry pulled via the macOS security CLI, for example. Most agents don’t go looking for these by default, but “agent can execute arbitrary shell commands” and “these stores are one shell command away” is a combination worth knowing about.

---

A Concrete Example

Let’s say you ask your coding agent to help you debug a connection error in your Node.js API. A reasonable request.

The agent opens your project. It reads package.json, server.js, and a few route files. Then it reads .env to understand how the database connection string is configured. Now it has your DATABASE_URL, your REDIS_URL, your OPENAI_API_KEY, and your STRIPE_SECRET_KEY in its context window.

Nothing bad happened yet. But the agent’s context now contains your production secrets.

What can go wrong from here?

• The agent summarizes them. You asked for an explanation of the error. The agent includes the connection string in its explanation, which gets logged.

• The model provider logs the context. Depending on the provider and your account settings, conversation context may be retained for abuse monitoring or model improvement.

• A third-party MCP tool receives them. Your agent calls a search tool, a documentation tool, or a browser tool to do research. That tool’s request may include your project context, including the secrets that were read upstream.

• A prompt injection redirects them. A malicious comment in a dependency’s README, a poisoned GitHub issue, or a crafted error message in a third-party API response tells the agent to summarize the current environment and post it somewhere. Your agent, trusting the instruction, does exactly that.

• The agent writes them into generated output. Test fixtures, example configs, documentation drafts, or even git commits can inadvertently include values that were in context.

None of these require the agent to be compromised. They all happen through normal agent operation on normal codebases.

---

The SSH Key Problem Is Worse

SSH keys are not scoped like API tokens. When an API key leaks, you rotate it and the damage is bounded to that service.

An SSH private key can grant access to every server, every Git remote, and every infrastructure component that trusts it. If your coding agent reads ~/.ssh/id_ed25519 while working on a deploy script, and that key is in its context, the attack surface is your entire SSH trust graph.

Most developers have never thought about this because most tools do not touch ~/.ssh. Coding agents do.

---

Cloud Credentials Are the Highest-Severity Case

AWS, GCP, and Azure credentials in agent context represent potential infrastructure-level compromise.

~/.aws/credentials often contains long-lived access keys with broad permissions. Developers frequently use admin-level or power-user credentials locally for convenience. If those credentials enter agent context and are subsequently exposed — through any of the paths described above — an attacker could:

• Enumerate your S3 buckets and download their contents.

• Launch EC2 instances for cryptomining or pivot operations.

• Access RDS snapshots and export your production database.

• Read Secrets Manager entries that contain even more credentials.

This isn’t a hypothetical blast radius. It’s the same shape as real-world incidents where a single compromised local endpoint cascaded into full cloud-account exposure — the 2023 CircleCI breach being one well-documented example. Malware on an employee’s laptop stole an authenticated session, which was then used to exfiltrate customer environment variables, tokens, and keys stored on the platform. Different entry point than a coding agent, same underlying lesson: once a credential leaves the place it was meant to sit, the blast radius is whatever that credential can touch, not whatever channel it leaked through.

---

Why Existing Controls Do Not Help

Your .gitignore does not help.

It prevents secrets from being committed to Git. It does nothing to prevent a local process from reading the files.

Your secret manager does not help here.

Vault, AWS Secrets Manager, and 1Password are excellent for production systems. But your local .env exists specifically because you need credentials available locally during development. Secret managers do not eliminate it.

Your antivirus does not help.

Coding agents are signed, legitimate applications running as your user. They are not malware. EDR tools have no visibility into which files an agent reads or what enters its context.

Model-level content filtering does not help.

Filters that look at output cannot prevent secrets from being included in the prompt that goes to the model. By the time a filter could act on the output, the secrets have already been sent to the API.

---

What Gödel Does

Sensitive path scanning

Gödel knows which paths typically contain credentials: .env variants, ~/.ssh/, ~/.aws/, ~/.azure/, ~/.config/gcloud/, .netrc, certificate files, and keychain-adjacent paths.

When your agent attempts to read a file in one of these locations, Gödel intercepts the read at the OS level — before the file’s contents reach the agent’s context window — and evaluates the request against your policy: which agent is asking, what path it’s requesting, and what task it’s currently executing.

Policy-based access control

You define which agents can read which paths under which conditions.

A policy might say:

“Claude Code can read .env in project directories, but not ~/.aws/credentials or ~/.ssh/.”

Violations are blocked before the file content enters the context window. The agent gets a denial, not the secret.

Real-time trust report

When Gödel finds a sensitive path access, it surfaces a finding in your menu bar.

The finding shows:

• Which file was accessed

• Which agent requested it

• What task the agent was performing

• Whether the access was allowed or blocked

This is the provenance record you need if you ever have to investigate what your agent saw.

Secret detection on allowed reads

Even for paths you allow, Gödel scans the content for known secret patterns — AWS key prefixes like AKIA, GitHub token formats, PEM private key headers, and similar fingerprints.

A match doesn’t just get logged. It downgrades the trust level assigned to the agent’s subsequent actions for that session.

Concretely, this means a tool call that would otherwise be auto-approved — for example, an outbound request from a research or browsing tool — gets escalated to require explicit confirmation once Gödel has seen a live secret enter context, on the theory that the next action is now higher-stakes than it was a moment ago.

---

What You Should Do Right Now

Even before you install Gödel, there are things you can do today:

1. Audit your .env files.
   Do they contain production secrets? They should not. Production secrets belong in a secrets manager. Your local .env should reference a local or staging environment.
2. Rotate any SSH keys that have touched production systems.
   If your development laptop’s SSH key can reach production, create a separate deploy key with scoped access.
3. Use short-lived AWS credentials.
   Replace long-lived access keys in ~/.aws/credentials with SSO-based temporary credentials via aws sso login or a credential helper.
4. Set HISTIGNORE in your shell.
   Export commands with credentials sometimes land in shell history.export HISTIGNORE="*AWS_SECRET*:*TOKEN*:*PASSWORD*"This keeps them out.
5. Review what your MCP tools receive.
   If you use MCP tools (browser, search, documentation), check what context those tools can see. A tool that receives your full project context may also receive your secrets.

---

The Bigger Picture

Coding agents are the most powerful developer tool in a generation. They also create a new kind of local information-flow risk that existing security tooling was not built to handle.

The problem is not that agents are malicious. The problem is that agents are powerful enough that the ordinary things they do — reading files, exploring directories, and calling tools — can have security consequences that the developer never intended and never sees.

Sensitive path access is where that gap is sharpest. It is also the easiest place to start closing it.

---

Tags: claude-code, coding-agents, developer-security, secrets-management, dotenv, aws-credentials, ssh-keys, prompt-injection, godel