How do you protect passwords and API keys when you build with AI?

When you build an app with an AI tool, secrets travel in places they never used to. You paste an error message into a chat and it includes a database password. An agent reads your whole project folder, .env file included. A vibe-coded front end calls an API directly from the browser, so the key ships to every visitor. None of this is exotic; it is the most common way small AI-built projects get into trouble.

The good news is that a few habits, set up once, cover most of the risk. The idea is simple: secrets live in one place, the AI never sees them, and an automatic check stops them from leaving your computer.

What counts as a secret?

A secret is anything that lets someone act as you or as your app: API keys (for OpenAI, Anthropic, Stripe and so on), database passwords and connection strings, private keys, access tokens, and the "service role" or admin keys that database platforms such as Supabase give you. Some keys are designed to be public, for example a Supabase "anon" key in a web page, but they are only safe if the database behind them has strict access rules. Treat everything else as private.

The Moltbook case from early 2026 shows how it goes wrong. Moltbook was a social network for AI agents. The security firm Wiz found a database key visible in the site's JavaScript, with no row-level security (rules that limit each user to their own rows) behind it. Anyone could read and write the production data, which included about 1.5 million agent API tokens, around 35,000 email addresses, and private messages, some of them holding other companies' API keys in plain text. Moltbook fixed it within hours of being told, but by then the keys had been readable.

A setup that keeps keys out of reach

Here is a routine that works with Claude Code, Codex, Cursor and most other coding agents.

Step 1: put secrets in a .env file, never in code. Your code reads them as environment variables (process.env.STRIPE_KEY in JavaScript, os.environ["STRIPE_KEY"] in Python). Add .env to .gitignore so git never commits it, and commit a .env.example with empty values so others know which names to set.

Step 2: tell the agent it may not read secrets. Instructions files help, but a permission rule is stronger because the tool enforces it. Anthropic's Claude Code documentation shows exactly this example for a settings file:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Save it in ~/.claude/settings.json (for all your projects) or in the project's .claude/settings.json, then run /status in Claude Code to confirm it loaded. Other agents have similar ignore or permission settings; check yours.

Step 3: turn on secret scanning before your first push. GitHub's push protection scans what you push and blocks a push that contains a recognized credential, explaining why, so you can remove it and try again. For your personal account it is on by default for public repositories; for a repository, an administrator has to switch it on in the security settings. Anyone with write access can still bypass a block by giving a reason, so treat a block as a real warning.

Step 4: keep secrets out of chats. Before pasting logs or error messages into an AI tool, scan them for keys and connection strings and replace them with [REDACTED]. If a key was ever pasted, committed or shown in a screenshot, revoke it at the provider and create a new one.

You can ask the agent to help you set this up without ever handing it the values:

Set up this project so secrets are never stored in code.
1. Find every hard-coded key, token, password or connection string and replace it with an environment variable read at runtime.
2. Create a .env.example listing the variable names with empty values, and make sure .env is in .gitignore.
3. Do not open, print or ask me for the contents of .env. Tell me which variables I need to fill in myself.
4. List any key that is used in browser-side code, and explain whether it is meant to be public.

What should you never give an AI agent access to?

An agent does what its permissions allow, including things you didn't intend, if a prompt is misread or if text it reads (a web page, an issue, a file) contains hidden instructions. So decide its limits by asking, "What is the worst this access could do?"

Keep these away from any coding agent:

• Production databases and production keys. Give it a development copy with fake data. If it must touch production, use a read-only account limited to the tables it needs.
• Payment and banking credentials, including live Stripe or PayPal keys. Use the provider's test mode.
• Your password manager, email and personal cloud accounts. An agent that can read your email can be tricked by an email.
• Cloud admin or "owner" credentials that can create, delete or bill resources. Create a narrow key for each task.
• Unreviewed access to main or to deployments. Let the agent work on a branch; you merge and deploy.

Give it instead: a sandbox or a separate folder, test keys with spending limits, and permission rules that ask before running commands you haven't approved. If the agent needs a real credential to finish a task, that is your signal to do that step yourself.