‘How-to secure MCP servers’ is wronger than wrong.
I've been accused — fairly, and more than once — of being very good at telling people they're wrong, and conspicuously bad at telling them how to do things correctly.
If I'm so willing to confidently spout off, the critique goes, why don't I publish the how-to? Why don't I write the checklist? Why don't I give people the secure MCP deployment pattern they keep asking for?
The uncomfortable answer is: because doing that would make me wrong.
Not rhetorically wrong. Substantively wrong.
My recent article claiming MCP servers are not infrastructure, they are contracts delegating authority, triggered some of that pushback when I shared it on my socials.
The how-to everyone expects
If I wanted to, I could have written the prescriptive version. It would look something like:
- Define authority explicitly
- Specify constraints formally
- Implement audit trails
- Establish rollback procedures
- Challenge the necessity of each capability
It would read cleanly. It would circulate. It would become Enterprise MCP Deployment Checklist v2.0.
And it would be wrong.
Because what people would execute are the steps, not the thinking.
Why prescription fails here
Infrastructure culture is optimized for prescription. Runbooks, SOPs, SOC 2, ISO 27001, PCI-DSS, HIPAA, FERPA, NIST 800-53 controls, FedRAMP baselines, DoD contracting checklists, and the endless parade of compliance attestations that turn judgment into artifacts.
It wants patterns:
- "Use this auth scheme"
- "Deploy it this way"
- "Implement these controls"
- "Follow this reference architecture"
That instinct makes sense when the problem is mechanical.
Agents using MCP is not a mechanical problem.
If I say "stop treating MCP as infrastructure," and then hand you infrastructure patterns I've contradicted myself in the same breath. I've given you something you can operationalize instead of understanding what you are actually delegating.
That's the exact displacement I'm arguing against.
The questions are the method
The core of the MCP piece was never the conclusions. It was the questions:
- What authority are we granting?
- To whom?
- Under what constraints?
- With what rollback, logging, and accountability?
- Should an agent be able to do this at all?
These aren't rhetorical questions or discussion prompts. They are irreducible. Foundational. Ontological bedrock.
They exist at the layer below implementation and above policy. You cannot answer them by pattern-matching, and you cannot outsource them to a framework, a checklist, a control set, or a blog post. Any attempt to do so is an attempt to evade responsibility by abstraction.
There is no portable answer to "what authority are we granting," because authority is not a technical property — it is a situational one. The correct answer depends, unavoidably, on the specific shape of your environment: what your organization actually does in the world, the regulatory regimes it is subject to, the risks it is willing and legally able to absorb, its capacity to detect, respond to, and recover from failure, and on the expectations users reasonably place on it.
A "best practice" that ignores those variables is not incomplete. It is false. It replaces understanding with ritual, and responsibility with compliance theater.
The absence IS the point
People notice what isn't in the article.
There is no best-practices section. No reference implementation. No sample secure MCP server. No recommended stack. No blessed architecture diagram.
That omission wasn't an oversight. It was the design.
Prescriptive checklists exist to externalize judgment. They let you move responsibility out of your head and into a document. You can point at them in reviews, wave them around in audits, and tell yourself you've done the thinking because you've followed the steps. That works when the domain is stable and the risks are well understood. It fails completely when the core problem is deciding what should be allowed to happen at all.
In domains like MCP, judgment is the work. The dangerous mistake is believing you can decompose judgment into a finite sequence of actions and then delegate it to a checklist. You cannot. The list will be executed faithfully, and the system will still be wrong in ways no list can anticipate.
The moment I give you my answers, I allow you to skip generating your own. I turn a requirement for contextual understanding into cargo cult. You stop asking what authority you are delegating and start asking whether you've implemented the pattern correctly. Responsibility doesn't disappear — it just becomes harder to see.
The questions force understanding because they cannot be satisfied mechanically. They require you to reason about power, risk, and consequence in your specific environment. Prescription would bypass that reasoning entirely. And bypassing it is exactly how teams end up with systems that behave correctly, pass audits, and still cause harm.
What I actually wrote
I didn't write a security guide.
I wrote a conceptual reorientation disguised as one.
The goal wasn't to tell you what to build. It was to change what you see when you look at MCP. If it works, you'll still build infrastructure. You'll still deploy clusters, configure auth, and ship tools. But you'll do it after answering the authority questions — not instead of them.
Your Kubernetes cluster becomes the implementation of a contract, not a substitute for thinking about one.
Why that makes people uncomfortable
How-tos and checklists and frameworks are comforting. They imply someone else has already figured this out. They feel like they reduce risk. What I'm saying is more unsettling:
No one can answer these questions for you. And if you don't answer them, the system will still behave correctly — just not safely.
You aren't mitigating risk merely by following regulatory prescriptions, legal mandates, and implementing an 'official' best practice. You are delegating judgement — the one thing you should always reserve for the humans in the loop.
Closing thought
I don't avoid how-tos because I lack opinions. I avoid them when they would do harm. MCP doesn't need another checklist, it needs people willing to sit with uncertainty long enough to understand the authority they're about to delegate.
That's not something I can provide.
It's something you have to do.