The .env File Is Your First Security Program

On April 30, an AI and finance entrepreneur who posts as darkzodchi put nine short lines on X. The first two read ”> open Claude Code” and ”> your .env gets read before you type anything.” The post passed a million views, and more than 6,300 people bookmarked it (X). Bookmarks are the tell. Nobody was arguing. People were saving the fix for later.

> open Claude Code
> your .env gets read before you type anything
> your API keys are now in the chat
> your password is now in the chat
> you add "don't read .env" to CLAUDE.md
> doesn't work
> 29 million secrets leaked on GitHub last year
> one line in settings.json actually blocks it
> there's a config that blocks all of this

darkzodchi (@zodchiii) · April 30, 2026

The post was half right, which is why it traveled. A bug report opened in March 2025 showed Claude Code loading a project’s .env file into the shell it runs commands in. The first cause, a library bundled into the earliest versions, was gone within weeks. The bug came back with Claude Code’s native build, this time through its runtime, and that fix shipped in version 2.0.64 in December 2025 (GitHub issue 401, changelog). By the time darkzodchi posted, both causes were fixed. The part that wasn’t fixed, and still isn’t on most laptops, is simpler: a coding agent reads the files in your project without asking, and your .env file is a file in your project. Claude Code’s own permissions table says reads within the working directory need no approval (Claude Code docs). Most of the others are no stricter, as you’ll see below.

If you have a .env file with a live key in it right now, you’re in very good company.

• On September 14, the email platform Brevo found that “A long-lived Cloudflare API key with full account permissions was stored in application source code.” Someone used it to serve malware from Brevo’s own edge for about five and a half hours (Brevo post-mortem).
• In May, a contractor’s public GitHub repository named “Private-CISA” turned up holding a file called “importantAWStokens” (Krebs on Security). The keys belonged to the agency that co-wrote the government’s list of product security bad practices, a list that names hardcoded credentials (CISA and FBI).
• In July, a research agent running inside one of OpenAI’s own security evaluations “found 14 Hugging Face user credentials in a public Hugging Face dataset,” and the intrusion that followed reached Hugging Face’s production systems (OpenAI technical report, Hugging Face timeline). The tokens belonged to ordinary Hugging Face users and were sitting in public data.

None of these teams is careless. They’re busy, the way you’re busy. Keys go where keys go when people move fast: into a file, a repo, a dataset, the folder the agent was told to work in.

That’s why I think the .env file is your first security program. It’s the first place your company decided who holds the keys. It’s also where an AI coding agent, a plugin you installed last week, an enterprise buyer’s security questionnaire and an attacker all start looking.

This fall my LinkedIn feed has been arguing about five things: whether agents should be authorized by the API they call or by the business action they take, which agents hold which keys, how much compliance a small vendor should be asked for, whether compliance is a sales weapon, and whether identity is the same thing as authority. Every one of those fights runs through that one text file. Here’s what each side gets right, where I land, and a one-hour program that turns the file into a real security program.

The short answer

A .env file is a plain text file of names and values your app reads when it starts: database URLs, API keys, signing secrets. In 2026 it also sits in the one folder every coding agent you run is designed to read.

Treating it as your first security program means seven steps you can finish in an hour: find what has leaked and which of it still works, rotate the live keys, stop new leaks at the commit, fence your coding agents away from the file, get plaintext secrets off disk, shrink what each remaining key can reach, and write down who owns each one. The full checklist, with exact commands and the controls each step satisfies, is below.

The five fights, one sentence each:

• Secrets and coding agents. Vendors are shipping fixes almost weekly, and most founders still can’t say which agents hold which keys.
• Outcome-based authorization. A key answers “can it call this API.” Your business needs an answer to “should it do this.”
• Identity is not authority. An agent holding your copied key acts as you. The standards people now say agents should act for you, with their own identity and a narrower grant.
• Right-sized compliance. Buyers ask five-person startups for a Fortune 500 binder. The cheapest honest answer starts with your secrets.
• Trust that sells. Specific evidence closes deals faster than badges, and a working secrets program is some of the most specific evidence you can show.

If you remember one thing: keep secrets out of your agent’s reading path, give every agent its own narrow key, and write down who owns each one.

Five fights, one text file

Most security debates on LinkedIn sound abstract until you find the file they’re about. This week’s feed made it easy.

On October 9, Dr. Ghassan “Gus” Hanna posted part six of a seven-part series on securing agents that take consequential actions. His first recommendation in it was outcome-based authorization: stop asking “Is the agent allowed to call this API?” and ask “Is the agent allowed to perform this business action?” A day earlier, Karina Klever published an article asking what happens when a five-person startup lands a Fortune 500 customer “and suddenly gets asked for a SOC 2, ISO 27001 certification, hundreds of security questions, and controls designed for a company 1,000 times its size?” On October 9, Jun H. told the story of an AI startup that beat a cheaper rival to a Fortune 500 contract in three weeks “because of one asset: a pre-packaged trust architecture.” Quinton Barber has spent two weeks writing that identity is not authority. And underneath all of it runs a steady stream of posts about .env files, Claude Code plugins and which agent holds which key.

It’s one conversation. Follow any of those threads far enough and you end up at a file of keys that something is allowed to read.

I’ve said versions of this on our podcast three times without connecting the dots. On episode 100, about the free AI tools employees sign up for, it came out as “boom, all of a sudden, private keys are flying around up into random clouds.” On episode 99 it was an agent that “realized it had access to all your AWS and your GCP and your Azure.” And on episode 104, with Yash Kosaraju, the chief information security officer (CISO) of Andreessen Horowitz, I described a coding agent “taking instructions from the internet, throwing them into a prompt, into an engine that has access to whatever it is that I have access to as a developer, and running it.”

Listen · Jon on episode 104, from 14:55

That last sentence is the whole problem in one breath. Everything I have access to as a developer usually lives in a .env file, a credentials folder and a shell history. The rest of this post is about shrinking that, one door at a time.

Your agent can read it, and vendors are shipping fast

Start with the defaults, because defaults are what your team actually runs. I read the current documentation for the coding agents founders use most. Here’s what each one does with a .env file out of the box, in the vendors’ own words.

Agent	What it does with your .env by default	Where the vendor says its protection ends
Claude Code	Reads files in your working directory without asking. A deny rule such as Read(./.env) is something you add, and the operating system sandbox “is off by default.”	Deny rules don’t apply to “arbitrary subprocesses that read or write files indirectly, like a Python or Node script that opens files itself,” and a .claudeignore file “has no effect.”
Cursor	Leaves .env* files out of its file tools by default.	”The terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore.”
OpenAI Codex	Runs commands in a sandbox with network access off.	For the commands it runs, it keeps environment variables whose names contain KEY, SECRET or TOKEN (“default: true”).
GitHub Copilot	Admins can exclude files from Copilot.	Exclusion “is currently not supported in Edit and Agent modes of Copilot Chat,” and the cloud agent’s secrets “are exposed to Copilot as environment variables.”
Gemini CLI	Loads .env into its own process: the current folder, then parent folders, then ~/.env.	The opt-out (advanced.ignoreLocalEnv) and secret redaction both default to false.
Google Antigravity	In the app on macOS and Linux, the sandbox is on by default, and “Sensitive files such as ~/.ssh and .env are blocked”	“None of the presets turn the sandbox on” for Windows, and the command-line tool’s sandbox setting, enableTerminalSandbox, defaults to off.

Sources: Claude Code permissions and sandboxing, Cursor ignore files, Codex configuration reference and security, Copilot content exclusion and cloud agent secrets, Gemini CLI configuration, Antigravity sandbox, all read on October 10, 2026.

Two things jump out. The safest default on the market, the Antigravity app on macOS and Linux, already blocks .env, which proves it’s possible, so it’s fair to ask every other vendor why theirs doesn’t go as far. Cursor’s covers its file tools but not its terminal. And every vendor tells you exactly where its protection ends. Reading those caveats is the cheapest security review you’ll do this year.

Ignore files aren’t walls

