Your API Keys Are Leaking: A Developer's Guide to Credential Hygiene With Proton Pass

Last updated: 2026-06-18

You run Ollama locally. You've audited your browser extensions. You know exactly which AI providers see your prompts and which don't. Your threat model is documented.

Then you check in a .env file with your OpenAI key still in it, and GitHub's secret scanner flags it four seconds later.

API key hygiene is the credential problem that privacy-conscious developers consistently undersolve. It is not as visible as cloud AI surveillance, but the blast radius when it goes wrong is immediate and expensive. A leaked AWS key can generate a $47,000 bill before you wake up — and that has happened to real developers, not as a hypothetical.

This article is about the adjacent problem: the same person who runs local LLMs and uses encrypted email still needs a structured, private workflow for managing the hundreds of credentials that modern development requires.

The Scale of the Problem You Are Probably Ignoring

Most developers dramatically underestimate how many credentials they actually manage. Count yours:

Cloud provider keys (AWS, GCP, Azure) — often multiple per environment
AI API keys (OpenAI, Anthropic, Mistral, Replicate, Hugging Face)
Version control tokens (GitHub PATs, GitLab tokens)
Database connection strings with embedded passwords
Third-party SaaS API keys (Stripe, Twilio, SendGrid, Resend, etc.)
Internal service secrets and webhook signing keys
SSH keys for servers, with passphrases optionally attached
Certificate private keys
OAuth client secrets
Docker registry credentials
NPM and package registry auth tokens

A developer working on a mid-size application can easily have 30-50 active credentials at any given time. A senior engineer managing multiple projects might have 100+. Most of these are rotated infrequently, if at all.

The question is not whether you have a credential problem. The question is how exposed you currently are.

Where API Keys Actually Leak

The seven most common paths for developer credential exposure are not the ones that get press coverage. It is rarely a sophisticated attack. It is almost always operational sloppiness that becomes a liability.

1. Git history.

The .env file that never touched your main branch still exists in your git history if you ever committed it anywhere. GitHub's secret scanning covers public repos automatically and enterprise repos optionally — but your own private repos are not automatically protected unless you configure it. git log --all --full-history -- .env will show you how many times you have committed secrets.

2. Shell history.

Running curl -H "Authorization: Bearer sk-ant-abc123" in your terminal is logged in .bash_history or .zsh_history. If you pipe those API keys into scripts, debug them by printing them, or pass them as command-line arguments, your terminal history is a credential dump.

3. Log files.

Debugging an API integration and the error message prints the full request object? Your API key is now in a log file. Log files rotate, but they also get uploaded to centralized logging services — Datadog, Papertrail, CloudWatch — and retained for months or years.

4. Clipboard.

You copy an API key to paste it into an environment variable. That key sits in your clipboard, and potentially in a clipboard history manager, for hours or days. Cloud clipboard sync (Apple Universal Clipboard, Windows Clipboard History) pushes that key to synced devices.

5. Messaging and email.

"Hey, can you test with my key for now?" That Slack message, that email, that text — it is stored on someone else's server indefinitely. Slack has a 90-day message limit on free plans. Paid plans have no limit. Your API keys live there.

6. Browser autofill and developer tools.

Pasting a key into a web dashboard means your browser's autofill system has seen it. Developer tools in Chrome can log network requests including Authorization headers. If you use browser sync, that session data moves to Google or Apple's servers.

7. Shared environment files.

The .env.example file that accidentally became .env and got committed. The config.json file that was supposed to have placeholder values. The developer who sent their .env file over email because they were onboarding a contractor quickly. Every team has these stories.

Why Standard Password Managers Fall Short for Developers

The typical advice — "use a password manager" — is correct but incomplete for developer credential workflows. Standard consumer password managers are designed for website credentials: username, password, URL. They are excellent at that.

Developer credentials are structurally different:

API keys have no URL. There is no canonical URL to associate with your sk_live_abc123 Stripe key. You might use it in five different services.
Credentials have structure. An AWS credential is an access key ID plus a secret access key. A database connection is a host, port, username, password, and database name. Consumer password managers treat these as one blob of text.
Credential sets need labels and metadata. You need to know which environment (production, staging, dev), which project, which permission scope, and when it was last rotated.
Credentials need to be shareable with teams without the team member ever seeing the plaintext. You want them to be able to use the credential in a shared environment without being able to extract and misuse it.
Credentials have rotation requirements. Unlike a stable website password, API keys should be rotated regularly. Your password manager should track this.

