What jumped out at me wasn’t the “22 security layers” pitch. It was the tension between that pitch and the actual engineering constraints they chose to obsess over. Zero external Go dependencies is a very clean story. Vendoring ONNX Runtime binaries and a model blob so you can keep the air-gapped clone guarantee is, in its own way, honest. That part at least feels like a real tradeoff, not marketing fog.
The rest makes me squint a bit.
A lot of security language in LLM land has started to sound like cargo cult architecture: regex scans, ATLAS mapping, compliance checks, neural prompt-injection detection, tool-poisoning detection, RBAC, response scanning, audit logging. Some of that is sensible. Some of it is basically “we put a detector in front of the scary thing.” I’d want to know how often the layers actually catch something meaningful, what they miss, and how noisy they are in practice. The post doesn’t answer that, and I don’t think the number 22 tells me much on its own.
The most believable part is also the least glamorous: using plain mutex-protected session state, 404s for invalid sessions, and build-time toggles instead of runtime cleverness. That is the sort of boring design I trust more than a grand security stack. The article seems proud of avoiding background goroutines, avoiding network fetches, avoiding transitive dependencies. Fair. Those are concrete choices with concrete benefits.
But “zero-dependency” here is a bit slippery. If you vendor a 28MB shared library and a model file, the dependency hasn’t gone away. It has just moved into your repo. That may still be the right move for an offline deployment story, but calling it zero-dependency is more of a boundary decision than a literal statement about the system. Same with “no external Go module dependencies”: true, apparently, but only if you ignore the much heavier non-Go pieces sitting beside the source tree.
I also keep thinking about the ML angle. A CharCNN-BiLSTM for adversarial prompt injection detection sounds like a 2023-era answer to a 2025 problem. Maybe it works well enough on the author’s threat set; perhaps it’s mainly there to catch obvious garbage before the policy engine runs. But prompt injection is messy, adaptive, and often contextual. A local classifier can help, sure, yet “neural net at the gate” can easily become a false sense of safety if it isn’t paired with strict tool permissions and careful prompt design. The post seems aware of that to a degree, but I’d still like to see failure cases instead of architecture diagrams.
What I do like is that the piece treats the MCP transport details as part of the security story rather than an afterthought. Session IDs, idle expiry, 404 vs 401, SSE negotiation, the request/response lifecycle — that’s all the stuff people forget when they jump straight to “agent security.” In practice, the transport and session layer are where a lot of sloppy implementations go wrong. If you’re building Claude-connected tooling, that’s the layer to get boring and predictable first.
The article’s bigger weakness is that it leans hard on taxonomy and not hard enough on evidence. A “22-layer” stack sounds impressive until you ask which layers are independent, which are overlapping, which are just renamed variants of the same control, and which are effective against real attacks versus theoretical ones. I’d be much more persuaded by a few examples: one malicious tool definition blocked, one prompt-injection attempt caught, one false positive that mattered, one case where the heuristic-only mode failed and CGO mode helped. Without that, the number is just a number.
Still, I’d rather see this kind of uncomfortable overengineering than another vague “AI safety” post that never touches the transport, storage, or build chain. The source is at its strongest when it’s talking about the dull bits: how to keep a server clonable offline, how to keep sessions from lingering, how to make the protocol behavior explicit. That’s the sort of work that actually survives contact with production.
Reference: Building a Zero-Dependency MCP Server with 22 Security Layers in Go
