DEV Community: JasperNoBoxDev

Stop Putting API Keys in .env Files — Use Your OS Keychain Instead

JasperNoBoxDev — Thu, 26 Mar 2026 22:35:08 +0000

Last year, a developer at a YC startup pushed a .env file to a public GitHub repo. It contained their Stripe live key, an OpenAI API key, and a production database URL. Automated scanners picked it up in under 30 seconds. By the time GitHub's secret scanning revoked the tokens it recognized, someone had already racked up $14,000 in OpenAI API charges.

This is not rare. GitGuardian's 2024 State of Secrets Sprawl report found 12.8 million new secrets exposed in public GitHub repositories in a single year. A 28% increase from the year before. And those are just the public repos — private ones are worse, because nobody is scanning them.

12.8M
secrets exposed in public repos (2024)

28%
increase year over year

Your .env file is a liability. Here is why, and what to do about it.

The dotenv pattern was never a security mechanism

The dotenv pattern came out of the Ruby community in 2012. It solved a real problem: developers were hardcoding database passwords and API keys directly into source files. Moving them to a separate file that you .gitignore was a genuine improvement.

But here is what a typical .env looks like on a developer's machine right now:

OPENAI_API_KEY=sk-proj-abc123...
STRIPE_SECRET_KEY=sk_live_...
DATABASE_URL=postgresql://admin:password@prod-db.example.com:5432/main
CLOUDFLARE_API_TOKEN=v4x...
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI...

Five production credentials. Plaintext. No authentication to read them. No encryption at rest. No audit trail. Any process running as your user — a rogue npm postinstall script, a compromised VS Code extension, a careless docker build — can read that file without you knowing.

That is not security. That is a Post-it note on your monitor with the vault combination.

Why .env file security breaks down at scale

A single .env file is manageable. Nobody has a single .env file.

We counted ours. 47. Some in active projects, some in archived repos, some in Docker contexts that got copied into images. The same Cloudflare API token appeared in six different files. When we rotated it, we updated three and missed the other three for weeks. (Full story of that audit here.)

There is no expiry tracking. No way to know which secrets are still valid. No audit trail of which process read which key. When a breach happens, incident response starts with "wait, where do we even have this key?" and ends with grep -r across the entire home directory.

Warning
GitHub's push protection auto-revokes tokens from GitHub, AWS, Google Cloud, and a handful of other providers. But most services lack that integration. Your Stripe key, your Postmark token, your custom API credentials — if those hit a public repo, nobody revokes them automatically. You find out when the bill arrives or the data is gone.

AI agents turned .env files into a critical vulnerability

The .env pattern assumed that only your application would read the file. That assumption broke in 2025.

AI coding agents — Claude Code, Cursor, GitHub Copilot, Codex — routinely read project files to build context. Your .env is a project file. When an agent reads it, every secret in that file enters the model's context window. From there, values can appear in generated code, debug output, error messages, or conversation logs.

The agent is not being malicious. It is trying to help. "Here is the error — your DATABASE_URL returns connection refused" — and now your production database hostname and credentials are in the chat history. Shared with your team. Logged by the provider. Potentially used as training data.

We wrote more about specific leak vectors in 6 Ways AI Agents Leak Your Secrets. The short version: if a secret is in a file that an agent can read, assume it will be read.

The env file alternative: macOS Keychain with Touch ID

The macOS Keychain is an encrypted credential store that has been on every Mac for over 20 years. It is backed by the Secure Enclave, protected by Touch ID, and used by Safari, SSH, and every Apple-signed application. Not a startup's custom vault — infrastructure that Apple maintains and audits.

NoxKey is a thin layer on top of the Keychain, purpose-built for developer secrets:

Before: plaintext .env

# Plaintext file anyone can read
$ cat .env
STRIPE_SECRET_KEY=sk_live_51Hx...

After: Keychain + Touch ID

# Encrypted in Keychain, Touch ID on every access
$ noxkey set myorg/project/STRIPE_KEY --clipboard
✓ Stored myorg/project/STRIPE_KEY

$ eval "$(noxkey get myorg/project/STRIPE_KEY)"
# → Touch ID prompt → secret loaded into shell
# → raw value never written to disk

$ echo $STRIPE_KEY
sk_live_51Hx...

One secret, one location, accessible from any project directory. No files on disk. Touch ID every time. When an AI agent calls noxkey get, it detects the agent's process tree and returns an encrypted handoff instead of the raw value — the secret reaches the environment but never enters the conversation context.

Agent calls noxkey get → Process tree detected → AES-256-CBC encryption → Secret in env, never in context

Migrate from .env to Keychain in minutes

# Import your existing .env file
$ noxkey import myorg/project .env
✓ Imported 5 secrets

# Verify everything landed
$ noxkey ls myorg/project/
myorg/project/STRIPE_SECRET_KEY
myorg/project/OPENAI_API_KEY
myorg/project/DATABASE_URL
myorg/project/CLOUDFLARE_API_TOKEN
myorg/project/AWS_SECRET_ACCESS_KEY

# Peek at a value to confirm (shows first 8 chars)
$ noxkey peek myorg/project/STRIPE_SECRET_KEY
sk_live_...

# Now delete the liability
$ rm .env

Do that for every project. We did 47 in one afternoon. The find command that started it:

$ find ~/dev -name ".env" -not -path "*/node_modules/*" -not -path "*/.git/*" | wc -l
47

What about CI/CD?

This approach is for local development — your machine, your secrets, your Touch ID. CI/CD systems have their own secrets management: GitHub Actions secrets, Cloudflare environment variables, AWS Parameter Store, Vault. Those are purpose-built for that environment and they work.

The problem is the gap between "secrets managed in CI" and "secrets on your laptop." That gap is currently filled by plaintext files with no authentication, no encryption, and no access control. It should be filled by your operating system's credential store.

The honest tradeoffs of leaving dotenv behind

This is macOS only. If your team is on Linux or Windows, NoxKey is not the answer for them (though the principle holds — use your OS credential store, not plaintext files).

There is friction. Touch ID on every access means authenticating more than before. Session unlock (noxkey unlock myorg/project) reduces this to one authentication per batch, but it is still more than the zero authentication that .env offers. That friction is the point — it means something is actually guarding access.

