API Keys and Secrets for Vibe Coders: Passwords With Better Branding

An API key is not “just a string”

It is a key.

That was not poetry.

It is literally in the name.

An API key is a piece of text that lets software access another service. It may let your app use an AI model, send emails, process payments, upload files, read databases, analyze speech, or perform some other useful act that costs money and creates consequences.

Vibe coders leak API keys because the app asks for one, the AI says “paste it here,” and the beginner obeys because the machine sounds calm.

The machine is not paying the bill.

You are.

Treat API keys like passwords with better branding and worse invoices.

The first rule: secrets are not code

A secret is anything that grants access.

Examples:

• API keys;
• database passwords;
• OAuth client secrets;
• access tokens;
• private keys;
• service account files;
• webhook secrets;
• admin credentials.

These do not belong in normal source code.

Bad:

const apiKey = "sk-live-please-dont-steal-this";

Better:

const apiKey = process.env.OPENAI_API_KEY;

The second version reads the key from the environment instead of hardcoding it into the source file.

That is safer.

Not invincible. Safer.

Security is not a magic cloak. It is a series of locked doors and someone remembering not to tape the keys to the window.

What is a .env file?

A .env file stores environment variables for local development.

Example:

OPENAI_API_KEY=your_key_here
DATABASE_URL=your_database_url_here

Your app reads these values when it runs.

This keeps secrets out of your normal source files.

But the .env file itself is sensitive.

It should not be committed to Git. It should not be uploaded publicly. It should not be shared in screenshots. It should not be pasted into support chats unless you enjoy rotating keys at midnight.

Add .env to .gitignore:

.env
.env.local
.env.*.local

This tells Git to ignore those files.

Without that line, your secret file may enter version history like a vampire invited through the front door.

Once a secret is committed, deleting the line is not always enough.

Git remembers.

Git is beautiful that way. Also inconvenient.

The beginner’s secret-handling workflow

Step 1: Create .env

Add your local secret:

OPENAI_API_KEY=replace_this_with_your_real_key

Step 2: Add .env to .gitignore

.env

Step 3: Use an example file

Create .env.example:

OPENAI_API_KEY=your_openai_api_key_here
DATABASE_URL=your_database_url_here

This file contains placeholder values only.

It tells future-you and collaborators what variables are needed without exposing the real keys.

Step 4: Load the secret in code

Example in Node.js:

const apiKey = process.env.OPENAI_API_KEY;

if (!apiKey) {
  throw new Error("OPENAI_API_KEY is missing");
}

Example in Python:

import os

api_key = os.getenv("OPENAI_API_KEY")

if not api_key:
    raise RuntimeError("OPENAI_API_KEY is missing")

Step 5: Test missing-secret behavior

Run the app without the key.

It should fail clearly.

Not silently. Not by exposing the key. Not by printing your entire environment into the logs like a confession booth with no curtain.

What not to do with API keys

Do not paste keys into public code

If your repo is public, assume anything committed can be seen.

Even if the repo is private, hardcoding keys is still a bad habit.

Private repos can become public. Screenshots can leak. Contractors can access. Tools can index. Humans can be humans.

A secret in code is a secret looking for weather.

Do not put secrets in frontend code

Anything shipped to the browser can usually be inspected by users.

If your API key is in frontend JavaScript, it may be visible.

Bad idea:

const SECRET_KEY = "live-key-inside-browser";

The browser is not a vault.

The browser is a glass box with a nice UI.

Do not paste secrets into random prompts

AI tools may process your prompt through external systems depending on provider, settings, workspace policies, and product design.

Do not paste real secrets into prompts unless you fully understand the privacy and retention policy.

Better:

I have an API key stored as OPENAI_API_KEY. The app says it is missing. Here is the error message, with the key redacted.

Use placeholders.

The AI does not need the real key to explain most problems.

Do not share screenshots with visible keys

Screenshots are where secrets go to die publicly.

Before sharing:

• blur keys;
• crop terminal output;
• remove headers;
• hide .env contents;
• check URLs for tokens;
• inspect logs.

A screenshot can leak more than code.

It can leak keys, file paths, usernames, internal URLs, customer names, and the quiet panic of the person taking it.

Do not use the same key everywhere

Use separate keys for:

• development;
• staging;
• production;
• personal experiments;
• client work.

If a development key leaks, you can rotate it without burning production to the floor.

One key for everything is convenient until it becomes one failure for everything.