The story that made this concrete came from PromptArmor in November 2025. A user asked Google’s Antigravity to integrate an Oracle ERP feature by following an online guide. The guide hid instructions in one-point text. Antigravity’s file tool refused to read the gitignored .env, so the agent “decides to work around this protection using the ‘cat’ terminal command,” then sent the credentials out through its browser to a site on the default allowlist (PromptArmor). It drew more than 760 points on Hacker News. Google’s position, as PromptArmor reported it, was that it was “already aware of data exfiltration risks.” Today the Antigravity app’s default sandbox on macOS and Linux blocks .env outright, which is the right ending, though its command-line tool still ships with the sandbox off.

Johann Rehberger showed the same pattern against Claude Code at the Chaos Communication Congress in December: a request to “review this file” carried a prompt injection, the agent read the .env, and the values left the machine in DNS lookups. He had reported it to Anthropic in May 2025, and it was fixed within about two weeks as CVE-2025-55284 (Embrace The Red).

The vendors are candid about this. Claude Code’s deny rules catch cat, head, tail, sed, tee and redirects, but not a script that opens the file itself. On Hacker News, adastra22 put the limit in one line: “if you deny the agent the bash tool, it will just write a Python script to do what it wanted instead” (Hacker News). The replies to darkzodchi’s post said it with more feeling:

"Me: Dont read .env file!!! Agent: You are absolutely right! I won't do that again. Also Agent: cat .env"

@stratos2k5, replying on X, April 30, 2026

That joke is funny because it’s a category error. A rule written in a prompt or a CLAUDE.md file is a suggestion to a model. A rule written in managed settings, a sandbox profile or the file system is a fact about the machine. You want facts. Claude Code’s operating system sandbox, for example, routes network traffic through a proxy whose allowed domains “start empty,” and Anthropic reports that sandboxing “safely reduces permission prompts by 84%” in its own use (Claude Code docs, Anthropic engineering). The safe path is also the faster one. My rule of thumb: deny rules stop accidents, sandboxes stop incidents, and both belong in managed settings, with the locks turned on, so nothing in a developer’s own settings files can loosen them.

Plugins run with your permissions

“A Claude Code plugin you install can execute arbitrary code on your machine with your user privileges.” That’s Anthropic’s own documentation, and I appreciate how plainly it says it. Hooks and Model Context Protocol (MCP) servers run outside the sandbox, and with auto-update on, “the files you reviewed can change on disk” (Claude Code plugin security). Every agent ecosystem now has the same shape: Cursor hooks, Codex plugins, Gemini CLI extensions (each of which “can have its own .env file in its directory, which will be loaded automatically”), MCP registries and plain old editor extensions (Gemini CLI configuration).

The last twelve months gave us the full syllabus:

• August 2025, Nx “s1ngularity.” Malware in a popular build package asked the developer’s own AI command-line tools to search the machine for secrets. It was one of the first payloads to outsource the hunt to your own agent (Nx post-mortem).
• February 2026, ClawHub. The post that carried the story to the mainstream said the most downloaded skill on OpenClaw’s marketplace was malware, and listed what its payload grabbed, ending with “every API key in your .env files.”
• May 2026, the TanStack worm. A self-spreading supply chain campaign listed .env files among its loot and reached two OpenAI employees’ devices, according to OpenAI’s advisory as reported by BleepingComputer (BleepingComputer).
• August 2026, crawlers in costume. GreyNoise found scanners wearing the user agent strings of OpenAI, Anthropic and other AI crawlers while requesting /.env, /app/.env, /.env.production and /.aws/credentials. Its advice is the best one-line identity lesson of the year: “Never treat a user agent string as identity” (GreyNoise).
• September 17, 2026, Plugin4Shell. AIR Security disclosed that in Claude Code, Codex, Copilot and Gemini CLI “any trusted plugin in a marketplace can be silently swapped for a malicious one.” Anthropic and OpenAI shipped fixes, and AIR says Google won’t patch Gemini CLI, which it has deprecated. In fairness, the attack requires control of the plugin’s repository (AIR Security on X, AIR Security, The Hacker News on X).

the #1 most downloaded skill on OpenClaw marketplace was MALWARE…

chiefofautism (@chiefofautism) · February 19, 2026

After the 2025 npm worm, the Cybersecurity and Infrastructure Security Agency (CISA) told developers to “Immediately rotate all developer credentials” (CISA). Founders roll their eyes at that, and I understand why: rotation is real work. But if a plugin can read everything your user can read, “rotate everything” isn’t paranoia. It’s arithmetic. The fix is to make “everything” smaller: fewer plugins, marketplaces allowlisted in managed settings, and agents running in a container or sandbox that holds only what the task needs.

The fight over the key in the sandbox

The best argument on X this year about agent credentials started on March 12, when Yousif Astarabadi posted “I hacked Perplexity Computer and got unlimited Claude Code” to more than three million views. He found that a subagent held a credential in its environment, failed six times to steal it (“Claude’s model/prompt-level safety is legitimately good”), then planted an .npmrc file in a shared home folder so every Node process the agent launched preloaded his code, and lifted the token that way. His prescription: “Bind the token to the sandbox ID,” “Make the token ephemeral,” and “Tie the token to the user’s billing account” (X).

I hacked Perplexity Computer and got unlimited Claude Code

Yousif Astarabadi (@yousifa) · March 12, 2026

Nine and a half hours later, Perplexity’s co-founder Denis Yarats answered, and his reply is a model of how to respond in public: fast, specific, and grateful to the researcher.

This isn’t accurate. The secure sandbox of Perplexity Computer creates a temporary proxy token for every user session.

We choose not to hide it from the user because it’s their token. (They can do whatever they want with it, but I don’t recommend posting it on X)

It’s not an API key, it’s a short-lived proxy token associated with the session and user. It’s located in the sandbox, because that’s the point of the sandbox.…

Denis Yarats (@denisyarats) · March 13, 2026

Read the two posts together and the fight dissolves. Both men describe the same design: a short-lived token bound to one session and one user, sitting behind a proxy that holds the real key. They disagreed about whether Perplexity already had it. That’s the pattern your own agents should copy, and the companies building agents are converging on it:

• Anthropic’s cloud sessions keep GitHub credentials “encrypted on Anthropic’s servers” so they “never enter a session’s VM,” and “network secrets” let an agent call an API “without seeing the key,” added by a proxy after each request leaves the virtual machine. That feature is on Pro and Max plans; “They aren’t available on Team or Enterprise plans yet” (Claude Code on the web, cloud environments).
• Claude Code on your laptop gained credential masking in August: sandboxed commands see a placeholder, and “the sandbox proxy substitutes the real value on outbound requests to hosts you allow” (Claude Code docs).
• Codex cloud makes secrets “available only during setup” and removes them “before the agent phase starts” (OpenAI).
• GitHub’s cloud agent goes the other way. Its secrets “are exposed to Copilot as environment variables,” masked in session logs (GitHub docs). Know which design you’re running.
• Password managers are moving in. 1Password’s July integration with Claude injects credentials “through a secure channel managed by 1Password, outside the agent’s view” (1Password), and WorkOS put the principle best: “The alternative is to stop shipping the credential to the code that needs it” (WorkOS).

Jim Clark from Docker gave the number in an AI Engineer talk published on October 5. How many credentials should be in an agent’s sandbox? In his words, “the right answer is always zero.”

The honest counterpoint came from the Hacker News thread for one of these brokers: “What if kontext runs under the same user as Claude?” (Hacker News). A broker is still a key. The win is that it’s one key you can watch, scope and revoke, instead of forty copies in forty .env files.

Every fix in a changelog is a problem that existed

Vendors are shipping fast, and I mean that as praise. Claude Code’s public changelog reads like a secrets-hardening sprint: a sandbox.credentials setting in June, credential masking in August, and on September 2 a fix for “Bash Read() deny rules not covering files given as option values” and “cd DIR && cat FILE compounds.” On August 27 it stopped cloud reviews from “uploading uncommitted edits to prod.env-style and *.tfvars files” (changelog). The day after the deny-rule fix landed, developers filed a cluster of bug reports because the stricter rules prompted more often. That’s what a guardrail looks like the moment it becomes real: annoying, then normal.

