Safety & Permissions When Claude Touches Live Tools

The Lesson That Matters Most

The previous three lessons handed you a lot of power. This one teaches you to wield it without getting hurt.

Here's the uncomfortable truth: MCP lets Claude take real actions on real systems. Most of the time that's wonderful. But the same connection that lets Claude create a GitHub issue can let it close one. The same database connection that reads your users can, if you set it up that way, delete them. Claude is careful and asks permission — but you are the final safety check, and you can only be a good one if you understand what's happening.

Good news: the safety mindset is simple. It's mostly about asking one question before you connect or approve anything — what's the worst this could do?

---

How Permission Prompts Work

By default, the first time Claude wants to use a tool, it stops and asks you. You'll see something like a prompt naming the tool (remember the mcp__server__tool format from Lesson 1) and what it's about to do. You get to choose:

• Allow — let it proceed this once.
• Allow and don't ask again — trust this tool going forward (use sparingly, and only for safe ones).
• Deny — refuse, and optionally tell Claude why so it tries something else.

This prompt is not a nuisance. It's a seatbelt. Read what the tool is about to do before you click. Especially for anything that writes or deletes.

A simple rule of thumb:

• For read-only actions (list issues, query data, fetch a page), allowing is low-risk.
• For write or delete actions (create, update, insert, remove), slow down and actually read the summary.

---

Read-Only vs. Write Servers: Choose at the Door

The single most effective safety move happens before Claude ever runs — at the moment you connect a server. Many tools let you connect with read-only access.

If you only need Claude to look at your production database, connect it with a read-only credential. Then it's physically impossible for Claude (or you, in a careless moment) to change or delete anything. The capability simply isn't there.

For example, a database connection string can use a read-only user:

claude mcp add --transport stdio db -- npx -y some-db-mcp-server \
  --connection "postgresql://readonly_user:pass@host:5432/mydb"

The readonly_user here is a database account that can only SELECT, never DELETE or UPDATE. This is the gold standard: don't grant write access you don't need.

Think of it like giving someone a key to your house. You could give them a key that also opens the safe — but if they only need to water the plants, give them the key that just opens the front door.

---

The Blast-Radius Mindset

Before connecting any server, picture the worst-case outcome. Security people call this the blast radius — if something went completely wrong, how big is the crater?

Ask yourself:

• What can this server reach? One repo, or my entire GitHub account?
• Can it only read, or can it also write and delete?
• Is this pointing at a throwaway test project, or at the live thing my customers use?
• If Claude misunderstood me and did the most destructive thing this tool allows, what would I lose?

The goal isn't paranoia — it's matching the access to the need. A read-only connection to a test database has a tiny blast radius. A full-write connection to your production customer database has an enormous one.

---

Scope Your Connections Deliberately

Remember the --scope flag from Lesson 2 (local, user, project)? Scope is a safety tool, not just a convenience.

• Keep risky or experimental servers at --scope local so they're confined to one project and only available to you.
• Be especially careful with --scope project, because it writes to .mcp.json and everyone who clones the repo inherits that connection. Don't push a powerful write-access server to a shared repo without the team agreeing to it.

Narrow scope = smaller blast radius. When in doubt, start local.

---

Handling Secrets the Right Way

MCP servers often need a secret to authenticate — an API token, a database password. How you store these matters enormously, because a leaked secret can hand your accounts to a stranger.

The rules:

That second row is worth repeating: .mcp.json gets committed to your repository. A secret in there is a secret published to anyone who can see the repo. Always use the ${VARIABLE} reference instead, so each person supplies their own secret from their own environment.

---

The Production Rule

If you remember one sentence from this entire module, make it this one:

Never connect casual write access to a production system.

"Production" means the live thing real people depend on — your real customer database, your real payment records, your live website's content. The convenience of letting Claude edit production directly is never worth the risk of a misunderstanding wiping real data.

When you need to work against production, prefer one of these instead:

• Connect read-only, so Claude can investigate but not change anything.
• Work against a copy or test environment first, then apply changes through your normal, reviewed process.
• If you must allow a write, do it for one specific action, read the permission prompt carefully, approve that one action, and don't enable "don't ask again."

---

A Quick Pre-Flight Checklist

Before you connect a new server, run through this:

1. Is this the official server from the tool's own docs? (Don't trust random ones with your accounts.)
2. Does it need write access, or would read-only do? Default to read-only.
3. What's the blast radius if it goes wrong?
4. Is the scope as narrow as it can be (local unless there's a reason)?
5. Are my secrets in environment variables, not committed files?

Five questions, thirty seconds. They'll save you from the rare-but-painful bad day.

---

Summary

• Claude asks permission before using a tool — treat the prompt as a seatbelt and actually read it, especially for writes and deletes.
• Connect servers read-only whenever you only need to look; the safest action is one the tool can't take.
• Use the blast-radius mindset: before connecting, picture the worst case and match access to need.
• Scope deliberately — keep risky servers local; be cautious with project scope since it's shared via .mcp.json.
• Protect secrets: use OAuth or environment variables, give minimal permissions, never commit real tokens.
• Never connect casual write access to production. Use read-only or a copy instead.