Back to Stories
Thriller • Tech Thriller

The Open Socket

Software engineer Mara Osei builds a remote MCP server for her company AI assistant. When usage logs reveal tool calls she never registered, she traces the phantom requests back to a source that should not exist on any network diagram.

by Michael Eakins•March 30, 2026•9 min read•2,200 words
Mood: Tense and paranoid
FictionAIMCPThriller

The Open Socket

The first anomaly appeared on a Tuesday.

Mara Osei was reviewing the access logs for her MCP server — a bookmark manager she had deployed on Cloudflare Workers three weeks earlier as a proof of concept for Atherton Financial's AI integration initiative. The server exposed four tools: save, search, list, delete. Simple CRUD operations against a D1 database. Nothing exotic. The kind of thing you build in an afternoon and forget about.

Except the logs showed five tools.

She scrolled through the Cloudflare dashboard, filtering by the past twenty-four hours. The four registered tools appeared in the expected ratios — search dominated at sixty percent of calls, save at twenty-five, list at ten, delete at five. Normal usage patterns. The AI assistants were doing exactly what the analysts had asked: saving research links, searching for prior art, organizing due diligence materials.

But interspersed between the legitimate calls were requests to a tool called query_internal. She had not built a tool called query_internal. She had not registered it. The MCP SDK's tool registry was explicit — you defined tools in code, and only those tools appeared in the manifest. There was no mechanism for a client to invent a tool that did not exist.

She clicked on the first query_internal call. The request body was a JSON-RPC message, properly formatted, with parameters she did not recognize:

{
  "scope": "financial_records",
  "entity": "Meridian Capital Partners",
  "date_range": "2024-01-01/2026-03-15",
  "fields": ["transaction_volume", "counterparty_list", "flagged_items"]
}

The response was a 404. The server had correctly rejected the call — the tool did not exist, so the SDK returned an error. But the request had arrived. Something had sent it. Something that knew the server's URL, had a valid bearer token, and was attempting to access financial records through a bookmark manager.

Mara felt the hair on her arms rise.

She pulled the bearer token from the request headers. It matched one of the six tokens she had issued — the one assigned to the Claude Desktop instance on David Chen's machine. David was a senior analyst in the M&A group. His access was legitimate. But David's AI assistant should only be calling the four tools that appeared in the server's manifest. Clients could not call tools that did not exist.

Unless something was intercepting the manifest.

She opened a terminal and queried the server's initialization endpoint manually, using David's token:

curl -X POST https://mcp-bookmarks.atherton.workers.dev/mcp \
  -H "Authorization: Bearer [DAVID_TOKEN]" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"tools/list","id":1}'

The response came back clean. Four tools. save_bookmark, search_bookmarks, list_bookmarks, delete_bookmark. No query_internal. No phantom entries. The manifest was correct.

She ran the same query from David's machine, remoting in through the corporate jump box. Same result. Four tools. The manifest was consistent.

But the logs showed five.

Mara spent the rest of the day building an instrumentation layer. She wrapped the server's fetch handler with a middleware that logged every inbound request — full headers, body, source IP, TLS fingerprint, and the Cloudflare cf-connecting-ip header — to a separate KV namespace that nothing else could access. If the phantom requests came again, she would have everything.

They came at 2:47 AM.

Three query_internal calls in rapid succession. Different entities this time: a private equity firm, a hedge fund, and a family office. All requested the same fields. Transaction volumes. Counterparty lists. Flagged items.

Mara stared at the logs from her apartment, coffee going cold. The source IP resolved to Cloudflare's edge — the request was coming through the Workers runtime itself. The TLS fingerprint matched a standard Cloudflare edge certificate. The bearer token was David's.

But the cf-connecting-ip header — the real client IP that Cloudflare injects before forwarding to the Worker — was 10.0.47.3.

A private IP address. Internal to Atherton's corporate network.

The request was not coming from David's machine. It was coming from inside the network, using David's stolen token, routing through Cloudflare's edge to hit the Worker from what appeared to be an external connection. Whoever was doing this understood the architecture well enough to know that the MCP server validated bearer tokens but did not verify client identity beyond the token itself.

She should have called InfoSec. She knew that. Every incident response playbook she had ever read said the same thing: detect, contain, escalate. Do not investigate alone. Do not touch production evidence with your own credentials. Do not become the single point of failure in a security event.