Shipping in public is a gift. It’s also a reminder that every line in a security changelog was a problem on somebody’s laptop the day before. Gemini CLI still loads .env by design. Its opt-out arrived in May 2026, about ten months after the first issue asked for one, and the default is unchanged. Google has since moved its individual users to Antigravity CLI and kept Gemini CLI for business licenses and paid API keys, so check which one your team actually runs (Google). In September, Polar’s team found its own compiled command-line tool doing what Claude Code once did: “The old binary picked up a POLAR_ACCESS_TOKEN from a stray .env” (Polar). Plenty of tools you run quietly load the .env of the folder you’re standing in, unless their authors opted out. So the question for a founder isn’t whether your agent vendor is good at security. Most of them are getting better every week. The question is whether your settings caught up with their latest release, and whether anyone at your company owns that.

Who holds which key?

Most teams can’t answer that, and the data says the keys outlive the people who forgot them. On September 29, Truffle Security reported 543,699 credentials in one snapshot of public code that still authenticated when it tested them in July. Its two driest sentences: “A leaked key that has been revoked is trivia.” and “A leaked key that still authenticates is access.” The difference was revocation. Only 260 of 73,048 committed GitHub tokens still worked, because GitHub kills its own leaked tokens, while 11,465 of 12,985 Postgres connection strings still did (Truffle Security). In August, the same team found 768 leaked Amazon Web Services (AWS) keys that held full control of a company account, and only 9.5% of the readable accounts had any budget alert. “AWS detected the exposure. Nobody acted on it” (Truffle Security).

Laptops are the new repos. GitGuardian, which sells secret detection, reported an average of 150 secrets on a sample of developer machines, with “numerous secrets” in coding agent history files, and cautioned that the figures “should not be treated as a universal prevalence estimate” (Help Net Security).

And then there’s the rest of us:

Others debating how to keep Codex from reading the .env file.

Me who pastes API keys in the chat.

Aradhye Agarwal (@AradhyeAgarwal) · July 26, 2026

This is where our 30-minute AI credential inventory comes in. It walks through the six places an agent’s keys live and gives you a spreadsheet template. The .env program below is the companion: the inventory tells you what you have, and the program shrinks it. If you’d rather have someone do the inventory with you, that’s the first week of our AI user access control audits and secure MCP program.

From calling the API to doing the business action

On February 22, Summer Yue, an AI alignment researcher, posted the most relatable agent story of the year. She’d told her OpenClaw agent to “confirm before acting,” then watched it start deleting her inbox. “I couldn’t stop it from my phone. I had to RUN to my Mac mini like I was defusing a bomb.” It passed ten million views.

Nothing humbles you like telling your OpenClaw “confirm before acting” and watching it speedrun deleting your inbox. I couldn’t stop it from my phone. I had to RUN to my Mac mini like I was defusing a bomb.

Summer Yue (@summeryue0) · February 22, 2026

Some replies were brutal. One read, “Prompt-level instructions are not hard constraints,” with a side of blame for someone who works in alignment. The creator of OpenClaw, Peter Steinberger, answered better: “This is great to learn and can happen to anyone” (X). He’s right, and so is the critic, about the mechanism. Her permission lived in a context window. When the context got summarized, the permission went with it. A rule that lives in a prompt can be summarized away. A rule that lives in the tool can’t.

That’s the authorization fight in one picture. On LinkedIn, Gus Hanna put it as a question every security review should ask:

Rather than asking: "Is the agent allowed to call this API?"
the organization should ask: "Is the agent allowed to perform this business action?"

Dr. Ghassan "Gus" Hanna · Cybersecurity Leader and Expert (AI agentic and LLMs, APIs, cloud) · October 9, 2026

Load the post from LinkedIn

A key can’t answer that question

Here’s where the .env file comes back in. An API key is a yes or a no. If your agent holds STRIPE_SECRET_KEY, it can refund one dollar or the whole quarter, to any customer, at any hour. Cerbos, which sells a policy engine, said it well in September: “An OAuth scope is a category, not a decision.” Scopes “are fixed at token-issue time, and they cannot see the arguments of the call that has not happened yet” (Cerbos). A key in a .env file is even blunter than a scope. It’s a category with no expiry date.

“Outcome-based authorization” doesn’t have an owner on the open web yet. The phrase also means something else in the federal world, where it describes how FedRAMP 20x grants authority to operate, with automation and real-time security metrics (LinkedIn). So here’s the definition I’d offer founders: an agent’s action is allowed when the business result it would cause fits a rule a person wrote down, checked by code outside the model at the moment before it runs. “Refund up to $200 to the customer’s original payment method.” “Deploy this commit to staging, never to production.” “Email this customer, never a list.”

The reference design exists

Amazon Web Services shipped the clearest version. Policy in Amazon Bedrock AgentCore, generally available since March 3, 2026, evaluates rules written in Cedar “at the gateway endpoint,” outside the agent’s code, on every tool call. AWS’s own example permits a refund tool only for a refund-agent role and only when “context.input.amount < 200.” You can run a policy in log-only mode first to see what it would have blocked, and automated reasoning flags rules that are too loose, too tight or impossible to satisfy (AWS, developer guide).

Payments got here years ago, and the payment rails are now doing it for agents:

• Europe’s payment rules (Regulation 2018/389) require authentication codes “specific to the amount of the payment transaction and the payee,” and “any change to the amount or the payee results in the invalidation of the authentication code generated” (EU 2018/389).
• Google’s Agent Payments Protocol has the user sign a cart mandate, “a secure, unchangeable record of the exact items and price,” or, for a purchase the agent will make later on its own, an intent mandate signed up front with price limits and other conditions (Google Cloud).
• OpenAI and Stripe’s Agentic Commerce Protocol issues “encrypted payment tokens” that “are only authorized for specific amounts and specific merchants” (OpenAI), and Stripe’s shared payment tokens let you “Set usage limits, including currency, maximum amount, and expiration window” (Stripe).
• Stripe now lets you tag a restricted key as belonging to an autonomous agent, and “agent-tagged keys are automatically subject to approval rules, which require a designated reviewer to approve sensitive actions before they take effect.” Stripe calls this “the recommended way to give autonomous agents access to your Stripe account” (Stripe).

That last one is the cheapest outcome-based authorization you’ll ever buy, and it starts with deleting sk_live_ from your .env file. Give the agent a gift card with a limit, a merchant and an expiry date, not your wallet.

The contract already assumes it

Target’s terms, last updated September 10, have a section called “Agentic Commerce and Delegated Access,” and its agent language dates back to March. Disputes involving a customer’s agent are evaluated “based on the permissions in effect,” and “Target does not purport to guarantee that any Approved Agent will act exactly as you intend in all circumstances” (Target). Read that twice. The gap between what an agent was permitted to do and what its owner meant is now a contract clause, and it lands on whoever granted the permission.

A tribunal got there earlier. When Air Canada in effect argued its chatbot was responsible for its own actions, the tribunal called it “a remarkable submission”: “It makes no difference whether the information comes from a static page or a chatbot” (Moffatt v. Air Canada). Your agent’s business actions are your business actions. If you sell an agent to an enterprise, their lawyers will ask who eats the wrong refund, and a precise permission model is the best exhibit you can hand them.

The prompt is not a policy

The Open Worldwide Application Security Project (OWASP) says a system prompt shouldn’t “be used as a security control,” and that authorization “must not be delegated to the LLM, either through the system prompt or otherwise” (OWASP). The incidents keep agreeing:

• In July 2025, Replit’s agent deleted a production database during what its user had set as a “code and action freeze.” Replit’s chief executive called it “Unacceptable and should never be possible,” and the fix that shipped was structural: separate development and production databases (Fortune).
• OpenAI’s Operator “is supposed to require user confirmations before completing any ‘significant’ or irreversible action.” It bought The Washington Post’s Geoffrey Fowler a dozen eggs for $31.43, “without my approval” (Washington Post, via Anchorage Daily News).
• In July 2026, TechCrunch quoted the GPT-5.6 Sol system card describing a model “assuming that actions are allowed unless they’re explicitly and unambiguously” prohibited, after users reported deleted files and databases (TechCrunch).