Most consumer password managers (including excellent ones) treat a 240-character AWS secret access key the same way they treat a Netflix password. That is not the right tool architecture.

What a Proper Developer Credential Workflow Looks Like

Before looking at specific tools, it helps to define what "solved" looks like:

Every credential lives in exactly one place. Not split between .env files, a password manager, a team wiki, and your memory. One source of truth.

No credential ever appears in cleartext in your codebase. Even in .env files that are gitignored. Your local .env file should be auto-populated from your credential manager, not hand-edited.

Credentials are scoped to the minimum required permissions. Your local dev environment key does not need write access to production databases. Scope everything to least privilege.

You know the rotation status of every credential. When was it last rotated? When does it expire? What would break if you rotated it today?

Sharing credentials happens through structured, audited channels. Not Slack. Not email. A system where you can see who accessed what and when.

Revocation is immediate and verifiable. If a credential is compromised, you can revoke it in 30 seconds and know exactly where it was used.

Getting to this state requires tooling. The two categories of tools that matter are secrets managers for production infrastructure (Vault, AWS Secrets Manager, Doppler) and credential managers for individual developers. Most of the credential leaks listed above happen at the individual developer level, before production secrets management ever enters the picture.

Proton Pass: A Privacy-First Credential Manager for Developers

Proton Pass entered the market in 2023 as the fifth major product in the Proton ecosystem (alongside Mail, VPN, Drive, and Calendar). It is the product in the lineup that gets the least attention from the privacy community, because password managers are less dramatic than encrypted email. That is a mistake.

For privacy-conscious developers specifically, Proton Pass has a set of properties that make it worth considering over the alternatives.

End-to-end encryption with zero-knowledge architecture. Proton cannot read your stored credentials. They hold no keys to decrypt your vault. This is the same architecture as Proton Mail, where not even Proton can read your messages. For storing production credentials, zero-knowledge encryption matters: you want the company holding your vault to be technically unable to produce plaintext in response to a subpoena.

Swiss jurisdiction. Proton is headquartered in Geneva, under Swiss privacy law. Switzerland is not a member of the EU or the US-led Five Eyes intelligence alliance. Swiss law requires a Swiss court order to compel disclosure, and Swiss courts apply a higher privacy standard than most US or EU jurisdictions. For developers storing credentials to production systems that handle user data, jurisdiction is a compliance consideration, not just a philosophical one.

Open source client. Proton Pass clients (web, mobile, browser extension) are open source. The code is publicly audited and reviewable. When you store a credential in Proton Pass, you can verify that the encryption happens on your device before transmission rather than taking the company's word for it. Most competitors are proprietary black boxes.

Structured secrets. Beyond username/password pairs, Proton Pass supports arbitrary custom fields: you can create entries with multiple key-value pairs, notes, and metadata. An AWS credential can be stored as a structured entry with separate fields for access key ID, secret access key, region, and environment label. This is closer to how developer credentials actually exist.

Integration with the broader Proton ecosystem. If you are already using Proton Mail for encrypted email and Proton Drive for zero-knowledge file storage, adding Proton Pass puts your entire credential surface — communication, files, and secrets — under a single Swiss-jurisdiction, zero-knowledge umbrella. That is a materially different privacy posture than splitting credentials across Bitwarden (a US company), email on Gmail, and files on Dropbox.

Put your credentials under zero-knowledge encryption

Proton Pass stores your API keys, logins, and secrets with end-to-end encryption under Swiss law. Part of the Proton ecosystem — pair it with encrypted email, VPN, and cloud storage in one subscription.

Learn More

Affiliate Disclosure: This article may contain affiliate links. If you make a purchase through these links, we may earn a small commission at no extra cost to you. We only recommend products we genuinely believe in. This helps support our work and allows us to continue providing free content.

Migrating Your Developer Credential Workflow

Getting from "keys scattered everywhere" to a managed credential system is a multi-day project, not a weekend afternoon. Here is a realistic migration sequence.

Step 1: Audit What You Have

Before migrating anything, enumerate your credentials. The goal is a complete list, not a perfect one. Go through:

Every project's .env, .env.local, .env.development, and .env.production files
Your shell history (~/.zsh_history or ~/.bash_history) — search for Bearer, Authorization, sk-, api_key, secret
Your email — search for "API key", "access key", "secret key", "token" in your sent mail
Your notes apps, team wikis, and internal documentation
Browser saved passwords (export to CSV, then delete from browser after migrating)

