We turned AI SAFE² v3.0 inward on our own MCP server. We avoided the catastrophic failures, but “better than broken” is not the same as secure.
At a glance:
- What happened: We audited our own MCP server under AI SAFE² v3.0. No catastrophic failures, but three design-level findings about how execution actually flows.
- What it exposes: Inspection and monitoring observe; they do not stop execution. The risk is in the architecture, not a patchable bug.
- What to examine: Where execution actually gets stopped in your MCP deployment. Not logged. Stopped.
Key quote: “A protocol doing exactly what it was designed to do… and exposing everything because of it.”
In plain language
MCP is the popular standard that lets AI assistants use external tools, like giving your AI helper a set of power tools for your computer. Security researchers have been finding ways those tools can be abused.
Instead of writing about someone else’s problem, we turned the assessment inward and audited our own MCP server the way an attacker would. The good news: no catastrophic failures. The uncomfortable news: we found three design weaknesses, the kind that cannot be fixed with a patch because they are how the system is built.
The bottom line: the risk is in the architecture, not a patchable bug. “Better than broken” is not the same as secure.
The key facts
| What | Self-audit of Cyber Strategy Institute’s own MCP server |
|---|---|
| Framework | AI SAFE² v3.0 assessment, attacker’s-eye view |
| Scope | 72-hour deep assessment of our own deployment |
| Catastrophic failures | None found. No dynamic command execution, no subprocess exposure, no direct STDIO RCE path. |
| Findings | Three design-level findings about how execution actually flows |
| Status | Remediation in progress; MCP formalized as a first-class attack surface (CP.5.MCP) |
The problem wasn’t a vulnerability. It was the design.
Over the past 72 hours, I went deep into the MCP supply chain issue, not as an outside observer reading someone else’s advisory, but from inside the system. Our system. I turned the assessment inward, onto the MCP server our own team operates, and looked at it the way an attacker would.
What I found wasn’t a bug. Bugs get patched, disclosed, and closed. What I found was something much more uncomfortable: a protocol doing exactly what it was designed to do, and exposing everything because of it.
Before you read further, ask yourself the question I had to ask myself: if your own MCP deployment were audited tomorrow, would the findings be vulnerabilities you could fix, or design decisions you’d have to live with?
Auditing an MCP server reveals cracked design blueprints. Illustrative artwork, not a vendor schematic.
MCP Has Already Won
Key quote: “It solved the integration problem. But in doing so, it quietly removed something critical: the execution boundary.”
MCP has already won. The numbers stopped being interesting a while ago, 150M+ downloads, 200,000+ servers, but the velocity behind them should still get your attention. MCP embedded itself into IDEs, agents, and workflows at a pace most security teams can’t even map, let alone govern.
It solved the integration problem. That is a genuine achievement, and it’s why adoption was never really a choice. But in doing so, it quietly removed something critical: the execution boundary.
Here’s the part worth sitting with. When was the last time your security team produced a complete map of every MCP server touching your workflows, not the approved ones, the actual ones? If you can’t answer that quickly, you’re already behind the protocol’s adoption curve, and the gap is widening every week.
The OX Security Confirmation
Key quote: “No exploit chain. No sophisticated bypass. Just… design.”
The OX Security research confirmed what many in the industry had been dismissing as theoretical. The mechanics are almost insultingly simple: user-controlled input flows into command construction, and that construction is executed at the OS layer. No exploit chain. No sophisticated bypass. Just… design.
And when the protocol owner says “this is secure by default,” it’s worth translating what that actually means in practice: you own the consequences. The default was designed for adoption velocity, not for your threat model. If the protocol’s own vendor calls it secure by default, who do you think absorbs the cost when “by default” meets your production environment?
Untrusted tool output flows into OS process execution with no validation gate. Conceptual diagram of the MCP design pattern.
Our Own Audit: Three Findings
Key quote: “But ‘better than broken’ is not the same as secure.”
So I turned inward and assessed our own MCP server under AI SAFE² v3.0, applying the same rigor we’d apply to a client’s environment. Here’s the uncomfortable truth: we avoided the catastrophic failures. No dynamic command execution. No subprocess exposure. No direct STDIO RCE path. That alone puts us ahead of most of an ecosystem that has already been exploited.
But “better than broken” is not the same as secure. Three things stood out, and I’m sharing them because every one of them is a decision your team has probably made too, whether you realized it or not:
| Finding | What it means | Why it matters |
|---|---|---|
| We trust our own output too much | If our control dataset is ever poisoned, we could unknowingly deliver prompt injection directly into an LLM client. | Trusting your own pipeline is still trusting a pipeline. |
| STDIO assumes trust where none exists | Local execution paths are treated as safe by default. | Local does not mean safe, especially with zero-click IDE execution. “Local” is just a word for “already inside.” |
| Rate limiting depends on the environment | Protections live in the proxy layer and vanish if the proxy is removed. | A control that only exists in one deployment topology isn’t a control; it’s a configuration accident. |
None of these are theoretical. They are exactly how supply chains get weaponized, not through exotic zero-days, but through trusted assumptions that nobody re-examined.
Monitoring, inspection, and design: what each observes versus what stops execution. Observed in our own environment; your deployment will differ.
You Cannot Inspect Your Way Out of an Execution Problem
Key quote: “You cannot inspect your way out of an execution problem.”
Here’s the part most enterprises miss. The standard response to all of this is more inspection: prompt filters, behavioral monitoring, another “AI safety” layer watching the traffic go by. It’s an understandable instinct, visibility feels like control.
It fails for one reason: you cannot inspect your way out of an execution problem. Observation tells you what happened. It does not stop it from happening. A monitoring dashboard can show you, in beautiful real-time detail, exactly how your system was compromised. That is not security; that is journalism.
Ask the question your detection vendor doesn’t want you to ask: your monitoring caught the incident in forty seconds. How much damage fits inside forty seconds of OS-level execution?
Stop Trusting Behavior. Start Enforcing State.
Key quote: “We stop trusting behavior. We start enforcing state.”
The shift we’re making, starting this weekend, is simple, but it’s non-negotiable:
- Every tool output gets sanitized before it ever reaches a model. Not monitored. Sanitized. The boundary sits before the model, not after the damage.
- STDIO execution gets identity-bound, not assumed. Every execution carries a verifiable identity, because “local” is not an identity.
- Rate limits move into the application layer, not the edge. Protections that disappear when you remove a proxy were never protections.
And more importantly, we’re formalizing MCP as a first-class attack surface inside AI SAFE², CP.5.MCP. Because pretending this is “just another integration layer” is how you lose control of your system one trusted assumption at a time.
From trusting behavior to enforcing state. Proposed direction. Implementation in progress.
The Broader Lesson
Key quote: “Which leaves one entity holding the risk: the enterprise.”
This is the broader lesson, and it extends well beyond MCP. Protocol vendors will optimize for adoption, they have to; that’s their business model. Developers will optimize for speed, they always do; that’s their job. Which leaves one entity holding the risk: the enterprise.
If your teams are already connecting MCP servers into agents, IDEs, or pipelines, and they are, you need to answer one question honestly:
Where does execution actually get stopped?
Not observed. Not logged. Not flagged after the fact. Stopped.
Because if you don’t have a deterministic boundary, you don’t have a system. You have exposure.
Intelligence can be rented. Execution sovereignty cannot.
We’re implementing the cage. The only question is, do you already have one?
What to Do Next
1. Inspect. Inventory every MCP server touching your workflows (not just the approved ones) and note what each one is allowed to execute.
2. Test. Send a crafted tool output through your pipeline and verify whether sanitization happens before the model sees it.
3. Decide. Move one protection (for example, rate limiting) into the application layer so it survives proxy removal; document what remains environment-dependent.
Find Your Exposure First
Free AI governance assessment, instant score, no sales call required.