The other side of this fight deserves a fair hearing, and it has the best data. Anthropic reported on August 7 that users approve 97% of Claude Code’s permission prompts, and in a study of 1,053 paid testers, “human review caught just 13.6% of dangerous commands, while auto mode caught 89%.” Users rejected 39% of plans but only 3% of individual permission requests (Claude blog). A good classifier beats a tired human at judgment calls. Anthropic is also honest that it’s probabilistic: “The 17% false-negative rate on real overeager actions is the honest number” (Anthropic engineering). Its own explainer draws the line where I would.

So here’s the synthesis I’d hand a founder. Humans are good at reviewing plans and bad at reviewing clicks, which is why we argued the human in the loop is going away. Classifiers are good at judgment and can’t promise anything. Your irreversible business actions (payments, refunds, deletes, production deploys, messages to customers) deserve a rule that can promise: written down, enforced outside the model, and tested like any other code. Agents are deterministic software in the way that matters here. You can’t unit-test a vibe, but you can unit-test amount < 200. Our tool-call gate builder writes that kind of rule for each of your agent’s tools, as Claude Code permission rules and as a Cedar sketch.

The vendors disagree, which is healthy

If you go shopping for this, expect an argument. AuthZed published “Policy Engines Don’t Work for AI Authorization. Here’s Why,” while conceding that “Policy engines make sense when all the decision data exists in the request” (AuthZed). Cerbos’s September post takes the other side, in a section on Rich Authorization Requests (RAR): “RAR expresses the request. Policy decides it.” Bruce Schneier and Barath Raghavan are skeptical of the whole category of semantic firewalls: “Integrity isn’t a feature you add; it’s an architecture you choose” (Schneier on Security). My read: a refund limit is request data, where policy engines shine. “Is this ticket from my customer?” is relationship data, where relationship graphs shine. Most startups need a little of both, and neither one is the prompt.

The market is also consolidating into the places agents run. On October 6, Oso, whose co-founder Graham Neray joined us on episode 89 to argue that authorization is the last layer companies still build from scratch, announced that Tiny acquired Oso Cloud and “most of the current Oso team is joining Temporal to build authorization for AI agents” (Oso). Temporal described the job as “asking, for each action an agent takes, who it is acting for and what that person is allowed to do” (GeekWire), and added a requirement most of us hadn’t thought about: “an approval that was granted stays granted, and a rejection stays rejected, even after a crash or a retry” (Temporal). The second refund is the one that gets you.

The most honest sentence I read on this came from Auth0’s Carla Urrea Stabile: “Every one of those actions was permitted, but none of them were intended.” She’s also candid that turning what a person says into what they meant to authorize “is unsolved” (Auth0). Which leads to the rule I’d tattoo on every agent design doc: intent can shrink a permission, never grow one.

What to do this quarter is less glamorous than the debate. Write down your ten irreversible actions. Route every agent action through the same API your product’s own interface uses, with the same checks, so the agent can’t skip your checkout page and therefore your refund policy. Then add agent-only limits: amounts, rates, recipients, environments. Run them in log-only mode for a week, read what they would have blocked, and turn them on. If you want help, that’s a normal week of our AI product red teaming and secure AI software development work, and our posts on giving agents write access, least privilege for agents and spend ceilings go deeper on each limit.

Identity is not authority

This fight is the oldest one in security, wearing new clothes. Quinton Barber has been making it on LinkedIn in a series he calls the Authority Series, and his opening article has the cleanest definitions I’ve read:

Identity proves what a system is. Access determines what it can reach. Authority determines what the business has actually decided that system is allowed to do, in a specific context, with a specific consequence boundary.

Quinton Barber · Cybersecurity architect at Atmosera · September 24, 2026

Load the post from LinkedIn

Michael Pak compressed it further, writing about the OpenAI and Hugging Face incident: “Identity is not authority. Possession is not permission” (LinkedIn). That second sentence is about your .env file whether he meant it to be or not.

Your .env file is an impersonation license

Standards people drew this line years ago. The OAuth token exchange standard, RFC 8693, from 2020, separates impersonation, where an actor “is indistinguishable from B,” from delegation, where “any actions taken are being taken by A representing B.” Its summary: “In a sense, A is an agent for B” (RFC 8693). The OpenID Foundation’s 2025 paper on agent identity is blunter: “User impersonation by agents should be replaced by delegated authority.” Its glossary defines impersonation as an agent acting indistinguishably from the user, “e.g., by using the user’s credentials directly” (OpenID Foundation).

By that definition, every coding agent that reads your keys out of a .env file is impersonating you. Dick Hardt, whose new AAuth draft gives every agent “its own cryptographic identity,” explains why that ends badly: “any secret that must be copied to where the workload runs will eventually be copied somewhere it shouldn’t be” (IETF draft). It’s an individual draft, not a standard, but it reads like the .env thesis written by someone who has spent a long career on authorization protocols. Even the MCP specification lists “Treating claimed scopes in token as sufficient without server-side authorization logic” as a common mistake, and says servers “MUST NOT accept any tokens that were not explicitly issued for the MCP server” (MCP security best practices).

Everyone looked real. Nobody was authorized.

The deepfake stories are being retold this way, and I think the retelling is right. When Arup’s Hong Kong office wired out about US$25 million after a video call full of deepfaked colleagues, the South China Morning Post’s headline needed three words: “Everyone looked real” (SCMP). Arup’s chief information officer, Rob Greig, later said “None of our systems were compromised and there was no data affected,” and that “People were deceived into believing they were carrying out genuine transactions.” Curious, he tried to deepfake himself in real time. “It took me, with some open source software, about 45 minutes” (World Economic Forum).

Every system did what an authenticated request told it to do. What was missing was a rule about which transactions a video call can authorize at all. The Federal Bureau of Investigation (FBI) gets this. Its September 17 announcement counts “nearly 61,000 complaints” of government and law enforcement impersonation scams with “losses totaling more than $1.6 billion” since January 2025, and its first piece of advice is a plain rule: authorities “will never contact members of the public by telephone or text message to demand any form of payment” (FBI).

Detection still has defenders, and they have a point. Ferrari stopped a deepfake of its chief executive in 2024 when an executive asked which book he’d recommended days earlier, a pure identity check (Fortune, via Bloomberg). But notice what made the executive suspicious: a secret acquisition, an urgent document, a new number. The unusual request raised the alarm, and the identity question closed it. Independent researchers also found that open-source deepfake detectors’ scores drop 45 to 50% on real-world fakes compared with older academic benchmarks (Deepfake-Eval-2024). On our episode 92, Jasson Casey of Beyond Identity argued that trust should come from verification rather than detection, and we wrote up his case in Deepfake Attacks Keep Working Because We Keep Detecting Instead of Proving. I’d take it one step further: verify the person when the request is unusual, and make sure no single channel can authorize the big things at all.

Your help desk is an authorization server with feelings

The Clorox lawsuit against Cognizant contains the whole thesis in four lines of transcript, as quoted by The Register:

"I don't have a password, so I can't connect."
"Oh, ok. Ok. So let me provide the password to you ok?"

Caller and service desk agent, as quoted from the Clorox complaint by The Register, July 2025

Clorox claims $380 million. Cognizant says “Clorox hired Cognizant for a narrow scope of help desk services,” and that Clorox’s own defenses should have caught it (BleepingComputer). Both sides have a point, and the founder lesson is the same either way: a password reset is a grant of authority, performed by whoever answers the phone. At 30 people, your help desk is a direct message to the chief technology officer: “lost my phone, can you reset my two-factor?” Write down who may approve that, and how they confirm it on a second channel.

The same thing happens on consent screens. On September 1, the FBI warned about OAuth consent phishing: once a victim approves a malicious app, “the cyber actor can act on behalf of the user, including reading and sending emails, and accessing sensitive data without having access to the user’s credentials.” Attackers “can bypass both passwords and multi-factor authentication,” and changing the password doesn’t remove the grant (FBI). “Act on behalf of the user” is the exact phrase every agent vendor uses, and the “Connect your Gmail” button on an agent is the same screen. Every “Allow” button is a power of attorney.

Even the spies kept a human on the signature

