# Why your AI coding agent should never see your API keys

> Source: <https://dev.to/ikkun1222/why-your-ai-coding-agent-should-never-see-your-api-keys-1hem>
> Published: 2026-08-15 02:02:59+00:00

Your AI coding agent needs your API keys. It needs them to call services, to

test integrations, to run your stack. So you give it `.env`

files, or you

export keys into the environment, or you paste them into config files the

agent can read.

That means your secrets live inside the agent's context window — the same

window where a prompt-injected instruction or an overly verbose debug log can

leak them to an attacker or an untrusted model endpoint.

This isn't theoretical. If you've used Claude Code or OpenCode for more than a

few days, you've probably seen a tool call dump an environment variable, or a

log line that echoes a connection string. Most of the time nothing bad

happens. "Most of the time" is a bad security posture.

AI agents are the first software that *reads your source, your config, and
your secrets*, then sends summaries of what it read to a third-party API.

With traditional software, the principle was simple: secrets live in the

process environment, code reads them at runtime, nobody reads them back out.

With agents, there is no such boundary — the agent both *reads* the

environment and *transmits* what it knows.

Three concrete leak vectors:

`.env`

and includes values in a
later prompt to an external model. You can't audit this; it's in the model's
training/inference pipeline.The solutions fall into a few buckets:

`.env`

hidingI ended up building a small CLI (Go, zero external deps) with three layers:

**Subprocess injection with output sanitization.** `trustless run -- cmd`

resolves secrets from my existing pass store and injects them as env vars.

After the command runs, stdout/stderr is scanned and secret values are

replaced — including base64 and URL-encoded variants. The agent sees the

command output, not the keys.

**HTTP proxy with per-host injection.** For services that take headers or

query params (EDINET, e-Stat, xAI, OpenRouter), `trustless proxy`

injects

the right credential per host. The agent points at `127.0.0.1:8080`

and

forgets about keys entirely.

**DLP reverse proxy for LLM calls.** `trustless serve`

puts a scanning

proxy in front of OpenAI-compatible endpoints. Outbound requests are

checked against secret patterns (keyword → regex → entropy, gitleaks-compatible

rules) and masked in-flight before they leave the machine. This is the

layer that catches the "agent decided to include the key in a request" case.

Why not a new vault? Because I already had pass. The CLI reads the existing

store, so there was zero migration. (Bitwarden is supported too, with OAuth

token auto-refresh for Google/Lark.)

The agent gets capabilities, not credentials. That's the whole trick.

If you want to look at the code: trustless is MIT-licensed at

[https://github.com/ikkun1222/trustless](https://github.com/ikkun1222/trustless) — 321 tests, race-detector clean,

cosign-signed releases. It's one implementation of this model; the threat

model discussion is more valuable than the tool itself.