You will need to update your workflow. Instead of copying .env.example and filling in values, you run noxkey import once and use eval commands. It took us about a day to stop reaching for .env instinctively.

Your API keys deserve better than plaintext files

12.8 million secrets exposed in public repos last year. AI agents reading every file in your project directory. Supply chain attacks targeting plaintext credentials. The .env pattern was a good idea in 2012. It is a liability in 2026.

Your operating system has an encrypted, hardware-backed credential store with biometric authentication. Use it.

Key Takeaway
Your .env file has no encryption, no authentication, and no access control. Every AI agent, every rogue script, and every accidental git push can read it. Move your secrets to the macOS Keychain — one location, Touch ID on every access, and AI agents never see the raw values. The migration takes minutes per project.

brew install no-box-dev/noxkey/noxkey

Free. No account. No cloud. Your secrets stay on your machine.

Frequently asked questions

*Why are .env files insecure?*
.env files store secrets as plaintext on disk with no encryption, no authentication, and no access control. Any process, script, or AI agent with file system access can read them. They frequently get committed to git — 12.8 million secrets were exposed on GitHub in 2024.

*What should I use instead of dotenv?*
Use your operating system's credential store. On macOS, the Keychain provides hardware-encrypted storage with Touch ID authentication. NoxKey wraps the Keychain in a developer-friendly CLI: eval "$(noxkey get myorg/KEY)" replaces process.env.KEY.

*Can AI agents read .env files?*
Yes. AI coding tools like Claude Code, Cursor, and Copilot have file system access and can read any .env file in your project directory. NoxKey prevents this by storing secrets in the Keychain and delivering them through encrypted handoff when an AI agent is detected.

*How do I migrate from .env to the macOS Keychain?*
Install NoxKey (brew install no-box-dev/noxkey/noxkey), then run noxkey import myorg .env to move all secrets to the Keychain. Delete the .env file afterward. The migration takes about a minute per project.

NoxKey is free and open source. brew install no-box-dev/noxkey/noxkey — GitHub | Website

How We Built Process-Tree Agent Detection

JasperNoBoxDev — Thu, 26 Mar 2026 22:35:01 +0000

How do you tell if a human or an AI agent is requesting a secret?

This question sits at the center of NoxKey's security model. An AI agent needs your Stripe key to make API calls. A human needs it to paste somewhere. Both call noxkey get. But the response should be fundamentally different — because what happens after delivery depends entirely on who's asking.

A human uses the value and moves on. An agent ingests it into a conversation context where it can be logged, echoed in debug output, included in generated code, or stored in a chat history on someone else's server. Same secret, wildly different risk profiles.

We spent two weeks building the process tree detection system that powers NoxKey's agent access control. Here's exactly how it works, where it breaks, and why imperfect detection still beats no detection at all.

CLI
noxkey get
Detection -->

Agent Detection
Process Tree Walker
Dual Verification
Menu Bar -->

Unix Socket

Menu Bar App
Server + Touch ID
Keychain -->

Keychain
Encrypted

Every process has a family tree

Every process on macOS has a parent. Your shell was started by Terminal.app. Terminal.app was started by launchd. When you type a command, your shell forks a child process to run it. This chain — child to parent to grandparent — is the process tree.

When Claude Code runs a command, the chain looks like this:

launchd PID 1 └─ claude ← Electron app (MATCH) └─ node ← Claude Code runtime └─ zsh ← spawned shell └─ noxkey ← get org/proj/STRIPE_KEY

When a human runs the same command from Terminal:

launchd PID 1 └─ Terminal.app └─ zsh ← login shell └─ noxkey ← get org/proj/STRIPE_KEY

The difference: one tree has a process named claude. The other doesn't. That's the signal.

Walking the process tree in Swift

NoxKey's server is a native Swift menu bar app. The process tree walker uses macOS kernel APIs — specifically proc_pidinfo and sysctl with KERN_PROC — to climb from any PID to launchd.

The algorithm: start at the requesting process, get its parent PID, check the binary name, move up, repeat. Stop at PID 1 or on match.