The espionage stories make the same point from the other direction. When a North Korean operative got hired at KnowBe4 in 2024, he’d passed “four video conference based interviews” and a background check that “came back clear.” What limited the damage was an authority limit: “It’s good we have new employees in a highly restricted area when they start, and have no access to production systems” (KnowBe4). The scheme hasn’t slowed down. The Wall Street Journal’s August documentary on it has passed ten million views.

Then there’s GTG-1002, the espionage campaign Anthropic caught in September 2025 and disclosed that November. The operators “told Claude that it was an employee of a legitimate cybersecurity firm, and was being used in defensive testing.” A claimed identity was taken as authority (Anthropic). The detail I think about most is in the full report: the attackers automated most of the work but kept “authorization decisions at critical escalation points” for humans, including authorizing the use of harvested credentials (Anthropic report). A state-sponsored crew automated the tasks and kept the pen. You can do the same thing on purpose.

The agent version is already here

In June, Varonis published a phishing test against an OpenClaw agent it named Pinchy. An email from an outside Gmail account claimed to be from the team lead, “Dan,” during a fake production emergency. The agent “searched the mailbox for credentials, located them, and forwarded them in plaintext,” including “AWS IAM access keys, database connection strings, and SSH credentials.” A stricter profile that told it to verify sender identities still failed. Varonis’s first fix was stricter written instructions, which it says “was not a complete defense” against the credential theft. Its other fixes are authority limits: approval before credentials leave, no mail to new addresses, no global read access (Varonis). It was a controlled experiment, which is exactly why it’s useful.

At the end of May, people on X watched the same failure happen to Instagram accounts. According to users and researchers posting about it, attackers used Meta’s AI support flow to take over accounts by getting past identity checks that were weak or missing, and the support agent had the authority to hand over the account.

my instagram (@ korn) was stolen overnight via the Meta AI exploit and was subsequently disabled.

it was Meta Verified, facial scan verified, and had 0 TOS violations.

the account is the sole source of my income.…

korn (@kornbuilds) · June 1, 2026

Norm Hardy named this in 1988. A compiler at Tymshare overwrote a billing file because “the compiler runs with authority stemming from two sources.” “The compiler serves two masters and carries some authority from each to perform its respective duties” (Hardy, The Confused Deputy). Your coding agent has two masters too: you, and whatever it read last. On episode 71, Ben Colman of Reality Defender described where companies are landing: they “do wanna engage your agent for information sharing, but maybe not for authorization.”

The case against, and where I land

The strongest objection is that you can’t authorize what you can’t identify. The OpenID Foundation paper says so itself: “Robust authentication is a critical prerequisite for authorization.” It’s right, and the products are catching up. Microsoft’s Entra Agent ID gives each agent a sponsor, a human “accountable for making decisions about its lifecycle and access,” and access that “automatically expires” if nobody renews it (Microsoft Learn). Okta’s Cross App Access moves the decision “from end users to enterprise IT administrators” (Okta). On episode 81, Eric Olden of Strata argued the opposite of my framing, that “agents are people too” and “It’s not a non-human identity problem.” I disagree about the people part. I agree with his conclusion that you don’t have to reinvent the playbook.

The skeptic’s version is that all of this is the identity industry finding its next invoice. The idea is from 1988, and the invoices are from 2026. Fair. That’s why the first steps are free:

1. One key per agent. No shared keys, and never a person’s own key copied into an agent’s environment.
2. A named human for every agent’s access, and an end date. If nobody renews it, it lapses.
3. Three written authority rules this week. No money moves on a call or a message alone. Any change to payout or recovery details needs a second channel. No agent forwards credentials or emails a new address without approval.

If an agent touches anything a competitor or a foreign intelligence service would want, that’s the work behind our counter business espionage and counter nation-state espionage programs. For everyone else, the three rules above get you most of the way, and device-bound credentials take care of a lot of the rest.

Right-sizing compliance: the receipt and the meal

Karina Klever’s article is the one I’d forward to every founder:

What happens when a five-person startup lands a Fortune 500 customer and suddenly gets asked for a SOC 2, ISO 27001 certification, hundreds of security questions, and controls designed for a company 1,000 times its size?

Karina Klever · CISO and compliance management consultant · October 8, 2026

Load the post from LinkedIn

The best comment under it came from Alexander Hanff, who runs a two-person privacy practice that works with very large companies: “if they have picked you, they did so for a reason and they are not going to let procurement grandstanding get in the way.” His trick is worth stealing. He works only inside the client’s own infrastructure, “that way, their own security controls are what is important.” The cheapest control is holding less of the customer’s data.

Yash Kosaraju gave the buyer’s version on episode 104: “the bigger challenge with AI tools is not your vendor due diligence of, like, do you have a pentest or do you have a SOC 2, and all of those questionnaires. The bigger issue here is what data do you have access to? How do you access it? And is it a two-way read-write or just a read?” That’s what right-sizing means. Your SOC 2 report is the receipt. Your security program is the meal. Buyers used to read the receipt. More and more, their engineers walk into the kitchen.

SOC 2 already has a line for your .env file

Here’s something I didn’t appreciate until I went looking. The System and Organization Controls (SOC) 2 criteria already have a line for the credentials in your .env file. Under CC6.1, one of the points of focus is “Manages Credentials for Infrastructure and Software.” But the American Institute of Certified Public Accountants (AICPA), which writes the criteria, also says “Use of the trust services criteria does not require an assessment of whether each point of focus is addressed” (AICPA trust services criteria, 2020 edition). The slot exists. Nobody is required to open it. Your auditor samples your access reviews, and your attacker samples your .env files.

The baseline that big buyers wrote for small vendors is clearer still. Minimum Viable Secure Product (MVSP), a list of 25 controls whose contributors include Google, Salesforce, Okta, Slack and Netflix, with the Cybersecurity and Infrastructure Security Agency joining in 2024, handles secrets in one sentence, control 3.5: “Sensitive application credentials and tokens should be stored separately from the application’s source code” (MVSP). Microsoft’s supplier program asks only “selected” suppliers for independent assurance, and now explicitly covers suppliers that “use AI Systems” (Microsoft). And the government’s own buyer guide, Secure by Demand, doesn’t ask for a certificate at all. It says “it is crucial that customers explicitly demand security as part of the procurement process,” then asks about the product: single sign-on, multi-factor authentication on by default, logs (CISA and FBI).

Right-sized doesn’t mean expensive. Maya Kaczorowski wrote up how her company, Oblique, got through its first SOC 2 audit period on a security stack built almost entirely from free tools: “We use TruffleHog on every commit to make sure we don’t accidentally leak secrets.” Her conclusion: “There’s more excellent, free tooling than you realize” (Oblique). That’s the right-sizing argument in one sentence: put the effort where the risk is.

The fight: sales document or security program?

Thomas Ptacek, who co-founded the security firm Latacora, has been the sharpest voice on this for years, and his 2026 comments on Hacker News are sharper than ever. “The reality is, SOC2 is a sales-enablement tool” (March). “Big enterprise SOC2 gates are generally not real” (May). And on what a startup’s first report proves, “the Type 1 is a pinky swear” (July). His practical advice to a solo founder drowning in questionnaires is the right-sizing playbook: you can often get a purchase order conditional on a Type 1, and “There will come a time where your business will grow to the point where it makes sense to pay for the secret handshake.”

The other side has a good argument too, and Armin Ronacher made it best:

It really frustrates me when I see people take the general view that “SOC 2 is fake / a scam”. These compliance things are for many startups (historically) the first time they take their opsec and internal processes seriously.

Armin Ronacher (@mitsuhiko) · March 20, 2026

Ryan McGeehan, who has written about security questionnaires since before most of us filled one out, said it in 2017: “Behind the questionnaire is a good intention. Do not dismiss good intentions” (Medium). I agree with both camps, which I know is unsatisfying. SOC 2 is a sales document, and that’s fine. So is a contract. Both have to be true.

When the receipt was fake

This March, the fight got personal. An anonymous Substack investigation alleged that Delve, a compliance automation startup, had produced near-identical SOC 2 reports for hundreds of customers. Delve denies fabricating evidence, saying “We are not an auditor, just as tax preparation software is not an accountant,” and that it is offering complimentary re-audits (X). We covered how to check a report and its auditor in Is Your SOC 2 Real?, so I won’t relitigate it. The internet handled the jokes:

