The MCP debate has a context problem

MCP has been declared dead so many times this year it should qualify for a pension. The complaint is familiar: too much scaffolding, too many moving parts, when a plain API call would do the job. And for a lone developer wiring up a personal assistant or running a script on their own machine, that complaint is mostly fair. Trust is implicit when you're the only user. Adding a protocol layer there is like installing a deadbolt on your sock drawer.

The argument collapses the moment you leave that single-developer bubble, though. Enterprise agent systems span teams, vendors, and organizations, and often the person whose data is being touched has no idea an agent is even in the loop. In that world, credential delegation becomes a real headache fast. Does the agent inherit the user's permissions? Run as a service account? Get scoped access per task? There's no universal answer, but pick wrong and you either hand out excessive access — which turns into an audit nightmare — or starve the agent, which just makes it fail quietly and slowly kills trust in the platform.

This is where regulated industries get uncomfortable. Compliance teams don't accept "the AI did it" as an explanation. They want to know what the agent touched, on whose authority, and under what scope, and they want that captured as the action happens, not reverse-engineered from logs afterward. A raw API integration has no built-in way to answer that. A properly configured MCP setup does, because it records server, credentials, and scope at the moment of each tool call.

Allowlists get treated as a substitute for governance, but they're really just a to-do list with good intentions. They fail through misconfiguration, agent behavior nobody predicted, and edge cases the list's author never imagined. Structural least privilege is the sturdier alternative: if an MCP connection only exposes the tools an agent needs for one task, there's no rule to break because there's no door to walk through. "It cannot exceed its scope" is a fundamentally different guarantee than "it's supposed to follow the rules," and security teams know the difference even when engineering doesn't want to hear it.

None of this means MCP is problem-free. Provisioning servers with the right scoped capabilities still takes more infrastructure know-how than most teams have lying around, so admins default to broad access plus an allowlist as a safety net — which is exactly the weak pattern this whole debate is about. Until scoped provisioning gets easy enough for a platform team to manage without reading someone else's config files, adoption stalls at the edges. The incidents that expose this gap won't announce themselves in advance. Autonomous agents will find the hole before anyone on the security team does.