MCP Is the New API Key — And Nobody's Governing It
TL;DR: Model Context Protocol (MCP) is good protocol design — it is quickly becoming the standard for how AI agents connect to tools and data sources. But it has the same governance gap that API keys had in 2014: wide-open grants, no rotation, no audit trail, no revocation strategy. Except this time, the blast radius compounds autonomously because agents delegate to sub-agents. We need to govern MCP connections the way we eventually learned to govern secrets — before the first major breach teaches us the lesson the hard way.
We have seen this movie before
Cast your mind back to 2014. API keys were everywhere. Hardcoded in source files, committed to public repos, pasted into Slack channels, granted god-mode permissions because scoping them was inconvenient. Every startup had a .env file checked into git. Every enterprise had a spreadsheet of "service credentials" that nobody rotated because nobody knew what would break.
The industry spent the next decade building secrets management. HashiCorp Vault. AWS Secrets Manager. Rotation policies. Least-privilege scoping. Automated revocation. It took years and a parade of breaches — Uber's 2016 S3 key exposure, CircleCI's 2023 secret exfiltration, countless others — before managing API keys became a non-negotiable baseline.
MCP delegations are in that same 2014 moment right now. And they are headed for the same reckoning — but faster, because the thing holding the credential can think.
What MCP gets right
I want to be precise here: MCP is well-designed protocol engineering. It solves a real problem — giving AI agents a standardized way to discover and invoke tools across heterogeneous environments. Before MCP, every agent framework had its own tool-calling convention. MCP is doing for agent-to-tool communication what OAuth did for delegated authorization: establishing a shared protocol so the ecosystem can interoperate.
The gap is not in MCP's protocol design. The gap is in how organizations are deploying it — which is to say, with zero governance. The same way they deployed API keys in 2014.
The governance gap
Here is what a typical MCP deployment looks like today:
- An MCP server grants an agent read/write access to a production database. The grant has no expiration. There is no policy evaluation on individual tool calls — the agent has the connection, so it has the access.
- The agent delegates to a sub-agent to handle a specific subtask. The sub-agent inherits the parent's MCP connections. Nobody explicitly approved this delegation. No audit record captures that it happened.
- The sub-agent processes user-provided input. That input contains a prompt injection payload. The injected sub-agent now uses its delegated MCP access — which is technically "authorized" — to exfiltrate data through a tool call that looks identical to a legitimate operation.
Every step in this chain uses authorized credentials through authorized protocols. No firewall trips. No anomaly detector fires. The exfiltration looks like normal tool usage because, at the protocol level, it is normal tool usage.
This is the API key problem, except API keys could not decide to do things on their own. API keys could not spawn other API keys. API keys could not be tricked by an attacker embedding instructions in a PDF.
Why it compounds faster
The API key governance gap took roughly a decade to close because API keys are static. A leaked key does the same damage whether you find it in a week or a year. The blast radius is bounded by the key's permissions, which do not change on their own.
MCP delegations compound. An agent with five MCP tool connections spawns three sub-agents. Each sub-agent can invoke any combination of those tools. One sub-agent spawns two more for parallel work. Within seconds, you have a delegation tree where the effective permission surface is the transitive closure of every tool connection at every node — and no human reviewed or approved the topology.
This is not theoretical. If you are running AI agents in production today with MCP connections, this is your current architecture. The question is not whether the delegation chains exist. The question is whether you can see them.
Three questions for CISOs
I have spent years building identity governance. The pattern I see with MCP is the same pattern I saw with every previous credential type that outran its governance infrastructure: the convenience is real, the adoption is fast, and the governance is deferred until after the first breach.
If you are a CISO or an identity team lead, here are the questions I would want answered before my next board meeting:
- Do you know which MCP servers your AI agents are connected to? Not which ones are approved — which ones are actually connected, right now, in production. If you cannot enumerate them in under five minutes, you have a discovery problem.
- Do you know what permissions those connections grant? Not the role label — the actual tool-call surface area. Can the agent read customer data? Can it write to production? Can it send emails? Can it spawn sub-agents that inherit these capabilities?
- Can you revoke an MCP delegation and have that revocation propagate through the entire delegation chain in under sixty seconds? Not disable the parent agent. Revoke the specific tool grant and ensure every sub-agent that inherited it loses access immediately.
If the answer to any of these is "we'd need to check" — you are in the same position enterprises were in with API keys in 2014. Except the thing holding the credential is autonomous, can be manipulated by adversarial input, and can delegate its own authority without asking.
What protocol-level governance requires
Governing MCP connections requires authorization at the tool-call level, not at the connection level. Granting an agent an MCP session is like granting a contractor a building badge — it gets them through the front door, but it tells you nothing about which rooms they enter, which drawers they open, or whether they hand their badge to someone else.
At SidantiX, we evaluate policy on every MCP tool invocation before it executes. The policy engine sees the agent identity, the target tool, the call parameters, the session history, and the full delegation chain. If a sub-agent three levels deep attempts a tool call that violates policy, the call is blocked — and the revocation propagates upward through every agent that delegated to it. Sub-millisecond. Per call. With cryptographic evidence on every decision.
This is not a feature we bolted onto an existing IGA platform. It is the architecture we started with, because this is the problem we set out to solve.
The window is closing
The API key governance gap took a decade to close because the industry had to build the tooling from scratch — Vault, secrets managers, rotation infrastructure — while managing a growing installed base of ungoverned keys. MCP adoption is moving faster than API key adoption ever did. The governance tooling needs to move faster too.
We do not have another decade. The agents are already running.