985: Stop putting secrets in .env

What It Covers

Wes Bos speaks with Varlock creators Phil Miller and Theo Ephraim about why plain-text .env files create serious security vulnerabilities, how AI coding agents compound that risk by reading local files, and how Varlock's schema-driven approach replaces fragmented secret management with a single validated, typed, and vendor-agnostic workflow.

Key Questions Answered

• •AI Agent Risk: AI coding tools like Claude Code and Gemini CLI read all local files during sessions, meaning any plain-text secrets in .env files get transmitted to external servers. Moving secrets out of plain text entirely — using a tool like Varlock to fetch from 1Password or cloud vaults at runtime — is the only reliable mitigation against this specific attack surface.
• •Schema-Driven .env Files: Varlock introduces a `.env.schema` file committed to the repo that uses JSDoc-style decorator comments — `@required`, `@sensitive`, `@type=email` — to declare validation rules, documentation links, and vendor fetch functions in one place. This eliminates the dual-file sync problem between `.env` and `.env.example` and auto-generates fully typed TypeScript definitions with IntelliSense support.
• •Sensitive Value Leak Prevention: Marking a variable `@sensitive` in Varlock triggers two runtime protections in JavaScript: automatic redaction in all `console.*` output, and a patch to `ServerResponse` and `Response` objects that blocks the value from appearing in any outgoing HTTP response body — preventing accidental leaks in RSC trees or Express endpoints without manual code review.
• •Vendor-Agnostic Secret Injection: Varlock uses a plugin architecture supporting 1Password, AWS Secrets Manager, GCP, Azure, and others, so teams can mix sources — 1Password for local development, Vercel secrets UI for production — without rewriting application code. A single service account token set in CI unlocks the configured vault, replacing per-developer copy-paste workflows with one centralized fetch.
• •CI Validation as First Step: Running `varlock load` as the initial GitHub Actions step catches missing or malformed environment variables before any build or migration runs, surfacing a clear, redacted diagnostic output instead of a cryptic runtime failure three steps into a workflow. A dedicated GitHub Action wrapper simplifies this for non-JavaScript projects that don't embed Varlock directly in application code.