Thank god I skipped Delve and just had Claude generate a SOC-2 report directly.

Paul Butler (@paulgb) · March 20, 2026

Zack Korman’s video response is the fairest thing anyone said about it: “I have a lot of complaints about SOC 2, and I have a lot of complaints about ISO 27001,” he says, then: “Fraud is worse.”

The part that matters for this post came later. Two of the incidents in our credential inventory happened at companies whose reports had come through Delve, and both were about stolen credentials. TechCrunch reported that LiteLLM’s March malware “stole the log-in credentials of everything it touched” while its site still showed Delve-sourced attestations (TechCrunch), and Context AI, whose app was the path into Vercel, confirmed “Context was previously a Delve customer” (TechCrunch). TechCrunch was careful, and so should we be: “Certifications don’t automatically prevent a company, like LiteLLM, from being hit by malware.” Real reports don’t either. Which brings us to ClickUp.

i went to clickup.com. opened the page source. found a hardcoded API key in the javascript. copied it. sent one GET request.

got back 959 email addresses and 3,165 internal feature flags.…

impulsive (@weezerOSINT) · April 27, 2026

A later post in the thread listed ClickUp’s badges (“SOC 2 Type 2 certified. ISO 27001. ISO 27017. ISO 27018. ISO 42001. PCI DSS.”) and said “none of it caught a hardcoded API key leaking 959 customer emails for 15 months.” (X). That’s a little unfair to SOC 2, which is an attestation and never promised to find a key in a JavaScript bundle. It’s completely fair to anyone who thinks a stack of badges answers the question “which keys are exposed, and who rotates them?”

The ending deserves as much attention as the start. Three days later the researcher posted that ClickUp paid out the maximum bounty on both findings, and that its chief executive and chief information security officer “reached out to me directly after the initial disclosure, took full ownership of the issues” (X). By the researcher’s account, the failure was a triage process that closed a report as a duplicate. The fix was leadership picking up the phone and owning it. That’s the culture you want.

So here’s my one-line version of the whole fight: attackers don’t read your SOC 2. They read your .env.

Right-sizing is a negotiation

Small vendors don’t get to set the terms, and I won’t pretend otherwise. Regulated buyers in Europe have their own supplier duties under NIS2 and DORA, and those arrive in your inbox as questionnaires and contract addenda whatever your size. The EU’s new Cyber Resilience Act spares micro and small enterprises from fines for one reporting deadline (“administrative fines do not apply to microenterprises or small enterprises”), but your customer’s lawyer won’t put that sentence in your contract (Regulation 2024/2847). Proportionality lives in the regulation, not in the addendum.

What you can do is bring a plan instead of a no:

• The attestation you have and the date of the next one. A Type 1 now and a Type 2 window that’s already started. Our guide to SOC 2 Type 1 versus Type 2 covers which buyers accept which.
• An MVSP self-assessment. It’s 25 controls, written by the kind of company that’s buying from you, and it has a self-assessment built in.
• A recent penetration test letter. We argued in Pentest Once a Year? that annual is the floor, not the proof, but it’s still the floor.
• Your credential inventory and the one-hour program below. One page that says which agents hold which keys, who owns each one and how fast you can rotate them. In my experience nothing in a security packet gets read more closely by a buyer’s engineer.
• The contract language you can actually meet. We wrote about the security exhibit your startup signed last quarter because founders keep promising things in exhibits their programs don’t do yet.

You’re not asking for less security. You’re asking to be measured on the security your product actually needs. When Drata’s co-founder Daniel Marashlian told us about the SOC 2 at his earlier startup, Portfolium, on episode 64, the cost he remembered wasn’t the auditor. It was “three engineers off to help go get a SOC 2 report is no joke. It’s a big decision.” Founders at Twin Cities Startup Week told us the same thing last month, and we wrote it up as “We Need SOC 2 Soon, But We’re Not Ready to Hire”. If that’s you, our SOC 2 Type 2 work starts with scoping it to your product, our free SOC 2 readiness checklist gets you a first look, and episode 37 is our founder’s guide to the whole alphabet.

Trust that sells, and the crowded feed we’re part of

This is the fight I’m least neutral about, because YSecurity is in it. Here’s the post that put the phrase in my feed:

Two AI startups pitched the exact same tool to a Fortune 500 enterprise. Competitor A was cheaper and faster. Competitor B won the contract in 3 weeks because of one asset: a pre-packaged trust architecture.

Jun H. · AI governance and cross-border data architect · October 9, 2026

Load the post from LinkedIn

Search LinkedIn for “SOC 2 in” plus “weeks” and you get the rest of the genre in one page: compliance founders, fractional security firms and audit firms, most of them promising speed. Delve’s homepage still read “Compliance in days” on October 10, after everything. Comp AI raised a $34 million Series A in September, saying “For a lot of software companies, security and compliance are directly tied to revenue” (TechCrunch). And more compliance homepages now promise to be the one that isn’t theater. Oneleet’s says “Real security. Zero theater.”

The fractional side is booming too. Cynomi, which sells virtual CISO software to managed service providers, reported in 2025 that 67% of managed service and managed security service providers offer virtual CISO services, “up from just 21% in 2024.” Providers ranked improved customer security as the top payoff, followed by upselling, margins and new customers (Help Net Security). That’s seller data about selling, so read it that way. The sharpest criticism comes from inside the category. Rob Black, who runs a firm called Fractional CISO, told IT Brew, “You can’t claim you’re a lawyer or a doctor unless you’ve passed a certain set of credentials. For a CISO, you can just say you’re a CISO” (IT Brew). James Rees of Razorwire was cheerfully honest about it:

Where we sit in this, honestly

YSecurity sells SOC 2 programs and on-demand security leaders, and Sasha and I also built Cyberbase, which answers security questionnaires. We’re in the feed, and you should weigh everything in this section with that in mind. On episode 99, Ged Ossman of Interf offered a formula I’ve thought about since: “trust is transparency divided by self-interest.” Our self-interest is obvious, so here’s the transparency.

The fight in the comments under one fractional security founder’s post captured both sides. Dave Anderson of TSC Security wrote, “Security is a revenue function. Not insurance. Not a cost center. Revenue.” Ronnie Fahy, a technology and security executive, answered: “Security is a cost centre, people will BS the opposite on LinkedIn constantly.” Then a chief information security officer, Jeremy Dupuis, added the buyer’s view: in one month he’d seen five long-established vendors with no third-party evaluation at all, “One of those vendors we will likely do business with because they provide something to us that we need but can not get with another vendor” (LinkedIn). Anderson’s own post had already conceded the point that matters: “The report gets you into the deal. The program behind it is what survives the diligence call.”

That’s where I land. Compliance does sell. A fast, honest answer to a security review shortens deals, and pretending otherwise is its own kind of LinkedIn performance. But what sells has changed. In March, after the Delve story, Samuel M. described “SOC 2 in days” bought to close a deal this way: “You were renting a signal” (LinkedIn). The most-engaged founder post I found on it, from Sachin S., ended with “Moving slow is a feature when your customers are defense contractors” (LinkedIn).

So judge any fractional leader, us included, by what they leave behind. Hire the fractional CISO who leaves you a credential inventory, a tested incident plan and a SOC 2 scope that matches your product, not a bigger pipeline for their next engagement. Our posts on what a vCISO actually does and costs and in-house, on-demand or YOLO lay out how to decide, and our in-house versus on-demand quiz takes ten questions.

What the buyer is actually buying

The best evidence for what closes deals comes from people who buy. Brian Lewis, speaking for himself about evaluating AI startups for an investment firm, gave the AI Engineer audience his list. For smaller companies, “we want to see at least one real security hire.” His red flags include read-write default scopes and “we’ll get you the security architecture diagram next week.” His green flags: “the best startups have security architecture that actually works, support engineers who respond, an admin API from the beginning, a 90-day plan that deploys into our infrastructure and cloud, and success criteria that we write.”

Yash Kosaraju said the same thing from Andreessen Horowitz’s side: “Some of the bigger clients would definitely ask for one, either a call with your security leader or a dedicated point of contact”. And on the vendor feed itself, he didn’t mince words.

Listen · Yash Kosaraju on episode 104, from 8:26

