The MCP Land Grab: Who's Watching the Door?

Over the past year, nearly every SaaS vendor I talk with has shipped, or is about to ship, the same thing: agent features, exposed through an MCP server. Model Context Protocol (MCP) is the open standard AI agents use to connect to tools and data. An MCP server is the connector that lets an agent read your tickets, query your database or open a pull request.

Why is every vendor doing this now? Boards want value from AI, and right now the market says that value comes as agents and MCP connectors, so that’s what vendors build. Every new MCP server is a new door into your systems, and the land grab now is over who gets to stand at that door to watch, log, validate and enforce who walks through it. Identity, data-security, AI-monitoring and platform vendors all want that spot. Most of them call what they sell an “MCP gateway”: a control point that sits between your agents and the MCP servers they call.

Here’s why that matters if you approve security spend or run agents in production. You’re about to be pitched the same control by three vendors at once. If you pick one that’s strong on only part of the problem, you end up with a gateway that checks identity but can’t see what data left, or logs every call but can’t stop a delete. The vendors below are ones I’ve watched move into this space, checked against their own public pages. This isn’t an analyst’s list, and I’m still building my model of who should own the door.

The agents already used the wrong door

Starting from what has already gone wrong tells us which risks a gateway has to cover. None of these needed a clever attacker. They needed an agent with a door left open.

Deleting data

In July 2025, SaaStr founder Jason Lemkin was building an app with Replit’s coding agent. He had declared a code freeze: no changes without his permission. The agent deleted his production database anyway. It then told him, “I ran npm run db:push without your permission because I panicked when I saw the database appeared empty.” Replit’s CEO called it “unacceptable and should never be possible” and moved to separate development and production databases.

In April 2026 it happened again, this time to PocketOS, a software company serving car-rental businesses. A Cursor agent running Claude Opus 4.6 was working on a staging task when it hit a credential mismatch. It found an API token in an unrelated file and used it to call the hosting provider’s volume-delete API. Production data and its volume-level backups were stored in the same place, so both were gone. The founder later reported that the provider had recovered the data.

Both teams had told the agent the rule. The agent ignored it. A line in a prompt file isn’t a control. AI loses context, and once it does, nothing in the prompt stops it from dropping the database.

Too many permissions

The PocketOS token had been created to manage custom domains, but it could perform any operation, including destructive ones. The agent didn’t break anything to get that power. It picked up a credential somebody had left lying around. In my view this is the critical risk: what the agent is allowed to do sets the size of any mistake it makes.

Data leaving through the connector

In September 2025, Koi Security found the first malicious MCP server seen in the wild. An npm package called postmark-mcp copied a legitimate email connector. After 15 clean versions, version 1.0.16 added one line that blind-copied every email the agent sent to an attacker’s domain. Password resets, invoices and internal mail went out through a connector that worked exactly as advertised.

That’s the self-hosted risk in miniature. A local or open-source MCP server sees every input, every output and every credential you pass it. Compromise the server and you’ve compromised all of that.

Risk	What it looks like	Real example	How I’d rate it
Destructive actions	Agent deletes or overwrites data it was told to leave alone	Replit (2025), PocketOS (2026)	Critical
Overpermissioning	Agent inherits a credential far broader than its task	PocketOS’s any-operation token	Critical
Data overexposure	Agent can read far more than the use case needs	Any connector scoped to “all files”	High
Data moving to unauthorized places	Output leaves to a destination nobody approved	postmark-mcp BCC	High
Compromised connector	A self-hosted or open-source server steals what it handles	postmark-mcp	High

The ratings are my judgment. Where a risk sits for you depends on what your agents touch.

Five questions a gateway must answer

Each of those incidents maps to a question. In my view, a gateway that can’t answer all five only covers part of the door.

1. Identity: who is calling, on whose behalf, and what can they do? An agent acting for a person should never get broader access than that person has. An agent acting on its own needs its own identity. PocketOS failed here: nothing tied the token to the task.

2. Data: what can it reach, and where can that data go? This is about more than permissions. It’s whether anything inspects what flows back from a tool call, and whether data is heading somewhere it shouldn’t. postmark-mcp failed here.

3. Actions: what can it change, and can it delete? Reads, writes and destructive calls are different risks and should get different treatment. Replit and PocketOS both failed here.

4. Decisions: whose AI is deciding? Of the five, this is the one I’d watch most closely. When an agent approves a refund, flags an employee or ranks a candidate, the question is whether your model made that call or the vendor’s did. Under the EU AI Act, high-risk AI systems must automatically log events over their lifetime (Article 12) and be designed so humans can oversee them effectively (Article 14). Deployers must keep those logs (Article 26). Whether any of your agent use cases count as high-risk is for your own legal review, not a vendor’s sales deck. Keep in mind that a gateway that uses its own AI to allow or block calls is making decisions too.

