Skip to main content
Syntax

985: Stop putting secrets in .env

47 min episode · 2 min read
·
Theo Ephraim,Phil Miller

Episode

47 min

Read time

2 min

Topics

Leadership, Design & UX, Artificial Intelligence

AI-Generated Summary

Key Takeaways

  • 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.

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.

Notable Moment

Phil Miller described a real incident where a developer accidentally revealed an API key while live-streaming by switching to the wrong editor tab. Within hours, someone used that key to generate a three-thousand-dollar AI bill — illustrating how quickly exposed credentials cause financial damage.

Know someone who'd find this useful?

Episode Transcript

Welcome to Syntax. If you have a dot EMV file sitting on your computer, this is the episode for you because we're gonna talk to you about why you shouldn't be doing that. My name is Wes Boss. And with us today, we've got Theo Ephraim and Phil Miller. They work on Varlock, which is a solution, a library that'll help you inject your secrets into your app and into your coding agents. But, we also just wanna, like, talk about just, like, why is everyone just putting, like, text files on their computer with all of their secrets when we have all of this? Like, logging into Notion for me is like a ritual where I have to, like, use a thousand things, and there's there's beep, bop, boom, pin codes and everything. And then then we just put the, like, database string in a dot e m v file. So welcome, guys. Thanks a lot for coming on. Yeah. Thanks for having us. So let's start there. Yep. What's wrong with dot EMV files? Yeah. I mean, why don't we first just talk about, like, you know, you have these files sitting there. Often, you're putting plain text secrets in there. And, you know, maybe you don't have any, like, super sensitive production secrets in there, but you still probably have some or, you know, maybe you needed to run some script that connected to production. So you put it in there once and, you know, you forget that the file's even there. And, you know, especially now in the era of AI coding agents where they're just reading all your files, slurping it all up, sending it off to some server, like, the only real safe way to ensure that they're gonna be not sent up to, you know, OpenAI is to get them out of plain text altogether. To go back a bit to to answer your question, I think the reason they're sitting in plain text is because every tutorial on the Internet, the first step is put the secret in plain text in a dot e n d file and then then do the rest of the tutorial. So everyone is still telling people to do that even though we know that it's wrong, and then we copy and paste those files on Slack. Right? I think that even the harder challenge is is for the most part that most people don't even know of a different way to do it. Like, that's just the way. Right? Yeah. Or the way that the way the easier way or sorry. The right way is, like, such a pain. Right? Or has seat fees of, you know, $20 per developer per month. So it's like, you're like, oh, I could do it that way, but it's just not worth the hassle. And people like to say that they do, you know, security best practice even if they don't always do them. Right? They're gonna they're gonna …

Get the full transcript (9,008 words) + summary by email — free

One-time email with the complete transcript and AI summary of this episode. No account needed.

One email, no spam. We’ll also show you what SignalCast does.

Browse all Syntax transcripts →

You just read a 3-minute summary of a 44-minute episode.

Get Syntax summarized like this every Monday — plus up to 2 more podcasts, free.

Pick Your Podcasts — Free

Keep Reading

Books, tools, and gear mentioned in this episode

SignalCast may earn commission on purchases via these links.

Tools

  • by Vercel

    teams can mix sources — 1Password for local development, Vercel secrets UI for production — without rewriting application code.
  • VarlockRecommended
    Wes Bos speaks with Varlock creators Phil Miller and Theo Ephraim about why plain-text .env files create serious security vulnerabilities... and how Varlock's schema-driven approach replaces fragmented secret management with a single validated, typed, and vendor-agnostic workflow.
  • by GitHub

    Running `varlock load` as the initial GitHub Actions step catches missing or malformed environment variables before any build or migration runs
  • by Google

    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.
  • by Anthropic

    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.
  • by Google

    Varlock uses a plugin architecture supporting 1Password, AWS Secrets Manager, GCP, Azure, and others, so teams can mix sources
  • by Sentry

    SPONSORS: Sentry
  • by Microsoft

    Varlock uses a plugin architecture supporting 1Password, AWS Secrets Manager, GCP, Azure, and others, so teams can mix sources

More from Syntax

We summarize every new episode. Want them in your inbox?

Similar Episodes

Related episodes from other podcasts

Explore Related Topics

This podcast is featured in Best Cybersecurity Podcasts (2026) — ranked and reviewed with AI summaries.

Read this week's AI & Machine Learning Podcast Insights — cross-podcast analysis updated weekly.

You're clearly into Syntax.

Every Monday, we deliver AI summaries of the latest episodes from Syntax and 192+ other podcasts. Free for one show.

Start My Monday Digest

No credit card · Unsubscribe anytime