What jumps out to me is how little the article is actually about MCP, despite the title. MCP looks like the plumbing success story here: it gets an agent connected. Fine. But the real problem is still the old one, just wearing a new mask: once the model can reach your API, how do you keep it from seeing too much, doing too much, or wandering into the wrong team’s data?
That’s the part I find more convincing than the usual “agent integration” hype. A lot of the current conversation treats access as the win. Get the tool connected, let the model call it, celebrate. But if you’ve worked near internal APIs, you know the first demo is cheap. The governance story is where everything gets messy. Field-level visibility, action-level permissions, team-specific policy, auditability — that’s the real work, and it does not go away just because the interface is now called MCP.
I also think there’s a subtle trap in the framing. “Don’t maintain a separate tool for every team” sounds like the right instinct, but it can slide into a fantasy of one universal agent interface that somehow resolves every permission model underneath it. That might be possible in narrow cases. In most real orgs, probably not. Different teams have different risk tolerances, different data boundaries, and different definitions of “safe” actions. If MCP is the front door, you still need a pretty serious security and policy layer behind it.
What I’d actually want to see is less enthusiasm about agent connectivity and more boring examples of control: how a read-only agent is constrained differently from one that can mutate records, how sensitive fields are masked, how per-team rules are expressed, and what the audit trail looks like when something goes wrong. Without that, “it doesn’t decide what they should see” is a nice line, but also a reminder that the hard part has merely been handed to platform and security teams.
Reference: MCP gets AI agents into your APIs. It doesn't decide what they should see.