You will find credentials you forgot existed. Some of them will have been rotated. Others will not.

Step 2: Categorize and Assign to Projects

For each credential, record: the service it belongs to, the permission scope, the environment (prod/staging/dev), the project, and the last rotation date. Do this in a temporary spreadsheet before importing to any manager.

Step 3: Revoke Everything You Cannot Account For

Any credential you cannot verify was created by you, for a specific purpose, and is still in use — revoke it. This is uncomfortable but necessary. A credential you cannot account for is a liability you cannot measure.

Step 4: Set Up Proton Pass With Structured Entries

Install Proton Pass browser extension and mobile app. Create a logical organization structure before importing:

Folders by environment: Production, Staging, Development
Or folders by project: Project Alpha, Project Beta, Shared Infrastructure
Nested vaults if you have team-shared vs. personal credentials

For each active credential, create a structured entry with custom fields rather than using the generic password field for everything. The extra 30 seconds per entry pays dividends when you need to find and rotate credentials quickly.

Step 5: Adopt `.env` from Vault Going Forward

Your local .env files should be generated from your credential manager, not hand-edited. Proton Pass does not yet offer native CLI integration with the dotenv ecosystem the way Doppler does — that capability is more appropriate for team environments. For individual developers, the workflow is: open Proton Pass, copy the specific credential, paste into your environment, close. The credential never lives in your codebase.

Step 6: Establish a Rotation Schedule

For each production credential, set a rotation reminder. A common schedule: AWS keys every 90 days, third-party API keys every 180 days, database passwords every 90 days. Use calendar reminders or Proton Pass's note fields to track rotation dates.

The Operational Reality

No tool changes behavior by itself. The developers who actually eliminate credential leaks share a set of habits more than a specific toolchain:

Pre-commit hooks. Install gitleaks or truffleHog as a pre-commit hook. It scans staged files for credential patterns before they ever touch git history. This is the highest-leverage single change you can make. Setup takes five minutes.

Gitignore discipline. The .env file belongs in .gitignore at the repository root, not just in your personal global gitignore. Check every repository.

No credentials in messages. The rule is absolute: credentials never go through Slack, Teams, email, or SMS. If you need to share a credential, share it through a password manager's sharing feature, an encrypted note, or a short-lived secrets service (like a self-hosted Bitwarden Send or Proton Pass for shared vaults).

Clipboard awareness. After copying a credential, clear your clipboard immediately after pasting. On macOS: pbcopy < /dev/null. On Linux: xclip -selection clipboard < /dev/null. Make this a reflex.

A Note on Production Secrets Management

This article focuses on individual developer credential hygiene. For production infrastructure, you need dedicated secrets management: HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, or Doppler. These systems handle rotation, audit trails, dynamic credentials, and service-to-service authentication at a scale that no password manager is designed for.

Proton Pass and individual credential management are not a replacement for production secrets management. They are different layers of the same problem: your personal vault handles the credentials you use as a developer human; your infrastructure secrets manager handles the credentials your production services use programmatically.

Both layers matter. Most developers have solved neither.

The Privacy Angle

Privacy-conscious developers often think about their threat model in terms of what they share with AI providers, cloud services, and advertising platforms. Credential management is a different but connected threat vector.

An exposed AWS key does not just generate a bill. Depending on the permissions scoped to that key, it can expose user data from your production database, compromise your S3-hosted assets, or provide access to services your users depend on. The credential security problem is, at its core, a user privacy problem: your credentials are the front door to data that often belongs to other people.

The same values that motivate running a local LLM — control over what you expose, to whom, under what terms — apply to the credentials that govern access to your systems. The discipline is adjacent, the stakes are as high, and the operational cost of getting it right is modest compared to the cost of getting it wrong.

Take the Next Step

If you read this article and thought "I should audit my credentials" — do it this week, not eventually.

The audit takes an afternoon. The habits take a month to build. The alternative is a credential incident that takes days to clean up and damages people who trusted your systems with their data.

Start your Proton ecosystem with a 30-day money-back guarantee

Proton Unlimited covers encrypted email, zero-knowledge cloud storage, VPN, and Proton Pass — one subscription, Swiss privacy law, open-source clients. No lock-in.