Safe AI for Designers: The Five Rules to Start With
How to use AI without leaking keys, breaking production, or sharing the wrong things. Plain English. Five rules every designer should set up before their first prompt.
Why read this first
AI is fast, friendly, and forgetful of your safety. The five rules below take twenty minutes and save you from the most common mistakes people make in their first month.
You do not need to be technical to use AI safely. You need to know what to share, what to hide, and where to stop. That is what this guide gives you.
The five rules in one minute
Never share your API keys
Not in code. Not in chat. Not in screenshots. Not even with your best teammate. Treat them like a credit card number.
Keep secrets in a .env file
The .env file lives on your computer, never in GitHub. Your app reads from it at runtime. Add it to .gitignore the day you create it.
Read before you paste
Before you paste a file into AI, scan it for words like KEY, SECRET, TOKEN, PASSWORD. If you see one, do not paste.
Never touch production if you are unsure
Production is the live system real users depend on. If a step says “this will deploy” or “this will run on prod” and you do not understand it, stop. Ask. Test on a copy first.
Rotate keys when in doubt
If you think a key was seen by someone, rotate it. Rotating a key takes two minutes. Cleaning up a leaked one takes days.
What is an API key, plainly
An API key is a long string that proves you are you when your software talks to another service. Imagine a hotel keycard that opens every door in the building, including the one billing you for the room.
If someone gets your OpenAI key, they can run prompts on your account until your card maxes out. If someone gets your Stripe key, they can read or change your customer data. The key does not know who is holding it. It just opens doors.
A leaked API key is not a security alert. It is an open tap. The bill or the breach starts the moment it leaks, not the moment you notice.
Where API keys belong
- .env file On your laptop only. Add to .gitignore.
- Password manager 1Password, Bitwarden, Apple Passwords.
- Vercel env vars Set in the dashboard, not in code.
- GitHub Secrets For CI/CD only. Never in the repo.
- Cloud secret store AWS Secrets Manager, Doppler.
- Your team's vault Shared password manager, never DM.
Notice what is NOT on this list: your code files, Slack DMs, screenshots in tickets, copy-pasted into a Claude chat, in a tweet about your cool new project. If a key is anywhere a human or a search engine can read it, it is leaked.
Rule 1: Never share your API keys
The longest version of this rule is one sentence: do not put your key anywhere you would not put your home address.
Every API key has its own dashboard somewhere. OpenAI keys live in platform.openai.com. Anthropic keys live in console.anthropic.com. Vercel, Stripe, Supabase, Mux, all have their own. You can always go to the dashboard and rotate. You should never need to send the key to anyone over chat.
A teammate asks for your key
You ask your teammate to set up the project. They say “what’s the OpenAI key?”
The right answer is: “I’ll add you to the team in the OpenAI dashboard. Generate your own.” It takes the same amount of time. It means if their laptop gets stolen, only their key gets revoked, not yours.
Rule 2: Keep secrets in a .env file
A .env file is a tiny text file at the root of your project. It looks like this:
OPENAI_API_KEY=sk-proj-abc123...
ANTHROPIC_API_KEY=sk-ant-xyz789...
TURSO_DATABASE_URL=libsql://my-db.turso.ioThree rules for .env:
- Add it to .gitignore. Open the file called .gitignore at the root of your project. Add a line that says
.env. Save. From now on, Git ignores it. It never makes it to GitHub. - Never commit a real key as an example. When you add a new variable, also add a
.env.examplefile with the same names but fake values, likeOPENAI_API_KEY=sk-.... That is the file you commit. The real one stays on your laptop. - Each environment has its own. Local laptop, staging server, production. Different keys. Never one key everywhere.
You still want a .env file. AI tools, code editors, and even shell history can accidentally surface code you write. Putting secrets in their own file means you can share screenshots, paste snippets, or copy code into AI without leaking. It is also one search-and-replace away from working with any new tool you adopt later.
Rule 3: Read before you paste
The single most common designer mistake is pasting an entire config file into AI to ask “what does this do?” with the API key still inside.
Before you paste anything into Claude, ChatGPT, or Cursor, glance at it for these words:
What you learned
If you see any of these, do not paste the file. Replace the value with <REDACTED> first, or paste only the part you actually need help with.
What is safe to share with AI?
| Criterion | Public code Best pick From your open repo | Private code Internal but no secrets | Customer data Names, emails, support tickets | Secrets Keys, passwords, tokens |
|---|---|---|---|---|
| OK to paste | ✓ | ✓ | — | — |
| Strip sensitive lines first | — | ✓ | ✓ | — |
| Use a sample instead | — | — | ✓ | ✓ |
| Never paste, ever | — | — | — | ✓ |
For private work code: most companies are fine with you using AI on it as long as you turn off training on your data. In Claude and ChatGPT, this is a setting in your account. Turn it off once and forget about it.
For customer data: the rule is “minimum needed.” If you can replace real names with “Customer A” and a real email with “user@example.com”, do that. AI does not care about the literal name. It cares about the structure.
Rule 4: Never touch production if you are unsure
Production is the live version of the thing real users use. Your portfolio site, your company’s web app, the database that has actual customer orders.
When AI gives you a command and the words “production”, “prod”, “deploy”, “main branch”, “publish”, or “drop database” appear, slow down. AI is confident even when it is wrong. The model that just generated rm -rf / thinks the command is reasonable. It does not know your database has the only copy of your customer’s orders.
- 01
Read the whole command
Out loud if it helps. Make sure you understand what each part does.
- 02
Try it on a copy first
Local laptop, a staging branch, a test database. Anywhere that is not real users.
- 03
Look for an undo
If something goes wrong, can you reverse it? If not, take a backup first.
- 04
Then run it on prod
Only when the first three steps are clear.
That is the moment to be most careful. AI does not know your context. It does not know which branch you are on, what the database looks like, or whether you have backups. The phrase “totally safe” comes from confidence, not certainty. Run on a copy first, every time.
Rule 5: Rotate keys when in doubt
Rotating a key means: delete the old one, create a new one, update your app to use the new one. Two minutes of work. The old key stops working the moment you delete it.
Rotate when:
- You typed your key into an AI chat by accident.
- You committed a .env file and pushed to GitHub.
- A teammate’s laptop got lost or stolen.
- You posted a screenshot and you cannot remember what was visible.
- You changed jobs or laptops and forgot what you copied where.
- Honestly, any time the question crosses your mind.
The cost of rotating a key is two minutes. The cost of not rotating a leaked key can be your entire OpenAI bill, your customer data, or your reputation. Always rotate.
What to do right now
Audit your machine in fifteen minutes
-
Check your last GitHub commit for secrets
Open the GitHub repo for your most recent project. Click the most recent commit. Use Cmd-F to search the diff for KEY, SECRET, TOKEN, PASSWORD. If you find any, rotate them today and rewrite the commit history.
You see no key-like values in your last commit, OR you found some and you have rotated them. -
Confirm .env is in .gitignore
Open the .gitignore file at the root of your project. Search for “.env” on its own line. If it is missing, add it. If you do not have a .gitignore file, create one and add “.env” as the first line.
Your .gitignore file contains a line that says “.env” without anything after it. -
Move secrets out of your code into .env
Search your codebase for any line that contains your real API key value. If you find any, replace the value with
process.env.OPENAI_API_KEY(or the equivalent for your language) and add the actual key to your .env file.No real key values appear directly in your source files. They all come from environment variables.
Recap
What you learned
What to read next
Finished the last lesson?
Mark it complete to wrap up "Beginner AI Setup" on your dashboard.
Try with Prompts
Ready-to-use prompts related to this guide