Eight MCP Servers, No Map, and Forty Minutes Until the CISO Meeting

Tomasz "TK" Kowalski is a platform engineer at a mid-size London fintech that builds regulatory reporting tools for other financial companies. Over the past twelve months, his three-person team deployed eight MCP tool servers across their agent infrastructure. One of those engineers has since left. Two weeks ago, TK's CISO forwarded the NSA's May 2026 advisory on MCP security with a two-word subject line: "we need to talk."

We spoke with TK — or rather, with the composite character he represents — over a video call he took from a meeting room his colleagues have started calling "the confessional." He is not a real person, but the technical situation he describes is assembled entirely from documented vulnerabilities, published advisories, and industry data. Every number is real. Only TK is invented.¹

The CISO's email lands. What's the first thing you actually do?

TK: I read the advisory. All of it. Which, credit to the NSA, is not a long read. Then I open a blank doc and try to write down what we have. Eight MCP servers. I built three. Priya built three. Amir built two before he left in February. And I'm sitting there staring at this doc and I realize I can't finish the list. I know my three. I mostly know Priya's. Amir's two... I know they exist. I know roughly what they do. I do not know what credentials they're running on, what permissions those credentials have, or where the API keys live.

So the first thing I actually do is feel a very specific kind of dread.

How do you not know what's in your own infrastructure?

TK: Because nobody sets out to build an ungovernable system. You download a reference server, wire up a Zod schema, connect it to whatever internal system it needs to talk to, hand it an API key, and it works. There's no central registry. No approval workflow. The MCP spec doesn't define standard audit logs.² Each server is its own little kingdom. We have eight kingdoms and no cartographer.

Strata Identity has this description I keep coming back to: a developer downloads an MCP server, runs it locally, authorizes it with a personal access token, and starts using it. Then another developer does the same thing. Before you know it, you have hundreds of servers with no governance.³ We have eight. That's the controlled version of the problem, and it's still enough to ruin my week.

The advisory specifically flags STDIO transport. All eight of yours use STDIO?

TK: Yeah.

That's a one-word answer about a critical vulnerability.

TK: Because there's nothing complicated about it. STDIO means the client launches the server as a subprocess. Reads from stdin, writes to stdout.⁴ It's the architecture of a local developer tool. We put it in production because it was the default and it worked. Now the OX Security advisory calls STDIO command injection "severity critical, exploitability easy, prevalence universal."⁵ The official MCP SDK executes the configured launch command without sanitizing user input. The command runs even when server startup fails. No warnings. Nothing in the toolchain raises a flag.

And here's what made me actually put my head on the desk: Anthropic confirmed this is expected behavior. Sanitization is the developer's responsibility.⁶

There is no patch. There is no update I can pull. I have to audit each server's implementation individually to check whether the engineers who built them, including one who no longer works here, handled input sanitization in their custom code. Eight servers. Twelve months of independent development. Good luck.

Tell me about the Amir problem.

TK: Amir left in February. Standard offboarding. HR deactivated his accounts, IT revoked his SSO, badge stopped working. Clean process. Beautiful process. Except MCP servers running on static API keys are invisible to that process. OWASP calls this "improper offboarding," literally their number-one non-human identity risk.⁷ The human identity gets deprovisioned. The machine credentials the human created keep running.

Sixty-eight percent of organizations have active machine credentials tied to offboarded personnel.⁸ I know we're in that sixty-eight percent. I just don't know which credentials, with what permissions, talking to what systems.

The truly fun part? Only 8.5% of MCP servers use OAuth.⁹ Fifty-three percent rely on static API keys.¹⁰ So Amir's servers are almost certainly running on keys that don't expire, aren't rotated, and aren't visible in our identity management system. I have to go excavate config files and environment variables to find them. It's archaeology. I should be wearing a headlamp.

What does the NSA advisory actually ask you to do?