func isAgentProcess(pid: pid_t) -> Bool {
    var currentPid = pid
    var depth = 0
    let maxDepth = 20  // safety limit

    while currentPid > 1 && depth average detection time


    1.6ms
    worst case


    20
    ancestors max depth


## The agent signatures list

Detection checks each ancestor's binary name against known AI coding tool signatures:

private let agentSignatures = [
"claude", "cursor", "codex",
"windsurf", "copilot", "cody",
"aider", "continue", "tabby"
]




Case-insensitive substring matching. If any ancestor's binary name contains any of these strings, the caller is classified as an agent.

Could an agent rename its binary to bypass detection? In theory, yes. In practice, agent binaries are code-signed, distributed through Homebrew or app stores, and installed to standard paths. Users don't rename them. And if an agent vendor deliberately tried to evade detection, the headline writes itself: "Cursor caught disguising itself to bypass credential controls."

Name-based detection works because the incentives align. Agent vendors *want* to be identified. Being detected means getting the encrypted handoff instead of being blocked entirely. The alternative — no detection, no access — is worse for everyone.

## Dual verification: never trust the client

The CLI performs process-tree detection client-side. But the CLI is a binary on the user's machine. A malicious script could bypass it entirely and talk to the Unix socket directly, claiming to be human.

So the server verifies independently.

How dual verification works
  When the CLI connects to NoxKey's Unix domain socket, the server resolves the peer's PID using the `LOCAL_PEERPID` socket option — a kernel-level credential, not something the client sends. The server then walks *that* process tree independently.

Both sides must agree. If the CLI says "human" but the server sees `claude` in the ancestry, the server's verdict wins. The more restrictive interpretation always takes precedence. A compromised CLI can't downgrade its own classification.

Same principle as server-side validation in web apps. The client can lie. The server checks anyway.

## The encrypted handoff

When detection confirms an agent caller, NoxKey doesn't refuse the secret. It changes *how* the secret is delivered. This is the critical design decision: agents need secrets to function. Blocking them entirely just pushes developers back to `.env` files. Instead, we make the secret available to the agent's process without exposing the raw value in its text context.

The handoff sequence:

1. Generate Key ← random AES-256-CBC key + IV &nbsp;&nbsp; └─ 2. Encrypt ← secret value encrypted with one-time key &nbsp;&nbsp;&nbsp;&nbsp; └─ 3. Transmit ← payload + key + IV over Unix socket &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; └─ 4. Decrypt ← CLI decrypts via CommonCrypto &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; └─ 5. Write Script ← self-deleting temp script to /tmp (0600) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; └─ 6. Output ← source '/tmp/noxkey_abc123.sh' to stdout &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; └─ 7. Cleanup ← file removed after 60s safety net

  - The server generates a random AES-256-CBC key and initialization vector
  - The secret value is encrypted with this one-time key
  - The encrypted payload, key, and IV return to the CLI over the Unix socket
  - The CLI decrypts using CommonCrypto (Apple's native crypto framework)
  - The CLI writes a self-deleting temp script to `/tmp` — containing `export KEY=value` followed by `rm -f "$0"`
  - The CLI outputs `source '/tmp/noxkey_abc123.sh'` to stdout
  - A background cleanup process removes the file after 60 seconds regardless

The agent runs `eval "$(noxkey get org/proj/STRIPE_KEY)"`. The eval sources the temp script, which exports the secret into the shell environment and deletes itself. The secret is now in `$STRIPE_KEY` — available to subprocesses — but the raw value never appeared in the agent's conversation context. It flowed through the OS, not through the chat.

The temp file exists on disk for milliseconds. Created with `0600` permissions (owner-only). The 60-second cleanup is a safety net for cases where the script isn't sourced.

## Defending against PID recycling attacks

PID Recycling Attack
  A legitimate process authenticates with Touch ID and gets a session. When it exits, macOS can recycle its PID. A new process inheriting that PID could hijack the authenticated session — accessing secrets without ever touching the fingerprint sensor. On a busy system with a 99999 PID space, recycling can happen within seconds.

NoxKey has session unlock: run `noxkey unlock org/proj`, authenticate with Touch ID once, and subsequent `get` calls under that prefix skip biometric auth for a configurable window. The session is bound to the PID that initiated it.

The attack scenario:

  - A legitimate process (PID 48201) calls `noxkey unlock org/proj` and authenticates with Touch ID
  - The session manager records: "PID 48201 has an active session for `org/proj/*`"
  - The legitimate process exits. PID 48201 is now free
  - An attacker spawns a new process. macOS assigns it PID 48201 — recycled
  - The attacker calls `noxkey get org/proj/DATABASE_URL` from PID 48201
  - The session manager sees the PID, finds an active session, skips Touch ID
  - The attacker gets the secret without ever authenticating

The fix: sessions are bound to PID *and* process start time. When a process calls `unlock`, the session manager records the PID and the boot-relative start timestamp from `kp_proc.p_starttime` (via `sysctl` with `KERN_PROC`). Every subsequent request checks both. A recycled PID has a different start time — microsecond precision makes collisions effectively impossible. The session check rejects it, and Touch ID is required again.

## Command-level blocking for AI agents

Process tree detection enables granular access control. When the caller is an agent, certain commands are blocked:

  - `--raw` — no plaintext stdout. Agents can't pipe raw values
  - `--copy` — no clipboard access for agents
  - `load`, `export`, `bundle`, `env` — no bulk secret operations

And certain commands remain available:

  - `ls` — agents can discover key names (no values shown)
  - `peek` — agents can see 8-character prefixes for verification
  - `get` — returns encrypted handoff, not raw values
  - `set --clipboard` — agents can store secrets from your clipboard

The CLI exits with a clear error: "This command is not available to AI agents." No ambiguity. The agent knows exactly why it was blocked and can tell the user.

## Honest limitations of process tree detection

This approach isn't perfect. We want to be upfront about where it breaks.

**Name-based matching has blind spots.** A new agent not in the signatures list won't be detected. We update the list with each release, but there's always a window. Obscure agents get treated as human callers.

**Detection is point-in-time.** It happens when the secret is requested. If an agent already has a secret in its environment from a previous session — before NoxKey was installed, or from a `.env` file it read earlier — detection can't revoke that access.

**This is macOS only.** The implementation uses `proc_pidinfo`, `sysctl`, and `LOCAL_PEERPID` — all macOS-specific APIs. The concept is portable to Linux (via `/proc`) and Windows (via `NtQueryInformationProcess`), but this code isn't.

**Sophisticated evasion is possible.** An attacker with root access could manipulate process names or inject into a legitimate process. But root access means your [Keychain secrets](https://noboxdev.com/blog/macos-keychain-for-developers) are already compromised regardless.

Despite these limitations — no other secrets manager distinguishes between human and agent callers at all. Every `.env` file, every `1password read` call, every `vault kv get` treats all callers identically. Imperfect detection that catches 95% of real-world agent access patterns is categorically better than zero detection. The [most common ways developers leak credentials](https://noboxdev.com/blog/credential-hygiene-for-developers) are all mitigated by this approach, even with its limitations.

We're not building an unbreakable wall. We're making the default safe.

When a developer installs NoxKey and an AI agent requests a secret, the right thing happens automatically — no configuration, no flags, no awareness required. That's the bar. Process-tree detection clears it.

Key Takeaway
  Process-tree agent detection uses macOS kernel APIs to walk from the requesting process to its ancestors, checking binary names against known AI coding tool signatures. Combined with dual verification (client + server via LOCAL_PEERPID), encrypted handoff delivery, and PID+start-time session binding, it catches 95% of real-world agent access patterns — without requiring any configuration from the developer.

---
*NoxKey is free and open source. `brew install no-box-dev/noxkey/noxkey` — [GitHub](https://github.com/No-Box-Dev/Noxkey) | [Website](https://noxkey.ai)*

NoxKey — A macOS Secrets Manager With Touch ID and AI Agent Detection

JasperNoBoxDev — Thu, 26 Mar 2026 22:34:59 +0000

We were debugging a Stripe integration at 1am when Claude printed a live API key in its debug output. Full key. Right there in the conversation log.

The agent was not malicious. The system was broken. The secret sat in a .env file. The agent read the file and included the value in its response. That is what agents do — they read project files and use what they find. The .env file was the vulnerability, not the agent.

That night we started building NoxKey.

A macOS secrets manager built for developers

NoxKey is a macOS menu bar app and CLI that stores secrets in the macOS Keychain, protected by Touch ID. No cloud. No accounts. No subscription. Your secrets live in Apple's encrypted storage on your machine and nowhere else.

When an AI agent requests a secret, NoxKey detects it automatically and delivers the value through an encrypted handoff — the secret reaches the agent's process environment without ever appearing in its conversation context.

Keychain storage. Touch ID authentication. Encrypted handoff for AI agents.

0
cloud connections

30s
to install


0
config needed

Architecture: menu bar app + CLI over a Unix socket

NoxKey has two pieces:

Menu Bar App
SwiftUI · Native macOS

Touch ID

Agent Detection

Keychain Access

Session Manager

Unix
Socket

CLI
Swift · /usr/local/bin/noxkey

get / set / ls

import / unlock

peek / strict

Encrypted Handoff

macOS Keychain

The menu bar app is a native SwiftUI application. It manages the Keychain, handles Touch ID prompts, performs process-tree agent detection, and serves requests over a Unix domain socket. This is the server. It has Keychain entitlements, biometric access, and full control over what gets returned to whom.

The CLI (noxkey) talks to the menu bar app over that Unix socket. It does not touch the Keychain directly — every request goes through the server, which validates the caller independently.

Why a Unix socket instead of XPC or HTTP? Unix sockets provide LOCAL_PEERPID — the kernel tells the server exactly which process connected. No authentication tokens to manage. No port conflicts. No network exposure. The socket file lives at a user-specific path, accessible only to your user account.

Install this macOS secrets manager in 30 seconds

$ brew install no-box-dev/noxkey/noxkey

==> Downloading noxkey-0.6.43.tar.gz
==> Installing noxkey
==> Caveats
NoxKey menu bar app installed to /Applications.
CLI installed to /usr/local/bin/noxkey.
==> Summary
  /Applications/NoxKey.app
  /usr/local/bin/noxkey

Launch NoxKey.app from your Applications folder. It appears in the menu bar — a small key icon. That is the server running. The CLI works immediately.

$ noxkey --version
noxkey 0.6.43

No account creation. No master password. No onboarding wizard. It uses your existing macOS login Keychain and your existing fingerprint.

Replace your .env files with Keychain storage

If you have dozens of .env files scattered across your machine, the first step is importing them.

$ noxkey import myorg/api .env
[Touch ID prompt]
Imported 6 secrets:
  myorg/api/STRIPE_KEY
  myorg/api/DATABASE_URL
  myorg/api/REDIS_URL
  myorg/api/CLOUDFLARE_TOKEN
  myorg/api/SENDGRID_KEY
  myorg/api/JWT_SECRET

$ noxkey ls myorg/api/
  myorg/api/CLOUDFLARE_TOKEN
  myorg/api/DATABASE_URL
  myorg/api/JWT_SECRET
  myorg/api/REDIS_URL
  myorg/api/SENDGRID_KEY
  myorg/api/STRIPE_KEY

$ rm .env

Secrets are organized as org/project/KEY. One secret, one location, accessible from any terminal in any project directory. No more duplicating the same Cloudflare token across six repos.

Daily usage: Touch ID for every API key access

The core pattern is one line:

$ eval "$(noxkey get myorg/api/STRIPE_KEY)"
[Touch ID prompt]
$ echo $STRIPE_KEY
sk_live_...  # available in your shell environment

Touch ID fires. The secret loads into your shell environment. Your script or application reads it from $STRIPE_KEY like any environment variable.

Session unlock eliminates friction
For batch operations — say you need five secrets to run your dev server — run noxkey unlock myorg/api once with Touch ID. All subsequent get calls under that prefix skip biometric auth for a configurable window. The session is bound to your PID and process start time, so PID recycling cannot hijack it.

Need multiple secrets at once? Session unlock handles that:

$ noxkey unlock myorg/api
[Touch ID prompt — once]
Session unlocked for myorg/api/* (expires in 15 minutes)

$ eval "$(noxkey get myorg/api/STRIPE_KEY)"    # no Touch ID
$ eval "$(noxkey get myorg/api/DATABASE_URL)"   # no Touch ID
$ eval "$(noxkey get myorg/api/REDIS_URL)"      # no Touch ID

One fingerprint, then flow. The session is bound to your process ID and its start time — PID recycling cannot hijack it.

For your most sensitive secrets, strict mode overrides sessions:

$ noxkey strict myorg/api/STRIPE_KEY
# This key ALWAYS requires Touch ID, even during an active session

How AI agent detection works

When Claude Code runs noxkey get, you do not configure anything. Detection is automatic.

noxkey PID 61023 — get myorg/api/STRIPE_KEY └─ zsh PID 61020 — spawned shell └─ node PID 58401 — Claude Code runtime └─ claude PID 58399 — MATCH! Agent detected Encrypted Handoff ← AES-256-CBC → temp script → source → self-delete Result: $STRIPE_KEY in shell env. Raw value never in conversation context.

The agent can make API calls, run your test suite, and deploy your app. It just cannot see, log, or echo the raw secret value. If it tries to use --raw or --copy, the CLI blocks it.

The six most common agent leak patterns — reading .env files, echoing secrets in debug output, storing values in conversation logs, hardcoding them in generated code, passing them to spawned processes — are all mitigated by this approach.

Security, DX, and agent safety features

Security

&#x1F91A;
Touch ID on every access

Not a password, not a PIN. Your fingerprint. Every time.

&#x1F512;
macOS Keychain storage

Apple's Data Protection Keychain, backed by the Secure Enclave. Not a custom vault.

&#x1F6AB;
Zero network connections

NoxKey never phones home. No telemetry, no sync. Your secrets never leave your machine.

&#x1F6E1;
Strict mode

High-value secrets always require Touch ID, even during unlocked sessions.

&#x1F6A8;
DLP guard

Scans agent output for leaked secret values using 8-character fingerprints. Blocks leaks before they enter AI context.

Developer experience

&#x26A1;
One command

eval "$(noxkey get org/proj/KEY)"

&#x1F513;
Session unlock

One Touch ID, then batch operations flow without interruption.

&#x1F4E5;
.env import

noxkey import org/proj .env — migrate in one step.

&#x1F440;
Peek

noxkey peek org/proj/KEY — first 8 characters for verification, without exposing the full value.

&#x1F4C1;
Org/project hierarchy

Secrets are namespaced, searchable, and never duplicated across projects.

&#x1F5A5;
Menu bar UI

Browse, add, edit, and organize secrets without touching the terminal.

AI agent security

&#x1F916;
Automatic agent detection

Process-tree walking identifies Claude, Cursor, Codex, Windsurf, Copilot, and others.

&#x1F510;
Encrypted handoff

Agents get secrets in their process environment, never in conversation context.

&#x1F6D1;
Command blocking

--raw, --copy, load, export, bundle, env are all blocked for agent callers.

&#x1F50D;
DLP scanning

Catches leaked values in agent output before they persist.

What NoxKey does not do

Deliberate scope
NoxKey is for individual developers on macOS who need to keep API keys and tokens out of .env files and AI agent contexts. It is not a team vault, not cross-platform, not a password manager, and has no cloud sync.

Not a team tool. NoxKey is for individual developers. No shared vault, no role-based access, no audit log. For team secret management, look at Doppler or HashiCorp Vault.

Not cross-platform. macOS only. The security model depends on the macOS Keychain, Touch ID, and the Secure Enclave. These do not exist on Linux or Windows. The concepts are portable — this implementation is not.

Not a password manager. NoxKey manages developer credentials — API keys, tokens, database URLs, webhook secrets. It does not autofill browser forms or sync across devices. Use 1Password or Bitwarden for that.

No cloud sync. Your secrets exist on one machine. If your laptop dies, you re-import. This is a feature — no server to breach, no sync protocol to exploit, no third party with your data. Backups are your responsibility.

Why we built a dotenv alternative for macOS

We were using .env files like everyone else. We had a .gitignore entry. We thought we were fine.

Then AI coding assistants became part of the daily workflow. Every project file became fair game for an agent to read, reference, and include in responses. The .env file went from "slightly risky convenience" to "active liability." The dotenv pattern was designed in 2012, before AI agents existed. It assumes the only thing reading your project files is your code.

We looked at existing options. 1Password CLI is solid but requires a subscription and has no agent detection. HashiCorp Vault targets infrastructure teams, not solo developers. Doppler is cloud-hosted. None of them distinguish between a human caller and an AI agent.

The macOS Keychain was sitting right there. Encrypted. Biometric. Local. Already on every Mac. All it needed was a developer-friendly interface and awareness of AI agents.

Get started

brew install no-box-dev/noxkey/noxkey

Free. No account. No cloud. Your Keychain and your fingerprint.

Key Takeaway
NoxKey stores your secrets in the macOS Keychain with Touch ID protection and zero cloud connections. When an AI agent requests a secret, process-tree detection delivers the value through an encrypted handoff — the secret reaches the agent's shell environment without appearing in its conversation context. Install with brew install no-box-dev/noxkey/noxkey and your .env files become obsolete.

noxkey.ai

Frequently asked questions

*What is NoxKey?*
NoxKey is a free, open-source macOS menu bar app that stores developer secrets (API keys, tokens, passwords) in the macOS Keychain with Touch ID. It replaces .env files with hardware-encrypted storage and adds AI agent detection with encrypted handoff.

*How does NoxKey detect AI agents?*
NoxKey walks the macOS process tree when a secret is requested. If it detects an AI agent (Claude Code, Cursor, Copilot) in the calling chain, it switches to encrypted handoff — the secret reaches the agent's shell environment through a self-deleting encrypted script, never entering the conversation context.

*Is NoxKey free?*
Yes. NoxKey is MIT-licensed, open source, and completely free. No account, no subscription, no cloud. Install with brew install no-box-dev/noxkey/noxkey.

*How do I migrate from .env files?*
One command: noxkey import myorg .env. This imports all key-value pairs into the macOS Keychain. Then delete the .env file. Access secrets with eval "$(noxkey get myorg/KEY)".

*Does NoxKey send data to the cloud?*
No. NoxKey makes zero outbound network connections. All secrets are stored locally in the macOS Keychain, which uses Apple's Secure Enclave for hardware encryption. This is verifiable via macOS network monitoring.

*What's the difference between NoxKey and 1Password CLI?*
NoxKey is local-only (no cloud, no account), free, and includes AI agent detection with encrypted handoff. 1Password CLI requires a cloud subscription and has no AI-specific security features. Full comparison.

NoxKey is free and open source. brew install no-box-dev/noxkey/noxkey — GitHub | Website

6 Ways AI Agents Leak Your API Keys and Secrets

JasperNoBoxDev — Sun, 22 Mar 2026 16:12:45 +0000

We watched Claude Code include a Stripe secret key in a debug log. It was trying to help — we had asked it to figure out why a payment integration was failing, and it printed the full HTTP request, headers and all. Authorization: Bearer sk_live_..., right there in the conversation context. Stored on Anthropic's servers, in the conversation history, visible in the terminal scrollback.

That is when we built the DLP guard.

AI coding assistants are the most productive tools we have ever used. They are also the biggest credentials risk most developers are not thinking about. Here are six ways your secrets leak through AI agents — with reproduction steps, severity ratings, and fixes for each one.

6
leak vectors identified

30s
to install the DLP guard


0
false positives in production

Leak #1 — Reading your .env file

1. AI agents read your .env file Critical

Every AI coding assistant with file access can read your .env file. It is a plaintext file in your project directory. The agent reads project files to understand context. There is no access control, no authentication, no prompt asking "should this tool see your Stripe key?"

How to reproduce it

Create a .env file with a test secret. Open any AI coding assistant. Ask it to "explain the project structure" or "help me debug the API integration." Watch the agent's tool calls — it will read the .env file as part of understanding your codebase.

# Create a test .env
echo 'TEST_SECRET=this-value-should-not-appear-in-chat' > .env

# In Claude Code:
> "What API services does this project use?"
# Agent reads .env → TEST_SECRET value is now in context

# In Cursor (0.45+):
# Open the project → Cmd+L → "Summarize the project config"
# Cursor indexes .env as part of the workspace

# In GitHub Copilot:
# Open .env in a tab → Copilot Chat has access to open file contents

The agent is not being malicious. It is doing what you asked: understand the codebase. Your .env is part of the codebase.

The fix: Do not have a .env file. Store secrets in the macOS Keychain instead. Load them at runtime with eval "$(noxkey get org/project/KEY)". There is no file for the agent to read.

Leak #2 — Debug output exposure

2. Secrets in debug output Critical

"The API call is failing, can you debug this?" The agent helpfully prints the full request to show you what is happening:

# You ask Claude Code:
> "The Stripe charge endpoint is returning 401, can you debug?"

# Agent output:
Here's the failing request:

  curl -X POST https://api.stripe.com/v1/charges \
    -H "Authorization: Bearer sk_live_51ABC...xYz" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -d "amount=2000&currency=usd"

The issue is that your API key has been rotated. The key
starting with sk_live_51ABC is no longer valid...

That key is now in your conversation history. On the AI provider's servers. In your terminal scrollback. If you are sharing your screen or recording a demo, it is in the recording too.

The agent saw the value in process.env.STRIPE_SECRET_KEY (referenced in your code) and included it because showing the full request seemed helpful for debugging. Right call for debugging. Wrong call for security.

The fix: A DLP guard that scans agent output before it enters the conversation. NoxKey's guard matches against 8-character fingerprints of your stored secrets:

# Set up the DLP guard (one-time)
noxkey guard install

# What it catches:
# Agent output: "Authorization: Bearer sk_live_51ABC..."
# Guard: "BLOCKED — output contains value matching myorg/project/STRIPE_KEY (peek: sk_live_5)"
# The output never enters the conversation context.

3. Credentials stored in conversation logs High

"Here is my config, help me fix this deployment." You paste your .env into ChatGPT. Here is where that data goes:

Transmitted over HTTPS to the API endpoint
Stored in the conversation database
Logged for abuse detection and safety monitoring
Potentially queued for human review if it triggers filters
Retained per the data retention policy (which can change)
Backed up across the provider's infrastructure

Six copies minimum, on infrastructure you do not control, with retention policies you did not agree to read. Even if you delete the conversation in the UI, the data was transmitted and stored. Deletion from the frontend does not guarantee deletion from logs, backups, or training pipelines.

How to reproduce it

# In ChatGPT, Claude, or any AI chat:
> "Here's my .env file, can you help me debug?"
> DATABASE_URL=postgresql://admin:s3cretP@ss@db.example.com/prod
> STRIPE_KEY=sk_live_...

# That data is now stored on the provider's servers.
# You cannot un-send it. You cannot verify deletion.
# If you used a wrapper app or browser extension, add another copy.

The fix: Never paste credentials into any chat interface. If the agent needs access to a secret, it should flow through the OS — Keychain to encrypted handoff to process environment — not through the conversation.

4. API keys hardcoded in generated code High

You ask the agent to "set up the Stripe integration." It generates a config file. Because it saw your API key in the environment (or in a file it read earlier), it hardcodes the value:

# You ask Cursor:
> "Set up Stripe with the charge endpoint"

# Cursor generates config/stripe.ts:
export const stripeConfig = {
  secretKey: "sk_live_51ABC...xYz",  // High

AI agents that can execute code spawn subprocesses. Environment variables are inherited by child processes by default:

Your shell STRIPE_KEY=sk_live_...
  inherits
  claudeinherits STRIPE_KEY
  inherits
  nodeinherits STRIPE_KEY
  inherits
  bash -c "curl ..."inherits STRIPE_KEY
  inherits
  curlhas full access to STRIPE_KEY

Every process in that tree has your Stripe key. The agent did not steal it — it inherited it, the same way every child process inherits environment variables on Unix. When the agent spawns a `curl` command to test your API, that process can access `$STRIPE_KEY`.

### How to reproduce it

Set a secret in your shell

export TEST_SECRET="this-is-sensitive"

In Claude Code:

"Run: echo $TEST_SECRET"

Output: this-is-sensitive

The agent accessed an inherited environment variable

and printed it to the conversation context.


Most agents do not actively exfiltrate credentials this way. But the capability is there. An agent with code execution and inherited environment variables has everything it needs to make authenticated API calls on your behalf.

**The fix:** [Process-tree detection](https://noboxdev.com/blog/process-tree-agent-detection) identifies when an AI agent — not a human — is requesting secrets. When an agent is detected, secrets are delivered via encrypted handoff instead of raw values. Bulk export commands are blocked. The agent gets scoped access instead of full environment inheritance.

Leak #6 — The vector nobody is talking about

## 6. Credentials exposed through MCP tool-use High


MCP (Model Context Protocol) tools and function-calling plugins let agents make HTTP requests, query databases, and interact with external services. When those tools need authentication, the credentials often flow through the agent's context.

MCP server config (e.g., in .cursor/mcp.json or claude_desktop_config.json):

{
"mcpServers": {
"database": {
"command": "npx",
"args": ["@modelcontextprotocol/server-postgres",
"postgresql://admin:s3cretP@ss@db.example.com/prod"]
}
}
}


That connection string — with the password — sits in a JSON config file. The agent reads it. The MCP server process inherits it. If the agent logs the connection for debugging, the password is in the conversation.

It gets worse with HTTP-based tools. An agent calling a REST API through an MCP tool might construct the request with an `Authorization` header. The tool call and its parameters — including the auth header — are part of the conversation context. Logged, stored, and visible in the conversation history.

### How to reproduce it

Set up an MCP server with credentials in the config

Ask the agent to "query the database for recent users"

Watch the tool call — the connection string (including password)

appears in the agent's tool invocation log

Or: configure an API tool with an auth header

Ask the agent to "fetch my account details from the API"

The Authorization header appears in the tool call parameters


**The fix:** Never put credentials in MCP config files as plaintext. Use environment variable references that resolve at runtime. Better yet, have the MCP server pull credentials from the Keychain directly, so the agent never sees or transmits the auth values.

## The root cause behind every AI agent secret leak

All six leaks share one root cause: **secrets and agents occupy the same space**. The secret is in a file the agent reads, an environment it inherits, a config it parses, or a conversation it participates in.

Secrets and agents occupy the same space. The fix is separation.

The solution is separation. Secrets flow through secure channels — Keychain to encrypted handoff to process environment. Agents operate in their context — text, conversation, code generation. The two never mix.

Install the DLP guard in 30 seconds

## The DLP guard: catch leaked API keys automatically


The NoxKey DLP guard scans agent output against 8-character fingerprints of every secret in your Keychain. If any output contains a value matching a stored secret, it blocks the output before it enters the conversation.

Install the guard

noxkey guard install

It runs automatically as a PostToolUse hook in Claude Code.

No config. No setup beyond the install command.

What it looks like when it catches something:

Agent runs: curl -v https://api.stripe.com/v1/charges

Agent output contains: "Authorization: Bearer sk_live_51ABC..."

Guard: BLOCKED — matches myorg/project/STRIPE_KEY

Output is redacted before entering context.

You see: [REDACTED — credential detected]

The agent sees: nothing. The secret never entered the conversation.


This catches leaks 2, 3, and 4 — debug output, conversation logs, and generated code that includes credential values. It does not prevent the agent from accessing `.env` files or inheriting environment variables (leaks 1 and 5), which is why [eliminating .env files](https://noboxdev.com/blog/stop-putting-secrets-in-env-files) and using encrypted handoff are still necessary.

The guard matches on 8-character prefixes, so extremely short secrets or secrets that share prefixes with common strings could theoretically produce false positives. In practice, API keys and tokens are long enough that this is not an issue. We have been running it for months with zero false positives across ~200 stored secrets.

## How to secure your API keys from AI agents right now

The leaks are real. The fixes exist. Here is the priority order:

  - **Delete your .env files.** Move secrets to the Keychain. This eliminates leak #1 entirely. ([Here is how we did it.](https://noboxdev.com/blog/why-i-deleted-every-env-file))
  - **Install the DLP guard.** One command. Catches leaks #2, #3, and #4 automatically.
  - **Use encrypted handoff.** Process-tree detection + encrypted responses prevent leak #5.
  - **Audit your MCP configs.** Remove hardcoded credentials from tool server configurations.
  - **Stop pasting credentials into chats.** There is no technical fix for voluntarily sending secrets to a third party.

Install NoxKey and the DLP guard — 30 seconds total

brew install no-box-dev/noxkey/noxkey
noxkey guard install




Key Takeaway

AI agents leak secrets through six vectors: reading .env files, debug output, conversation logs, generated code, process inheritance, and MCP tool-use. All six share the same root cause — secrets and agents occupy the same space. The fix is separation: [store secrets in the Keychain](https://noboxdev.com/blog/stop-putting-secrets-in-env-files), deliver them via encrypted handoff, and install the DLP guard to catch any values that slip through. [Touch ID](https://noboxdev.com/blog/touch-id-api-keys) ensures no agent can access a secret without your physical confirmation.

---
*NoxKey is free and open source. `brew install no-box-dev/noxkey/noxkey` — [GitHub](https://github.com/No-Box-Dev/Noxkey) | [Website](https://noxkey.ai)*

Why We Deleted Every .env File — And What Replaced Them

JasperNoBoxDev — Sun, 22 Mar 2026 15:54:51 +0000

It started at 1am on a Tuesday. We were rotating a Cloudflare API token — routine stuff, the old one was about to expire. We updated the .env in the active project, ran the deploy, everything worked. Then the staging environment for a different project broke. Same token, different .env, still pointing to the old value.

Fixed it. Then a third project broke the next morning.

That is when we ran the command that changed everything:

$ find ~/dev -name ".env" -not -path "*/node_modules/*" -not -path "*/.git/*"
./boundless-learning/.env
./gitpulse/.env
./gitpulse/api/.env
./noxterm/website/.env
./blindspot/.env
./blindspot/api/.env
./112schade/.env
./bitz-snoek/.env
./playnist/.env
...

$ find ~/dev -name ".env" -not -path "*/node_modules/*" -not -path "*/.git/*" | wc -l
47

Forty-seven .env files. On one machine.

47
.env files on one machine

6
duplicated keys across projects


8 months
forgotten with live credentials

The .env file audit that started it all

We spent the next hour opening every single one.

The duplicates. The Cloudflare API token — the one that just broke three projects — appeared in 6 different files. An OpenAI API key was in 8. The same Postmark server token sat in 4 projects, two of which had not been touched in over a year.

The expired ones. A Stripe test key that had been rotated months ago was still sitting in three .env files. It no longer worked, but nobody cleaned it up. If it had been accidentally used in production, the result would have been silent auth failures — mysterious 401s at 2am with no explanation.

Critical
The dangerous ones. A healthcare API project had a .env with a production database connection string. Full admin credentials. The project was archived — untouched for 8 months. But the credentials were still valid. Anyone with access to the machine could have connected to a production database with patient-adjacent data.

The forgotten ones. A side project from early 2024 — a weekend experiment, completely forgotten — still had a live Stripe secret key in its .env. Not a test key. The real one. Connected to a real account with a real credit card.

Forty-seven plaintext files with zero authentication, scattered across the filesystem, containing credentials we could not even remember storing. Some valid, some expired, no way to tell which without checking each one manually.

Migrating from .env files to macOS Keychain

We decided to move everything to the macOS Keychain using NoxKey and delete every .env file on the machine. The whole process took one afternoon.

The workflow for each project:

.env workflow

# Plaintext file, no auth
$ cat .env
DATABASE_URL=postgresql://...
OAUTH_CLIENT_SECRET=abc...
OPENAI_API_KEY=sk-proj-...

# Hope you .gitignored it
# Hope no agent reads it
# Hope you remember to update it

NoxKey workflow

# Step 1: Import the .env file
$ noxkey import noboxdev/gitpulse .env
✓ Imported 4 secrets

# Step 2: Verify everything landed
$ noxkey ls noboxdev/gitpulse/

# Step 3: Peek to confirm
$ noxkey peek noboxdev/gitpulse/OPENAI_API_KEY
sk-proj-...

# Step 4: Test it works
$ eval "$(noxkey get noboxdev/gitpulse/OPENAI_API_KEY)"

# Step 5: Delete the liability
$ rm .env

Import .env → Verify with ls → Peek to confirm → Test with eval → Delete .env

For projects that shared secrets — like the Cloudflare token that lived in 6 places — we stored it once under a shared prefix:

$ noxkey set shared/CLOUDFLARE_API_TOKEN --clipboard
✓ Stored shared/CLOUDFLARE_API_TOKEN

One token. One location. Accessible from any project. When we rotate it next time, we update it once. Not six times. Not three-out-of-six times.

The healthcare API credentials got an extra layer:

$ noxkey strict noboxdev/healthcare-api/DATABASE_URL
✓ Marked as strict — always requires Touch ID

Strict mode means that secret always requires Touch ID, even during a session unlock. No shortcuts for credentials that could expose patient data.

The first week without .env files

The first two days were friction city.

Every time we opened a terminal, muscle memory reached for the .env that was not there anymore. Instead of source .env or letting dotenv auto-load, the workflow was eval "$(noxkey get noboxdev/project/KEY)" with a Touch ID prompt for each secret.

Day two almost broke us. Debugging a webhook integration, restarting the server about fifteen times in an hour. Touch ID fifteen times. It felt excessive.

Tip
Then we discovered session unlock:

$ noxkey unlock noboxdev/blindspot
✓ Session unlocked — Touch ID skipped for noboxdev/blindspot/* until session expires

One Touch ID authentication, then every get under that prefix skips the prompt for the rest of the session. Unlock at the start of a work session and forget about it.

By day four, the new workflow felt natural. By end of week, it was invisible.

How AI agent security became the bigger win

Two weeks after the migration, we were pair-programming with Claude Code on the Blindspot project. The agent needed the Postmark token to test an email integration. Old workflow: it would have read the .env and the raw token would be sitting in the conversation context. Logged. Visible. Potentially leaked in an error message.

Instead, the agent ran noxkey get. NoxKey detected the agent by walking the process tree, encrypted the value with AES-256-CBC, wrote a self-deleting temp script, and returned a source command. The secret reached the shell environment, but the raw value never appeared in the conversation.

We had not even been thinking about AI agent security during the migration. We deleted our .env files because of the duplication and rotation mess. The agent safety was a side effect — and turned out to be the more important benefit. We use AI agents every day now. Every single session would have been reading plaintext secrets if those .env files still existed.

For more on this attack surface, we wrote about six specific ways agents can leak your secrets.

Six months without a single .env file

Key rotation is a non-event. When the Cloudflare token expires, we update it in one place. Every project picks up the new value next time it runs noxkey get. No hunting through directories. No grepping for old values. No "which three of the six copies did we forget to update?"

We know exactly what we have. noxkey ls shows every secret on the machine, organized by project. No more discovering a forgotten Stripe key in an archived repo. If it is in the Keychain, we can see it. If it is not, it does not exist on this machine.

$ noxkey ls
noboxdev/blindspot/POSTMARK_SERVER_TOKEN
noboxdev/blindspot/DATABASE_URL
noboxdev/gitpulse/DATABASE_URL
noboxdev/gitpulse/OAUTH_CLIENT_SECRET
noboxdev/gitpulse/OPENAI_API_KEY
noboxdev/healthcare-api/DATABASE_URL          [strict]
shared/CLOUDFLARE_API_TOKEN
shared/CLOUDFLARE_ACCOUNT_ID
...

New projects start clean. No .env.example to copy and fill in. Store secrets once with noxkey set and load them with eval. The project directory has zero credential files. Nothing to accidentally commit, nothing for an agent to read, nothing to forget about when the project gets archived.

The background anxiety about plaintext credentials is gone.

The anxiety is gone. This one was unexpected. We did not realize how much low-grade background worry those plaintext files caused. "Did we .gitignore that correctly?" "Is that old project's .env still sitting there with live keys?" "Did the AI just read our database credentials?" Those questions do not exist anymore. The secrets are in the Keychain, behind Touch ID.

The honest downsides of leaving .env behind

It is macOS only. We work exclusively on macOS, so this is not a limitation for us. If you are on a mixed team, your Linux colleagues need a different solution. The principle is the same — use your OS credential store — but NoxKey will not help them.

Onboarding new team members takes an extra step. Instead of "here is the .env.example, fill in your keys," it is "install NoxKey, then noxkey set each key." More steps the first time. Simpler every time after.

Some tools expect .env files. Docker Compose, certain Node.js frameworks, Vercel's local dev server. For those, we generate a temporary .env from the Keychain, use it, and delete it. Not perfect. But the alternative is 47 plaintext files with no authentication.

Run this command right now

find ~/dev -name ".env" -not -path "*/node_modules/*" -not -path "*/.git/*" | wc -l

Whatever number you see — that is how many plaintext files with zero authentication are on your machine right now, containing credentials that any process, any agent, any accidental git push can expose.

NoxKey is not the only answer. But .env files are the wrong answer. Use your Keychain. Use 1Password CLI. Use something with actual authentication. Stop treating plaintext files as secret storage.

Key Takeaway
47 .env files with zero authentication, scattered across one machine, containing credentials we could not even remember storing. The fix: import them into your OS Keychain with noxkey import, verify with noxkey ls, then delete every .env file. One afternoon of work eliminates plaintext secrets, duplicate key rot, and AI agent exposure — permanently.

If NoxKey is the route you want to take:

brew install no-box-dev/noxkey/noxkey

Free, no account, no cloud, your secrets never leave your machine. The migration took one afternoon. Six months later, there is no going back.

Frequently asked questions

*How many .env files does the average developer have?*
We found 47 across one machine — spanning active projects, archived repos, and forgotten prototypes. Many contained duplicate or expired keys. Running noxkey scan . from your home directory will find yours.

*What replaces .env files?*
The macOS Keychain. It's hardware-encrypted, protected by Touch ID, and already on your Mac. NoxKey provides a developer CLI on top: noxkey import myorg .env migrates your secrets, then eval "$(noxkey get myorg/KEY)" loads them into your shell.

*Is it safe to delete .env files after migrating?*
Yes, once you've verified the import with noxkey ls myorg/ and confirmed each key with noxkey peek myorg/KEY (shows first 8 characters). We recommend keeping a backup for 48 hours, then deleting permanently.

*Does this work with Docker and CI/CD?*
NoxKey is for local development. For Docker and CI/CD, use your provider's secret management (GitHub Actions secrets, AWS Secrets Manager, etc.). NoxKey replaces the plaintext .env files on your development machine.

NoxKey is free and open source. brew install no-box-dev/noxkey/noxkey — GitHub | Website