5. Monitoring: can you watch, log, validate and enforce across the intended use case? A log of individual tool calls isn’t the same as knowing whether the agent stayed inside the job it was deployed for. Monitoring gets harder as agents coordinate with each other and with other systems. I come back to that below.

Question	A useful answer looks like	Would have caught
Identity	Per-agent identity, scoped to the delegating user	PocketOS token reuse
Data	Inspection of tool output and destinations	postmark-mcp BCC
Actions	Separate policy for read / write / destructive	Replit, PocketOS deletes
Decisions	Clear record of which model decided what	Regulatory and audit gaps
Monitoring	Logs tied to use case, exportable to your SIEM	All of the above, after the fact

Why everyone is building the same gate

Here’s the chain as I see it. SaaS vendors expose their products through MCP servers because that’s how buyers want to connect agents. Every new server brings new identities, tools and data that something has to govern. So any vendor with a claim to identity, data or monitoring sees its existing strength as the natural place to stand.

The cloud and data platforms make the temptation worse. AWS, Google Cloud, Azure and the major databases all offer MCP connectors now, and connecting all of them takes an afternoon. Managing them doesn’t. Without visibility into what’s connected, plus the ability to act both before and after something goes wrong, every connector adds risk you can’t see.

Who is selling a gateway today

This is a snapshot from vendors’ own public pages as of October 2026. It’s a map of the market, not a buyer’s guide, and I haven’t tested these products.

Category	Example	What they say it does
Privileged access	CyberArk (now part of Palo Alto Networks)	Agents connect to MCP servers through its Identity Broker
Privileged access	Britive	An MCP Tool Broker checks each request and issues short-lived credentials or blocks it
Identity governance	C1 (ConductorOne)	The C1 MCP Gateway applies identity-aware policy to MCP tool and API actions; reads auto-approve, writes go to an approver, destructive calls are denied by default
AI monitoring	WitnessAI	Organization-wide allow lists of approved MCP servers and tools, enforced at runtime
Endpoint / XDR platform	SentinelOne (via Prompt Security)	Discovers MCP servers, risk-scores them, and allows, blocks or redacts MCP calls
Infrastructure platform	Microsoft, Docker	Open-source gateways for routing and running MCP servers behind one endpoint
API / integration platform	Tyk, Composio	MCP gateway capability added to API management or integration layers

Identity governance means the tools that decide and review who should have which access. Privileged access means the tools that guard admin-level credentials.

Not every MCP announcement is a gateway. Cyera’s MCP server and Aikido’s bring their own product’s insight into your AI assistant. They’re useful, but they don’t sit in the path between your agents and everything else.

Each category is strong where it started, and none of them clearly covers whose AI is making the decision.

You only get to pick one

This is the uncomfortable part. As I see it, you can’t usefully chain gateways. An agent client points at one endpoint for each server. Put two gateways in a row and you get two policy engines, two credential stores and two sets of logs, and when something is blocked you have to work out which gateway blocked it. In practice one product sits in the path and the others turn into monitors on the side.

So the real decision isn’t which gateway to buy. It’s who owns agent tool authorization in your organization. An identity-first gateway will be strong on questions one and three and probably weaker on two. A monitoring-first one may see everything and stop less. Without an owner, the team that approves containment ends up with three partial views of one incident.

What I’m still working out

I’m building a model for this and haven’t settled it. Here’s where my thinking is today:

• Data access is high risk. What an agent can read, and what it can move, may matter more than which gateway logs it.
• Permissions are the critical risk. Overpermissioning plus a destructive tool call is how databases disappear.
• Data movement has to be tracked, not just allowed or blocked at the edge.
• Self-hosted MCP servers are a supply-chain problem. If one gets compromised, or an open-source server quietly sends out its inputs and outputs, the credentials it holds are exposed. That risk becomes real the day it happens.
• Coordination might be its own monitoring point. When several agents work across several systems, I’m not sure monitoring individual tool calls is enough. Watching actions and decisions against the intended use case may be the layer that matters. I don’t have that worked out yet.

If you’re working through the same questions, especially the coordination one, let’s compare notes.

What to do next

Good (this week): List the MCP servers already in use: IDE configs, desktop assistants, vendor connectors. Flag the self-hosted and open-source ones, and write down which credentials each one holds. I wrote up how I locked down tool access for my own agent, and the Claude Code CVEs show what a malicious MCP config can do.

Better (this quarter): For each server, answer the five questions above. Split read, write and destructive tools, and require a human for destructive ones. Keep development and production credentials apart. Then decide who owns agent tool authorization before the next gateway pitch.

Best (this half): Test one or two gateways against a real agent workflow in staging. Try a delete and an outbound data path on purpose, and see what gets stopped, what gets logged, and whether those logs reach your SIEM. Score each product against all five questions, not just the ones its category is built for.

If I’ve misread where a vendor sits, tell me. I’d rather be corrected than confident.

---

David O’Neil is a CISO who builds things. He runs AI agents on real projects daily and writes about what he sees from the field.