Convenience loves a single point of failure.

What to do if you leak a key

First: do not merely delete the key from the file and call it fixed.

That is like removing a snake from a photo and assuming the room is now safe.

If a key was exposed:

1. Revoke or rotate the key in the provider dashboard.
2. Remove it from current code.
3. Remove it from Git history if needed.
4. Check usage logs for abuse.
5. Replace it with a new key.
6. Add .env to .gitignore.
7. Use secret scanning where possible.
8. Review where else the key was copied.

Rotation means making the old key useless and issuing a new one.

This is the part beginners skip because the app works again.

The attacker does not care that the app works. The attacker cares that the old key still works.

Restrict your keys

Many providers let you restrict API keys.

Use restrictions where possible:

• allowed domains;
• allowed IP addresses;
• allowed APIs;
• usage quotas;
• billing limits;
• environment-specific keys;
• read-only access where write access is not needed.

A key should have the smallest permission needed.

This is called least privilege.

Bongbetic calls it:

Do not give the intern a flamethrower to light a candle.

Secrets and AI agents

AI agents complicate secrets because they may need to run tools, call APIs, inspect files, and execute commands.

That does not mean agents should receive broad access.

Ask:

• Does the agent need this key?
• Can it use a development key instead?
• Can permissions be read-only?
• Can the key be scoped to one service?
• Can destructive actions require manual approval?
• Are logs capturing the key?
• Can the agent read .env?
• Can the agent modify .env?

A prompt saying “do not misuse this” is not a security boundary.

It is a polite wish.

Use real permissions.

OWASP’s secrets management guidance emphasizes centralized storage, provisioning, auditing, rotation, and controlled access to secrets. The beginner version is simple: know where keys live, know who can read them, and know how to kill them quickly.

Safer prompts for API-key problems

Missing key

My app says OPENAI_API_KEY is missing. Explain how environment variables work and how to check whether the key is loaded. Do not ask me to paste the actual key.

Frontend exposure check

Review this project structure and tell me whether any API keys may be exposed to browser code. Explain which files are client-side and which are server-side.

Leak response

I accidentally committed an API key. Give me a safe response checklist: rotate key, remove from code, update .gitignore, check history, and verify usage. Do not suggest using the leaked key again.

Agent permissions

This AI agent needs to call an API. What is the minimum permission scope it needs? Suggest a safer key setup for development and production.

These prompts teach the AI to respect the boundary.

The boundary still needs locks.

Beginner checklist before publishing

Before you publish or share a vibe-coded project, check:

• No real API keys in code.
• .env is listed in .gitignore.
• .env.example uses placeholders only.
• No secrets in frontend files.
• No visible keys in screenshots.
• No keys pasted into README files.
• Separate dev and production keys exist.
• Keys are restricted where possible.
• Billing limits are configured where possible.
• Logs do not print secrets.
• Public repo history is checked.
• Leaked keys are rotated, not merely deleted.

If this feels annoying, good.

Security is often annoyance wearing a helmet.

Annoyance is cheaper than incident response.

Final thought

Vibe coding makes it easy to connect powerful services.

That is part of the fun.

A beginner can build with AI models, maps, email, payments, spreadsheets, databases, voice transcription, and search APIs faster than ever.

But every connection has a key.

Every key opens something.

Every open thing needs a boundary.

Do not let the machine, the tutorial, or your own excitement convince you that secrets are just strings.

They are keys.

And keys belong in pockets, vaults, or carefully managed secret stores.

Not in screenshots. Not in Git. Not in prompts. Not in the browser wearing a fake mustache.

Next step

Before your app asks for its first API key, learn where the skeletons are kept.

• Read Vibe Coding Risks
• Read Git for Vibe Coders
• Explore Bongbetic tools

FAQs

What is an API key?

An API key is a credential that lets software access another service. Treat it like a password because it can grant access, trigger usage, and create costs.

Should I put API keys in my code?

No. Avoid hardcoding API keys in source code. Use environment variables or a proper secrets manager depending on the project’s complexity.

What is a .env file?

A .env file stores local environment variables such as API keys and database URLs. It should be excluded from Git using .gitignore.

What should I do if I leak an API key?

Rotate or revoke the key immediately, remove it from code, check Git history and logs, review usage, and replace it with a new restricted key.

Can I paste API keys into AI tools?

Avoid pasting real secrets into prompts. Use placeholders and redacted examples unless you fully understand the tool’s privacy and data-handling settings.