8 · The AI-era workflow

The Secret Leak Field Manual · 4 min read

Question this chapter answers: How do assistants and agents move secrets around — and what setup keeps them in the right places?

Nothing here assumes bad intent by a tool or carelessness by its user. Assistants are built to make things work, given the context and access they are granted. The failures are structural, which is good news: structures can be arranged.

How secrets move

Movement	Mechanism	Where it lands
Paste-into-context	A `.env` file or connection string shared as prompt context	Assistant session history; possibly vendor-side storage
Echo-into-files	The assistant reproduces a key it saw into generated code, fixtures, or comments	Source, then every surface downstream
Prove-it-works calls	To verify an integration, the agent runs it with a real credential from the environment	Real API traffic from a machine you did not plan for; sometimes the key itself written into test code
Imitation	One hardcoded key or client-side call in the repo teaches the pattern; later features repeat it	Spread across many files, each diff individually reviewable-looking
Tool configuration	MCP servers and agent tooling configured with provider keys so agents can act	Config files and tool state that few inventories count
Observability drift	Prompts, errors, and payloads containing keys flow into error trackers and log aggregators	Surface 5 of Chapter 1

Least-privilege setups for AI tools

The organizing rule: the agent should hold the least powerful credential that completes the task, for the shortest time.

Scoped keys with spend caps for anything an agent might use to prove integrations work. LLM providers expose project-scoped keys with usage limits; a capped key converts "agent drained the budget" into "agent hit a limit."
Separate development credentials. Agents working in development should never hold production credentials; the environments should not share secrets at all.
Sandbox accounts for third-party services where test modes exist (payment processors' sandbox modes are designed for this).
Short-lived credentials wherever possible — cloud roles assumed per-session rather than long-lived pairs stored where agent tooling can read them.
Deny-by-default env plumbing. Server-only variables stay server-only: secret-bearing values live behind server modules, and no file under a client-facing directory reads them. Frameworks enforce parts of this (private env modules that fail to compile when imported client-side); team conventions enforce the rest.
Instruction files as guardrails, not guarantees. Agent instruction files ("never place credentials in components; route provider calls through /api") reduce frequency. They do not replace scanning, because instructions can be forgotten mid-task exactly like style rules.
Tool configs stay server-side. An MCP server that needs a provider key runs where that key is safe; the browser-facing app talks to your endpoint.

Review patterns for generated diffs

Agent output is still code you ship. Review it with two passes:

Pass one — the diff:

Any new literal matching credential shapes (prefixes from Appendix B) blocks merge.
Any new read of a secret-bearing variable inside client-facing directories blocks merge.
Fallback lines deserve special attention: process.env.X ?? "sk-…"-shaped defaults are how half-done env plumbing ships a real key as a "fallback."
Env renames get the same scrutiny as logic changes — a prefix changed to fix a build error is a publication event.

Pass two — the artifact.

After build, search the output bundle for markers (eyJ, sk_, sk-, AKIA, ASIA, BEGIN PRIVATE KEY, postgres://, mongodb+srv). This takes seconds and sees what the diff cannot: what substitution actually produced.
Then let scheduled monitoring watch the deployed result. Drift-based alerting exists precisely for the reintroduction loop — a key removed in one commit and restored by a later session is the signature AI-era failure, and "it came back" deserves its own alarm, not silence.

What this section does not claim

No setup makes agents safe; the goal is bounded blast radius. With scoped, capped, short-lived credentials, deny-by-default plumbing, two-pass review, and external monitoring, the realistic worst case shrinks from "production drained" to "a capped key burned its own limit and an alert fired." That is the whole game.

Do this now

[ ] Inventory every credential your AI tooling can currently reach (editor settings, agent configs, MCP server configs, shell profiles).
[ ] Replace any production key reachable from development sessions with a scoped, capped development equivalent.
[ ] Add the marker list from pass two to your code-review checklist.
[ ] Write the team's one-line policy on pasting secrets into prompts, and make the sanctioned alternative concrete (a vault reference, not just "don't").
[ ] Turn on change-based alerts for your deployed apps if they are not already watching.