AI Safety Series

The AI
Safety Playbook

A running list of my top AI safety tips, all in one place. How to set your Claude connector permissions, 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.

Start with the connectors section below. It is the one that applies to almost everybody, and it takes about a minute per tool.

Start Here Set Your Claude Connector Permissions

You are probably giving Claude more permission than you realize. Most people connect it to Gmail, Google Drive, or Slack and never check what they just handed over. I did the exact same thing at first.

The part people miss is that a connector does not just read your stuff. It can act. It can send, delete, move, and change things for you. That is what makes it so useful, and it is exactly why you want to decide the rules up front instead of finding out later.

The good news is Claude does not make this all or nothing. You get to set exactly what each connection is allowed to do, action by action. You just have to go do it, and almost nobody does.

Level 1

Always Allow

Claude never asks, it just does it. Use this for the safe everyday things you do not want to babysit, like reading a file or searching your inbox. Nothing here can cause damage, so getting out of the way is fine.

Level 2

Ask Every Time

Claude checks with you before it acts, every single time. You see exactly what it wants to do and you say yes or no. Use this for anything that changes, sends, or shares. It adds one click, and that click is worth it.

Level 3

Always Block

Claude can never do that action, full stop. Use this for things you never want an AI touching on its own, like deleting files or spending money. If it is off the table for you, put it fully off the table.

Here is how I actually set mine, so you can see the pattern. I let Claude do the safe half of a job freely, and I keep my hand on the part that cannot be undone.

My Real Settings

Read my Google Drive: always allow. Reading changes nothing.
Delete files: always block. No reason an AI needs to erase my work on its own.
Draft emails: always allow. A draft just sits there until I look at it.
Send emails: ask every time. Sending is the part you cannot take back.

To set it up: open your connector settings in Claude, click into the specific connector you want to adjust like Gmail or Google Drive, then set each permission one by one to Always Allow, Ask Every Time, or Always Block. That is the whole thing, about a minute per tool.

Do this the moment you connect a tool, before you let Claude start working. A new connector should not go live until you have told it what it may and may not touch.

Not Sure What The Rules Should Be

If it is a brand new tool and you have no idea what to allow, skip down to Tip 3 below. There is a prompt there that has Claude tell you everything it will be able to do once connected, then recommend the guardrails for you before you turn it on.

Tip 1 Vet 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 Check
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 2 Never 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)
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 3 Set 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 Guardrails
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.

© 2026 Mariah Brunner. All rights reserved.