TK: Four things, roughly. Log all tool invocations with parameters, identities, and cryptographic hashes. Align tools with data classification zones so anything touching financial data needs explicit access controls. Cryptographic signatures on MCP messages with expiration timestamps and replay protection. Trust boundary enforcement so one compromised server can't move laterally.¹¹

Every one of those requirements is reasonable. None of them existed when we built these servers. And none of them are met by our current fleet. No centralized logging. No message signing. Static API keys instead of scoped credentials. No tool-level access controls.

Moving from STDIO to HTTP transport, that's maybe a sprint. Adding OAuth 2.1, RBAC, audit trails, a service registry, credential rotation, message integrity? That's a quarter. Minimum. And that's if nothing else catches fire while we're rebuilding.

Your company builds regulatory reporting tools for other fintechs.

TK: Yes. I'm aware of the irony. We help other companies produce audit trails, and we cannot produce our own for MCP. Our SOC 2 auditors are going to ask which AI tools are active, what data they can touch, and how access is controlled.¹² Right now, the honest answer is: we have eight MCP servers, we think we know what most of them do, we're not sure what credentials two of them are running on, and the protocol doesn't natively support the audit trail you're asking for.

The NSA advisory is already showing up on enterprise security questionnaires.¹³ Our customers are going to ask us about this. We sell trust in regulatory infrastructure, and we have orphaned API keys from a departed engineer running MCP servers that the protocol architect says are our responsibility to secure.

If I were a novelist, I'd call that dramatic irony. Since I'm a platform engineer, I call it Tuesday.

What's the timeline look like?

TK: TrueFoundry estimates six to ten weeks just for inventory and catalog build at a 500-person org.¹⁴ We're smaller, but the problem isn't headcount. It's that every server is a bespoke implementation. The CISO wants answers in a week. I can give her a list of server names in a week. I cannot give her a list of permissions, credentials, data access patterns, and trust boundaries in a week. That information doesn't exist in one place. Some of it doesn't exist at all.

If you could go back twelve months, what would you do differently?

TK: (long pause) I'd have built a registry before I built the first server. But that's easy to say now. Twelve months ago, MCP was a protocol with momentum and a spec that said security is the implementer's responsibility. We were implementers. We implemented features. The security posture was... implicit. The assumption was that these were internal tools behind our network boundary, talking to our own systems.

The NSA just told us that assumption was wrong. They're right.

I have a meeting with the CISO in forty minutes. I should go prepare something that looks like a plan.

Footnotes

1. TK is a composite character. All technical details, statistics, and vulnerability descriptions are drawn from published sources cited below. ↩

2. MCP 2026 roadmap acknowledges no standardized audit trails. WorkOS, "MCP's 2026 roadmap makes enterprise readiness a top priority," March 2026. ↩

3. Strata Identity, "Securing MCP Servers at Scale," January 2026. ↩

4. MCP Transport Specification. TrueFoundry, "MCP Transport: Stdio vs Streamable HTTP." ↩

5. CyberStrategyInstitute, "MCP Security Supply Chain Crisis April 2026," May 2026. ↩

6. Anthropic's position on STDIO sanitization responsibility per OX Security advisory, cited in CyberStrategyInstitute. ↩

7. OWASP NHI Top 10, "NHI1:2025 Improper Offboarding." ↩

8. Oasis Security, "What is an Offboarded Employee?" April 2025. ↩

9. CyberStrategyInstitute, MCP authentication survey data, May 2026. ↩

10. MintMCP, "Best MCP Gateways for SOC 2 Compliant Organizations 2026." ↩

11. NSA Artificial Intelligence Security Center, "Model Context Protocol: Security Design Considerations," CSI U/OO/6030316-26, May 2026. ↩

12. LastPass Blog, "Model Context Protocol Risk: Govern AI Agent Credentials." ↩

13. Speakeasy, "The NSA's MCP security baseline." ↩

14. TrueFoundry, "MCP Security Risks & Best Practices: Enterprise Guide," May 2026. ↩