Yesterday I did something that is not very modern of me: I counted. Not the tokens, not the models, not the agent sessions. I counted the servers that hold my credentials and can execute actions on my behalf. Then I counted how many of them can write, delete, or run code. The answer was uncomfortable, and I have nobody to blame but myself.
The trigger was a number I read that same morning: someone scored 675 published MCP servers on fifteen structural security signals. Read-only mode, authentication, tool risk, maintenance, provenance. The result: 89.3% landed in the “high risk” band. Only 0.9% scored “safe”.
My first reaction was: that is about other people’s servers, not mine. My second reaction, ten seconds later, was: what would my own row look like on that spreadsheet?
The three numbers that did it
Three of the findings stayed with me because they describe things I can check on my own machine, today, without installing anything.
92.1% of the servers had no read-only mode. I always assumed read-only was a feature you add later. It turns out almost nobody adds it at all. And in my own setup, the servers I trust most are exactly the ones with the widest write access. Trust and scope have grown together, unchallenged.
Only 14.7% supported OAuth. The rest use static keys. Mine use static keys — keys in plain config, copied between machines, some of them older than the projects they authenticate.
35.9% exposed at least one dangerous tool — code execution, file deletion, data writing. And 43.1% of those combined it with no read-only escape hatch. That is the worst possible combination: maximum capability, no way to scale it back per task.
The part that actually worried me
The researchers made one argument I could not wave away: to abuse an MCP server, an attacker does not need to exploit a bug in it. The assistant does not have to be broken. It only has to be persuaded — by a web page it reads, a document it processes, an email it summarises.
That is what they call the lethal trifecta, and I have all three legs of it in one pipeline. My agent reads untrusted content from the outside world. It has access to private data — my notes, my project files, my family archive. And it has tools that can communicate outward and write files. Private data, untrusted content, and outbound action, in the same process, on the same turn.
I have spent months hardening the outside of my setup. The parts I had never inspected were the ones the agent calls with my blessing, every single day.
What I am doing about it
I turned the findings into a three-question checklist and I am walking it server by server: does this server need read-only mode for the way I actually use it, how does it authenticate, and which of its tools are genuinely dangerous? That is it. No new tooling, no new framework — just a scorecard applied to what is already running.
The first honest answer I wrote down: several servers are authenticated with keys that have never been rotated, and at least one of them could be replaced by a read-only variant with no loss of function for anything I do.
The uncomfortable lesson
I audit what I am worried about. That is precisely why the audit is incomplete — the things I am not worried about are the things I never look at. The uncomfortable part is not that my setup is risky. It is that the risk lives exactly where I had stopped looking, because I had decided long ago that this part was fine.
So here is the question I want to leave you with, and I am genuinely curious about the answers: how many servers are currently connected to your agent, and for how many of them can you actually name the tools they expose? If you had to write that list down right now, without opening your config — how far would you get?
Wat vond je van dit bericht?