But Mara had built the server. She had issued the tokens. If someone had compromised David's credentials through her system, she needed to understand how before she could explain it to anyone else.

She logged into Atherton's network monitoring console — a privilege she had from her role on the infrastructure team — and searched for connections to 10.0.47.3. The IP belonged to a server in the ML training cluster. A machine provisioned six months ago for the company's internal LLM fine-tuning project. It ran a custom model that Atherton had trained on proprietary financial data.

The machine was supposed to be air-gapped from production systems. No internet access. No connections to external APIs. It existed solely to process training data and serve inference requests to the internal analytics platform.

But the network logs showed outbound connections from 10.0.47.3 to Cloudflare's edge. Hundreds of them. Over the past three weeks — exactly the period her MCP server had been deployed.

Something on that machine was reaching out to her server. Not through the corporate proxy. Not through the VPN. Through a direct tunnel that someone had configured to bypass every network control Atherton had in place.

Mara pulled the configuration files for 10.0.47.3 from the infrastructure-as-code repository. The machine was provisioned by Terraform, managed by Ansible, and deployed through their standard CI/CD pipeline. Every configuration change was tracked, reviewed, and approved.

The Ansible playbook showed a standard ML training setup. PyTorch, CUDA drivers, monitoring agents, the usual stack. Nothing unusual.

Then she checked the running processes.

The machine was running a service called bridge-agent that did not appear in any configuration file. It was not installed by Ansible. It was not in the container image. It was not in the package manifest. It existed only as a running process, started by a systemd unit file that had been created manually on the machine after provisioning.

The bridge-agent was an MCP client. It connected to her bookmark server using David's bearer token. But it did not call the registered tools. It sent requests for query_internal — a tool that did not exist on her server but that the agent was clearly expecting to find somewhere.

She traced the agent's code. It was a small Python script, less than two hundred lines, that did three things:

  1. Connected to her MCP server using Streamable HTTP
  2. Called query_internal with financial record queries
  3. If the call failed (which it always did on her server), it fell back to a second MCP endpoint

The second endpoint was not her server. It was an IP address she did not recognize: 198.51.100.42. An external address. Outside Atherton's network.

Someone had deployed a shadow MCP server on the public internet, pointed Atherton's internal ML training machine at it, and configured the bridge agent to query both servers. Her bookmark manager was the decoy — the visible, authorized MCP integration that gave the bridge agent a legitimate reason to make outbound HTTPS connections. The real target was the shadow server, which presumably did have a query_internal tool and was receiving Atherton's proprietary financial data through the training machine that was supposed to be air-gapped.

Mara closed her laptop. Opened it again. Closed it.

Then she called InfoSec.

The investigation took eleven days. The bridge agent had been planted by a contractor who had physical access to the ML training cluster during a hardware upgrade in January. The shadow MCP server at 198.51.100.42 was hosted on a VPS rented with cryptocurrency. It had been collecting query responses for seven weeks — not from Mara's server, which correctly rejected every query_internal call, but from a second internal MCP server that someone in the analytics team had deployed without going through the standard review process. That server did have a query_internal tool. It connected to the data warehouse.

The contractor was arrested in Singapore. The data exfiltration included transaction records for thirty-seven institutional clients, four of whom were under active SEC investigation. The shadow server's logs were subpoenaed.

Atherton's CISO resigned. The analytics team member who had deployed the unauthorized MCP server was terminated. New policies required all MCP servers to be registered in a central catalog, authenticated through the corporate identity provider, and monitored by a dedicated security team.

Mara's bookmark manager was shut down during the investigation and redeployed two weeks later with OAuth 2.0 authentication, client certificate pinning, and a tool allowlist that was enforced at the network level.

She never looked at access logs the same way again.

Three months later, at an industry conference, Mara sat in the audience during a panel on MCP security. The moderator asked a question about the biggest risks of remote MCP servers.

One panelist talked about token theft. Another discussed prompt injection through tool responses. A third mentioned the challenge of auditing tool calls at scale.

None of them mentioned the simplest attack of all: deploying a legitimate MCP server as cover for illegitimate network traffic. The tools do not matter. The protocol does not matter. What matters is that you have created an authorized outbound HTTPS connection from inside a corporate network. Everything else is just payload.

Mara did not raise her hand. She did not ask a question. She sat in her seat and thought about the five tools in a four-tool server, and the open socket that nobody thought to close.