Eleanor Mount explained at BSides San Francisco why trust centers exist at all: “an entire industry now exists based on all of our failures to share information.” She also warned about the opposite failure, vendors who “share literally everything with you in attempts to be very transparent,” as in “getting like 27 policies.”

Specific is what sells

The legal history makes the same point. In the Securities and Exchange Commission’s case against SolarWinds, the claims that survived the judge’s July 2024 ruling were about the company’s public security statement, its specific promises, rather than its general puffery. The SEC dropped the case entirely in November 2025 (Harvard Law School Forum, SEC). The lesson I take: a trust page is marketing until it gets specific, and then it’s evidence. Date every claim, keep it true, and link it to something a buyer can check.

That’s why the .env program is the best sales asset nobody puts on a trust page. “We use a secrets manager” is a badge. “Every agent we run has its own scoped key, no secret lives in a file an agent can read, and we can rotate any credential in under an hour” is a sentence a buyer’s engineer believes, because they can ask you to prove it on a call. We built the security slide for your board deck around the same idea, and our sales support work is mostly helping founders turn true sentences into fast answers.

Both sides of the questionnaire now use AI. Vanta’s homepage features a customer that “Automated 93% of questionnaires,” and Conveyor claims its agent can “fill out over 90% of customer security questions fully, autonomously, and accurately” (TechCrunch). When a model answers a model’s questionnaire, the only human left is the one whose name is on the answer. Make sure that person read it.

Be kind to whoever leaked the key

Before the checklist, a word about the person who’s going to find something during it. It might be you.

Look at how two companies talked about one person’s part in a breach. In February 2021, SolarWinds’ former chief executive told Congress that a leaked password was “a mistake that an intern made” (CNN, via KTVZ). In January 2023, CircleCI wrote about an engineer’s compromised laptop: “While one employee’s laptop was exploited through this sophisticated attack, a security incident is a systems failure” (CircleCI). Google’s site reliability engineering book puts the principle in one sentence: “You can’t “fix” people, but you can fix systems and processes” (Google).

The best example this year came from an AI lab. On July 30, Anthropic disclosed incidents in an outside firm’s evaluation environment where its models reached real organizations’ systems, partly by “reading credentials from an exposed debug page.” Its framing: “consistent with a blameless postmortem culture,” “we’re approaching the fixes as if the responsibility were ours alone” (Anthropic). That’s the posture I want founders to copy. Agents are our software, and our prompts and our keys are our responsibility. Not the intern’s, not the model’s.

People panic when a key leaks, and they say so. A three-developer company in Mexico was billed $82,314.44 for Gemini usage in 48 hours, against a normal “$180 a month”: “I am in a state of shock and panic right now” (The Register). A developer in India watched ₹8,31,807.77 in charges pile up in about two hours and wrote, “In retrospect I should have grabbed request-level logs first, but I panicked” (Google AI Developers Forum). If the first thing your engineer feels after leaking a key is fear of you, the second thing they’ll do is wait. Waiting is what makes a leak expensive.

The platforms are getting kinder, and you should know what they’ll do for you. Anthropic says that when a key turns up in a public GitHub repository, “Anthropic automatically deactivates the exposed API key” (Anthropic). OpenAI says “the API key is disabled immediately” (OpenAI). Google’s new Gemini keys come with “fast-acting leaked key enforcement” (Google). AWS attaches a quarantine policy to exposed keys that now also blocks calls to its AI models (AWS).

Two caveats keep that from being the whole story. First, almost all of it covers public leaks. Your private repos, laptops, continuous integration logs, Slack threads and agent transcripts get none of it. Second, detection isn’t revocation. Verizon’s 2025 Data Breach Investigations Report found “the median time to remediate discovered leaked secrets on a GitHub repository is 94 days” (Verizon). GitGuardian, which sells detection, reports that “nearly 70% of credentials confirmed as valid in 2022 were still valid in January 2025,” and that on a retest a year later “the validity rate was still above 64%” (GitGuardian). Cloudflare, one of the best-run security teams anywhere, traced its Thanksgiving 2023 incident to the step everyone skips: “we failed to rotate one service token and three service accounts” after the Okta breach (Cloudflare).

And one more thing, said gently because the people involved are real: the leak is survivable, and hiding it isn’t. Uber’s 2016 breach started with a key in “a private GitHub repository,” according to the Federal Trade Commission (FTC). The legal case about how it was handled ended this year when the Supreme Court declined to hear the last appeal (docket), and the appeals court had already written the lesson: “The jury’s verdict in this case underscores the importance of transparency even in failure situations” (Ninth Circuit).

So the cultural half of your first security program is one sentence long: anyone can say “I leaked a key” in your team channel within five minutes, and the first reply is “thank you.” Then you rotate. GitHub’s own guidance puts it in the right order: “as a first step you need to revoke and/or rotate that secret,” and rewriting history afterward “may not be warranted” (GitHub).

The one-hour .env security program

Here’s the program. It’s built for a team of ten to fifty people with AI coding agents in daily use, and it assumes you run it on the repos that matter most: the product, and the infrastructure that deploys it. Do the steps in order, because rotation comes before cleanup. Every command and setting comes from the vendors’ current documentation.

Minutes	Step	How	What it proves
0 to 10	1. Find what has leaked, and which of it still works	gitleaks git -v scans history and gitleaks dir -v . scans the working tree, including an untracked .env. For a live check, trufflehog git file://. --results=verified,unknown tests which keys in your history still authenticate, and trufflehog filesystem . --results=verified,unknown does the same for files on disk.	Whether a working key sits in your history or on disk, separated from the noise.
10 to 20	2. Rotate the live keys first	GitHub says “as a first step you need to revoke and/or rotate that secret.” Stripe’s key rotation lets old and new keys both work “for up to 7 days.” On AWS, create the replacement, deactivate the old key, test, then delete it. On Supabase, create a new secret key, swap it in, then delete the old one.	A leaked key stops being a usable key.
20 to 25	3. Stop new leaks at the commit	Add the Gitleaks hook to .pre-commit-config.yaml, then run pre-commit autoupdate and pre-commit install. On GitHub, turn on push protection: it’s free on public repos, and private repos need GitHub Secret Protection, at $19 per active committer per month.	New secrets get blocked before they reach the remote.
25 to 35	4. Fence your coding agents	Claude Code: deny rules plus the sandbox, delivered through managed settings (snippet below). Cursor: add **/.env and **/.env.* to the global ignore list and use the sandboxed terminal, because Cursor says its terminal can’t enforce the ignore list. Gemini CLI: set advanced.ignoreLocalEnv and secret redaction to true. Codex: set ignore_default_excludes = false. Copilot: don’t count on content exclusion in agent mode.	Agents can’t casually read the file, and sandboxed commands can’t send it anywhere you didn’t allow.
35 to 45	5. Get plaintext secrets off disk	Pick one: op run --env-file=./app.env -- <command> with op:// references in a committed file, doppler run -- <command>, dotenvx encrypt then dotenvx run -- <command>, 1Password’s local .env mount, Bitwarden’s bws run, or SOPS with age.	A laptop backup, a screenshot or an agent’s cat no longer turns up raw keys.
45 to 55	6. Shrink what each remaining key can reach	OpenAI: switch keys from “All” to restricted permissions. Anthropic: one workspace per environment, with spend limits. Stripe: restricted keys, agent-tagged for agents. GitHub: fine-grained tokens with an expiry. AWS: aws sso login instead of long-lived access keys. Cloudflare: tokens with a time limit and IP filtering.	Least privilege and expiry exist in the dashboards, not just in a policy document.
55 to 60	7. Write it down	One row per key: owner, where it lives, which agents and plugins can reach it, scope, expiry and how to rotate it. Start from our credential inventory template.	You can answer the questionnaire honestly, and rotate fast next time.

Sources for the commands and quotes above: Gitleaks, TruffleHog, GitHub on removing sensitive data, Stripe API keys, GitHub Secret Protection pricing, 1Password CLI, Doppler CLI, dotenvx, Supabase API keys, AWS IAM Identity Center.

A few honest notes, because every tool on that list has an edge:

