A free guide by New Money School
AI Safety Series
A running list of my top AI safety tips, all in one place. How to vet a skill before you install it, keep your keys from leaking, and set guardrails before you connect any tool.
AI is powerful, which also means it can do damage if you are not careful. These are the exact checks I run so I can use it fast without getting burned. This guide grows as I add more, so save it.
Tip 1Vet A Skill Before You Install It
A downloaded skill can include scripts that run on your computer, so installing one from a creator or GitHub is basically running a stranger's code. Security researchers compare it to opening a random file from an email. Here is my 30-second check.
Step 1
Read it in a plain chat first
Before you install anything, paste the skill's code into a regular Claude chat, not Claude Code. That window can't run anything on your computer or touch your files, so it is a safe place to inspect it.
Prompt — Safety CheckCopy
I'm about to install this as a skill, but I got it from a source I don't fully trust. Before I do, go through every file and line in it, the SKILL.md and any scripts it includes, and tell me in plain terms if anything looks unsafe. Flag anything that tries to access my files, send data somewhere, run hidden commands, grab my passwords or API keys, or do something that doesn't match what the skill claims to do. If it's clean, say so. If anything's off, quote the exact line and tell me why.
Step 2
Only then bring it in
Once it comes back clean, bring it into Claude Code, have it tailor the skill to how you work based on everything it knows about you, then save it as a skill you can trigger whenever you need it.
Honest Note
This catches the obvious red flags fast, but it is a first line of defense, not a guarantee. When you can, only use skills from sources you actually trust.
Tip 2Never Leak Your Keys — The .env File
If you build anything with Claude Code, one slip can leak your passwords to the whole internet. 29 million secret keys leaked on GitHub last year, and attackers grab exposed keys within about five minutes. The fix is a tiny file called .env: a private notepad for your keys that stays separate from your code. Here is the prompt I actually paste. It does a full sweep instead of one key at a time, and it sets the habit so nothing slips through later:
Prompt — Set Up .env (Full Sweep)Copy
Set up a .env file for this project the right way and pressure-test it from every angle. First, scan my entire codebase for any secret that is sitting in plain text: API keys, access tokens, passwords, database URLs, connection strings, webhook secrets, anything sensitive. For each one you find, create a .env file if one does not exist yet, move that secret into it as NAME=value on its own line with a clear name, and replace the hardcoded value in my code with a reference to that environment variable so everything still runs exactly as before. Then create a .env.example file with the same variable names but blank or placeholder values, so I can share or push the project without exposing a single real secret. Make sure .env is listed in my .gitignore, and create a .gitignore if I do not have one. Next, check my git history to see whether any of these secrets were already committed at some point. If they were, tell me exactly which ones and which file, and remind me to rotate that key at the source, because adding .env now does not un-leak anything that is already public. Most important, treat this as a standing rule from here on: every single time I connect a new tool, API, database, or service, or paste in any new key or token, automatically move it straight into .env and reference it from there instead of hardcoding it, and never let a secret get committed. When you are finished, confirm the app still runs and give me a short summary of every secret you moved and anything I still need to rotate.
Here is what it is doing under the hood:
1. Sweeps your whole project
It hunts down every secret hiding in your code, not just the one key you were thinking about. Keys, tokens, passwords, database URLs, all of it.
2. Moves each one into .env
A plain file that holds every secret as NAME=value, one per line, and your code calls each key by name so everything still works.
3. Adds .env to .gitignore
This is the part that actually protects you. It tells Git to never upload that file anywhere public.
4. Creates a .env.example
A safe copy with the names but no real values, so you can still share or push your project without leaking anything.
5. Sets the habit going forward
From now on, every new tool or key you connect gets moved into .env automatically. You never have to remember to do it again.
One Gotcha
If a key already got pushed to GitHub, a .env file won't un-leak it. The prompt checks your git history and flags it, but you still have to go to that service and rotate the key yourself.
Tip 3Set Guardrails Before You Connect A Tool
Connecting a tool to Claude does not just let it read, it lets it act: send, delete, share. So I set guardrails first. For my email, the rules are simple: it can only ever draft, never actually send, and it can never delete anything.
The tricky part is a brand new tool, because you often have no idea what the guardrails should even be. So I drop in this prompt to figure out the right limits before I connect it:
Prompt — Build The GuardrailsCopy
I'm about to connect [tool name] to you. Before I do, help me set up the right guardrails. First, tell me everything you'll be able to do once connected, especially anything that sends, deletes, shares, edits, or spends money, so I understand the real risks. Then recommend a set of hard rules for what you should and shouldn't be allowed to do with this tool, always defaulting to the safest option, like drafting instead of sending and never deleting. Also warn me if this tool could carry hidden instructions from other people, like emails or shared docs, that might try to make you take actions I didn't ask for. Give me the final guardrails as a clear list I can save.