How I Secure My MCP Connections

I’ve had good and bad runs with MCP. Some connections saved me hours. Others made me nervous. Wrong account, too much reach, setup I couldn’t explain a week later. I learned the hard way that MCP is not plug-and-play. It takes thought, especially if you work across projects and clients and you want to be careful about what the agent can see and do.

This is how I’m setting things up now. Still a work in progress. I’m not claiming a finished playbook. But the direction is clear enough to write down.

For what’s wired on my bench today, see Stephan’s MCP workbench. This page is the setup story. Why I stopped sharing MCP globally, how I track it in git, and how I wire keys without browser sign-in roulette.

One stack per project.

Cursor would happily put MCP at the root of your laptop user folder. One connection file for every project you open. Fine for a single repo forever. Bad for how I actually work.

I stopped using global shared MCPs a while ago. Each project gets its own config in that folder, not a laptop-wide setup that follows me everywhere. When I open Client A, I get Client A’s stack. Client B is a different folder, different keys, different rules.

I also write down what MCP can and can’t do in that project. Usually in Cursor rules, sometimes in comments in the config file and in a checked-in example env file. What can it read? What should it never write? Which connection answers which kind of question. The agent is powerful. I don’t want it guessing where the fence is.

One rule I enforce for myself: I don’t let Cursor AI edit the MCP config folder. If I add a server or change a script, I do it. Or I paste what the agent suggests and commit it myself. That folder is setup, not draft copy. When I edit MCP through Cursor’s UI, the changes land locally in the project. That’s the point.

Because of that, I can track the config file, the small shell scripts, and an example env file in git. The live env file with real keys stays out of the repo. I can see when I split Sentry by app, when I scoped Cloudflare to one account, when I removed something that felt too broad. That history mattered after the bad runs.

Why three files, not one.

The MCP servers I use don’t read env files on their own. So I couldn’t just drop keys next to the config and call it done. I needed a thin bridge.

The pattern that stuck is three parts. The config file holds wiring only, no secrets, safe to commit. A project-level env file holds keys scoped to that folder. One small shell script per connection loads the env file, passes the token, and starts the server.

Without that script you’re pasting secrets into JSON or leaning on browser sign-in. Both of those blurred clients for me.

I see three variations on my benches, same idea, different vendors. Sometimes one generic script loads the env file and runs whatever the server needs. Sometimes the script reads a key and hands it to a remote connector. Cloudflare and GitHub work that way for me. Sometimes one script serves multiple connection names in the same org, split by app, so each name documents what it’s allowed to touch.

When someone copies the pattern, they copy the wiring and build a fresh env file. They create tokens manually, same as any new project. I keep an example env file in git with notes on where to get each key and when it expires. Even if the same token could work in two places, I want a separate variable per connection so the mapping is obvious.

Scoped tokens, not browser sign-in.

This is the piece I’m most opinionated about. Still refining.

Maybe it’s just me, but I get confused. When a provider only offers browser sign-in, no API key or access token I can name and limit, I generally don’t let it into my config. I don’t want to be always checking that my MCP is talking to the right account. Browser login makes that harder, not easier. Across clients I lose the thread fast.

A good MCP, once configured, slides into the background. I use it. I trust it. I might not think about security again for months. That’s why getting the setup solid on day one matters to me. Read-only or narrowly scoped tokens, spelled out in the example env file, wired through a script I can read six months later. I’d rather create that token up front and know exactly what it can touch than wonder which org Cursor signed into last Tuesday.

Most vendors let you set up access tokens with specific permissions. Cloudflare does a great job here. You can choose read, write, or both at almost every layer. That means you can narrow what your MCP can damage. Read on almost everything, write on only the few things you’d ever want an agent touching. I bias hard toward read.

When the model wants to change something anyway, I don’t ask it to improvise. I tell it to hand me a direct link into the admin page. The exact screen, the exact record. Cloudflare, Supabase, Sentry, most dashboards have a linkable URL. Same pattern as my workbench map. The agent investigates with read tokens. I make the change in the UI with a link dropped in chat. Awesome when it works.

Example: I ask to add a subdomain for my Cloudflare R2 bucket, my CDN. The MCP finds the right buckets and gives me a Cloudflare link to do it manually.

I’m not saying browser sign-in is wrong everywhere. I’m saying it was the wrong default for my multi-project setup, for someone who stops thinking about the connection once it works. Explicit tokens, per-project env files, one script per connection. Slower upfront, clearer later. Some connections are still on my live bench while I figure out if they meet the bar. The map shows reality. This page shows the standard I’m moving toward.

Still figuring it out.

The good MCP runs convinced me the pattern is worth the discipline. The bad ones convinced me not to rush.

Want to see what’s actually wired? Stephan’s MCP workbench is my current stack breakdown. What’s connected, what each server is for, and playbook links where reviews exist. This page is how I secure that setup. One project folder, wiring in git, keys you can name, and the agent stays out of the MCP config folder.

If you’re wiring your own bench and want a second pair of eyes, book a Tech Stack Clarity Check (15 min).