Your LLM API keys are a massive lia

Hard-coding your OpenAI or Anthropic keys directly into your .env file is the fastest way to wake up to a $500 bill because you accidentally pushed a commit to a public GitHub repo. I've seen it happen to too many teammates. While .gitignore is the standard answer, it's a fragile defense; one mistake during a merge or a lazy git add . and your credentials are leaked.

The real shift in productivity comes when you stop treating API keys as static strings and start treating them as dynamic environment resources. If you're using Cursor or Claude Code, you're likely toggling between different model providers. Managing these manually is a nightmare.

I've switched to using a local secret manager or a vaulted environment approach. For those of you on macOS/Linux, stop using raw .env files for everything and start leveraging a tool like direnv. It loads environment variables only when you enter a specific directory and unloads them when you leave, reducing the blast radius if a process goes rogue.

My current "Safe-Key" Workflow:

• Local Vaulting: Use a tool like 1Password CLI or Doppler to inject keys at runtime.
• Strict Scoping: Never use a "Master Key." Create project-specific keys with strict usage limits (hard caps) set in the provider's dashboard.
• The Wrapper Strategy: Instead of calling the API directly in your business logic, use a lightweight proxy or a wrapper class that handles the key injection.

Here is a simple Python wrapper pattern I use to ensure keys are never accidentally printed in logs or leaked via exception tracebacks:

import os
from typing import Optional

class AIClient:
    def __init__(self):
        # Fetch from environment, never hardcoded
        self._api_key = os.getenv("ANTHROPIC_API_KEY")
        if not self._api_key:
            raise ValueError("Missing API Key: Ensure your secret manager is active.")

    def get_client(self):
        # Return the initialized client here
        # This prevents the key from being a global variable
        return SomeAIProvider(api_key=self._api_key)

# Usage
client = AIClient().get_client()

One massive "gotcha" with Cursor's .cursorrules file: avoid putting any actual keys or sensitive endpoint URLs inside it. Since .cursorrules is often shared across a team to keep the AI aligned on coding standards, putting a key there is practically the same as publishing it to the web.

If you are building a tool that others will use, stop asking users to paste their keys into a text field. Implement a "Key Validation" step that checks the key's validity with a cheap list_models call and immediately encrypts it before storing it in a database.

Pro-tip for Claude Code users:
Since Claude Code runs in your terminal, it can sometimes pick up keys from your shell profile (.zshrc or .bashrc). This is dangerous because any script you run in that terminal can potentially read those variables. I recommend using a dedicated shell session for AI work or using a tool like dotenv-shell to isolate the environment.

The "Panic" Checklist if you leak a key:

• Revoke immediately in the provider dashboard (don't just delete the code).
• Rotate all other keys if they shared the same naming convention.
• Audit your usage logs to see if the leaked key was used for massive batch processing.
• Update your .gitignore to explicitly include .env, .env.local, and any .json credential files.