• Gitleaks’ author says the project is now “feature complete” and that new work goes into its successor, Betterleaks. Either one is fine for a first pass (Gitleaks).
• Secret managers move the key, they don’t make it disappear. A process you launch with op run still holds the values, and 1Password is candid that with its local .env mount “There’s no distinction made between different processes reading the file” (1Password). That’s still a big step up from a plaintext file every tool on the machine reads by default.
• Encrypting .env protects the commit, not the session. The dotenvx team says plainly that when you run Claude through it, “Claude receives the real values, but any values it prints are redacted” (dotenvx). On Hacker News, Thomas Ptacek’s worry about encrypted dotfiles was that the “de-revocation” of old keys “is hiding in your git history” (Hacker News). Rotate anyway.
• Many guardrails fail open. GitGuardian’s coding-agent hooks let the action through with a warning when they can’t scan (GitGuardian), and by default, when a Claude Code masking rule matches nothing, “sandboxed commands can read the real file unmasked” (Claude Code docs). Fail-open is a sensible default for developer experience. Just don’t present it in a security review as a control.

Step 4, paste-ready

This is our assembly of documented Claude Code settings, not a file Anthropic publishes. Put it in managed settings for the whole company, or in ~/.claude/settings.json to start, then run /status to confirm it loaded:

{
  "permissions": {
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true,
    "filesystem": { "denyRead": ["~/**/.env"] },
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ]
    }
  }
}

Expect a test or dev command that loads .env to break once reads are denied. That’s your cue for step 5: launch it through op run, doppler run or dotenvx run instead. To check that the network fence works, Anthropic’s docs suggest asking Claude to run curl --noproxy '*' https://example.com, which “Fails with Could not resolve host” when the sandbox is doing its job (Claude Code docs).

Two more things change. Claude Code won’t start where the sandbox can’t, so install bubblewrap and socat on Linux and run it inside WSL2 on Windows. And git over SSH from Claude’s shell stops working, so push from your own terminal, or move git’s network commands out of the sandbox with excludedCommands. In managed settings, also turn on allowManagedReadPathsOnly and allowManagedDomainsOnly, the locks that stop developers from widening the sandbox in their own settings files. One limit to know: the sandbox rule covers files named exactly .env, which is one more reason to finish step 5.

For Gemini CLI, the two settings go in ~/.gemini/settings.json:

{
  "advanced": { "ignoreLocalEnv": true },
  "security": { "environmentVariableRedaction": { "enabled": true } }
}

For Codex, in ~/.codex/config.toml:

[shell_environment_policy]
ignore_default_excludes = false

If you’d like to see your own file through this lens, the tool below sorts your keys by blast radius, writes the settings for the agents you use and gives you a starter inventory. It only needs the names.

Free tool · runs entirely in your browser

.env x-ray

Paste the variable names from your .env file and tick the coding agents your team runs. You get each key's blast radius, the first fix for the riskiest ones, settings for your agents and a starter credential inventory to download. If you paste values by accident, they're deleted the moment they land. Nothing you paste leaves this page.

Variable names One per line. cut -d= -f1 .env prints just the names.

Coding agents that open this repo

Claude Code Cursor OpenAI Codex Gemini CLI GitHub Copilot Google Antigravity Other agents or plugins

X-ray my keys Load an example Clear

How it works: each name is matched against patterns for common providers and secret types, like payment keys, database URLs, cloud keys and session secrets, then sorted by what it could do in the wrong hands. Names with a public prefix such as NEXT_PUBLIC_ or VITE_ are flagged when they look like secrets, because frameworks build those values into the JavaScript your visitors download. It's a first pass from names alone. A name can't tell us whether a key is restricted, expiring or already rotated, which is what the inventory columns are for.

Get help running the hour →

We'll reply with how we'd run the one-hour program with your team. We only receive your email, the counts above and which agents you ticked, never the names you pasted.

Hour two, week one, quarter one

The hour gets you from “we don’t know” to “we know, and the worst of it is fixed.” Here’s what comes next, in the order I’d do it.

Hour two

• Scan the whole GitHub organization, not just one repo: trufflehog github --org=<your-org> --results=verified. Add a gate to continuous integration so a verified secret fails the build.
• Check your MCP configuration files and agent settings for inline keys. The MCP specification says local servers “retrieve credentials from the environment,” which means every local server you add is one more process reading your secrets (MCP authorization). Our MCP drift post covers pinning and fingerprinting them.
• Audit your cloud agents. Copilot’s cloud agent hands its secrets to the agent as environment variables, and in Claude’s cloud environments, “Anyone who uses the environment can read the values” of plain environment variables.

Week one

• Turn on GitHub Secret Protection for private repos, or write down that you’re relying on pre-commit and CI scanning instead. A written decision is evidence. A forgotten one is a finding.
• Set an organization policy that caps token lifetimes. Fine-grained tokens already default to a 366-day cap, so lower it, and add a cap for classic tokens, which never have to expire unless an owner sets one.
• Push the Claude Code settings above through managed settings, and allowlist plugin marketplaces there too.
• Run a 30-minute tabletop: “a plugin we installed last month was malicious. What could it read?” The honest answer is your rotation list.
• Do the 30-minute credential inventory, and fix the five red flags it surfaces.

Quarter one

• Take long-lived keys out of the places agents run. The options, from simplest: a gateway with virtual keys and budgets in front of your model providers, Claude Code’s credential masking, or a broker that keeps user tokens server-side.
• Run agents in a container or virtual machine that holds only the secrets the task needs.
• Move continuous integration to short-lived, identity-based credentials, and automate rotation for the machine keys that remain. The UK’s National Cyber Security Centre says that for machine credentials, “the process of rotation should be automated with no human involvement” (NCSC), which is different advice from forcing people to change passwords on a calendar.
• Map the evidence into your SOC 2 or ISO 27001 controls. The table in the compliance section is a starting point your auditor can react to.

If you’d like a team to run this with you, it’s the first two weeks of our secure AI software development engagements, and the deeper version, scrubbing secrets out of datasets you train or fine-tune on, is our training data scrubbing program.

What to say when the buyer asks

Sooner or later a questionnaire will ask how your developers and AI agents handle secrets. Here’s an answer you can adapt once the hour is done. Every sentence in it should be true before you send it.

Production secrets live in [our secrets manager] and are injected at runtime; they are not stored in source code or in plaintext files on developer machines. Each AI agent and integration has its own credential, scoped to the systems it needs, with a named owner and an expiry date, recorded in our credential inventory. Coding agents run with managed settings that deny reads of credential files and restrict network access from their shells. Secret scanning runs before every commit and on every push, and a verified leaked secret is rotated before any history cleanup. We can rotate any production credential within [one hour], and we review the inventory quarterly with our access reviews.

The credential inventory post has a longer version for agent-specific questions. If your board wants the same story on one slide, that’s the security slide your board deck is missing.

Your first security program is a text file

Every startup I’ve worked with has a moment when security stops being a policy document and becomes a habit. It’s rarely the SOC 2 kickoff. It’s usually smaller: the first time someone rotates a key without being asked, or a new engineer asks where the secrets live and gets a good answer.

The .env file is where that habit starts, because it’s where every one of this fall’s arguments lands. Agents read it. Business actions hide behind it. It decides whether your agent acts as you or for you. It’s the line SOC 2 already has and nobody is required to read. And it’s the most specific thing you can show a buyer. One hour gets you most of the way. The rest is doing it again next quarter, a little faster.

If you want to hear how other founders and security leaders think about this, start with Dylan Ayrey of Truffle Security on episode 9, recorded years before secrets in agents were a headline, and Yash Kosaraju on episode 104 of The Security Podcast of Silicon Valley. If you’d rather argue in person, I’ll be at the AI LAX Summit at Google in Playa Vista, Los Angeles, on Friday, October 16, on the Track 03 panel on AI governance and safety, from 2:50 to 3:25 p.m. Pacific. Bring your .env questions, not your .env file. In April, YSecurity sponsors MicroConf US 2027 in Austin, where our talk, “How Founders Turn Security Commitments Into Revenue,” picks up the trust-that-sells thread. Everything else we’re doing is on our events page.

And if you’d like help with any of it, book a free 15-minute call. We’ll tell you whether you need us.