A few days ago I was working on something completely unrelated when I noticed an old injection-test MCP server sitting in one of my .mcp.json files.

I had completely forgotten about it.

It wasn't doing anything bad. I had added it months ago while testing something and apparently never bothered removing it. Normally I'd just delete the line and move on.

This time I stopped for a second.

I use Claude Code pretty much every day. It has access to most of the projects I'm actively working on — including some of the studio stuff for YILK GAMES, my portfolio, and various automation scripts. I've also got a handful of MCP servers connected to it. One for Unity, one for TouchDesigner, GitHub, and a few smaller tools I've written myself.

They can read files. Some of them can modify things. Some can run commands. Some can interact with services.

And I realized something slightly uncomfortable:

I don't actually know what I've given them access to anymore.

That's probably a problem.

Turns out I'm exactly the person these security papers are talking about

I've been reading more about AI agent security recently, and the funny thing is that most of the examples don't feel like some distant enterprise problem.

They sound like my setup.

There's a lot of discussion around things like least agency — basically, an agent shouldn't have more permissions than it needs to complete the task.

My approach so far has been considerably less sophisticated:

If it works, don't touch it.

That's fine until the thing doing the work isn't just a script anymore, but an AI agent that can decide what to do next.

That's when permissions start to matter a lot more.

That stupid config file got me thinking

My first reaction to the forgotten MCP server was basically "I'll clean this up later."

Then I started thinking about everything else I've probably left lying around.

Old environment variables. Test scripts. Credentials in places they shouldn't be. MCP servers I installed for a one-off experiment. Dependencies I haven't looked at in months.

None of those things necessarily need to be malicious to become a problem.

If an agent can access them, they're part of the environment the agent can potentially reason about and use.

And that's the part I hadn't really thought about before.

The security problem isn't necessarily an AI deciding to attack you.

It can be much more boring than that.

You give it a goal. It hits a roadblock. It looks around for another way to accomplish the goal. And if you've accidentally given it access to something useful, it may use it.

That changes how I think about my development environment.

So I'm going to test my own setup

I'm not particularly interested in writing another generic "AI security is important" post.

I'd rather find out what I have actually exposed.

So that's what this series is going to be about.

I'm going to go through my own setup, figure out exactly what my MCP servers expose, look at what an agent can actually access, and then try to break things deliberately.

The plan for the next posts:

  • Part 2 — The four big threats: prompt injection, excessive agency, jailbreaks, and the AI supply chain.
  • Part 3 — MCP Security 101: what the security model actually looks like and where the dangerous assumptions are.
  • Part 4 — Auditing my own setup: finding out what Claude Code and my MCP servers can actually touch.
  • Part 5 — Fixing it: permissions, isolation, secrets, and some basic guardrails.

I have a feeling this is going to uncover more than a few things I'd rather not have left lying around.