A friend of mine — a backend engineer at a mid-size fintech startup — sent me a message last month that started with “so this is bad.” His team had just shipped an AI agent that used the Model Context Protocol (MCP) to connect to their internal tools: a CRM, a billing system, and a Slack workspace. It worked beautifully in the demo. Then, during a routine security review, someone noticed the agent still had full read/write access to a tool it hadn’t used in three weeks — access that was never explicitly revoked, because nobody had built a way to revoke it.
Nothing was breached. No data was stolen. But the gap was real, and it wasn’t a bug in his code. It was a structural weak point that shows up in almost every MCP integration being shipped right now: the authorization layer is an afterthought, not a foundation.
If you’re building with MCP — or even just evaluating it — this is the conversation nobody’s having loudly enough yet. So let’s have it.
If you haven’t worked with it directly, here’s the short version: MCP (Model Context Protocol) is a standard that lets AI models talk to external tools and data sources — databases, APIs, file systems, SaaS platforms — through a common interface. Instead of every AI app writing custom integration code for every tool, MCP gives everyone a shared language.
Think of it like USB-C for AI agents. Before USB-C, every device had its own charger and cable. MCP is trying to do the same thing for “how an AI agent connects to a tool.” That’s genuinely useful. It’s why MCP adoption has moved so fast — teams don’t want to rebuild the same plumbing for every new agent they ship.
But here’s the catch: USB-C doesn’t ask permission before it starts moving data. And a lot of MCP servers don’t either — or they do, but in a way that’s far weaker than most teams realize.
The problem isn’t MCP’s core idea. It’s what happens at the connection between an AI agent and the tools it’s allowed to touch — the authorization layer. Three things tend to go wrong at once:
When a user connects an MCP server to their agent, they’re usually shown a single consent screen: “Allow this agent to access [Tool].” That’s it. Not “read your calendar,” “send emails on your behalf,” and “delete files” as separate permissions — just one blanket yes.
This is the same mistake early mobile apps made before Android and iOS forced granular permissions. Nobody wants to relearn that lesson the hard way, but that’s exactly the trajectory MCP is on.
Once an agent gets a token to access a tool, that token often persists far longer than the task that justified it. My friend’s billing-system access is the textbook example: the agent needed it for a two-week project, and the access token quietly kept working for months afterward because nothing in the architecture prompted anyone to check.
This is the subtle one. In theory, an agent should only be able to act within the scope a human explicitly granted — read this folder, not that one; send messages, don’t delete them. In practice, many MCP implementations pass tokens downstream to sub-tools or chained agents without re-checking scope at each hop. A token meant for “read customer records” can end up being usable by a downstream process for something broader, simply because nobody re-validated it along the way.
Put those three together, and you get a pattern security teams are already flagging in early audits: agents that have more access than anyone intended, for longer than anyone intended, with less oversight than anyone assumed.
It’s tempting to file this under “edge case” — until you look at how fast agent adoption is scaling. Enterprises are moving from a handful of pilot agents to dozens of task-specific agents wired into real systems: CRMs, HR platforms, financial tools, internal wikis. Every one of those connections is a new OAuth-style handshake, and most teams are copy-pasting the same lightweight auth pattern across all of them because it’s what MCP made easy.
That’s the real danger. It’s not that any single integration is catastrophically insecure. It’s that the same shortcut is being replicated at scale, across thousands of companies, faster than security review processes can catch up.
A few real-world-shaped scenarios worth sitting with:
None of these require a hacker. They just require normal organizational entropy, which is a much harder thing to defend against than a single attacker.
Most current approaches fall into a few camps — and it’s worth being honest about the tradeoffs of each.
Approach 1: Trust the platform. Some teams just rely on whatever default auth flow their MCP server or client library ships with. Fast to implement, but it inherits every weakness described above. Fine for a prototype. Risky in production.
Approach 2: Manual scope review. Security-conscious teams manually audit every MCP connection’s permissions on a schedule. This works, but it doesn’t scale — once you have dozens of agents and integrations, manual review becomes the bottleneck, and things slip through.
Approach 3: Short-lived tokens with explicit refresh. This is the stronger pattern, and it’s starting to show up in more mature implementations. Instead of a long-lived token, the agent gets a token scoped to a specific task with a short expiry, and has to explicitly re-request access for anything beyond that scope.
Here’s roughly what that looks like in practice:
javascript
// Weak pattern: broad, long-lived tokenconst token = await mcpClient.authorize({ scope: "full-access", expiresIn: "90d"});// Stronger pattern: task-scoped, short-lived tokenconst token = await mcpClient.authorize({ scope: ["read:customer_records"], purpose: "campaign-analysis-q3", expiresIn: "24h", revokeOnTaskComplete: true});
The difference looks small in code, but it changes the entire risk profile. A token that expires in 24 hours and is scoped to one purpose can’t become the six-month-old forgotten access my friend found. It fails safe by default.
Approach 4: Per-hop scope validation. For chained or multi-agent systems, the strongest teams are starting to re-validate scope at every delegation point — not just at the initial connection. This is more engineering work, but it’s the only approach that actually closes the “constrained delegation isn’t constrained” gap.
None of these are exotic ideas. They’re the same lessons OAuth learned over the past fifteen years, applied late to a new context. The tooling to do this well is still catching up, which is exactly why this is worth understanding now rather than after your first audit finding.
If you take one thing from this, let it be this checklist:
None of this requires abandoning MCP. The protocol’s core value — a shared, sane way for agents to talk to tools — is still worth it. But adopting it without also adopting stronger authorization discipline is like installing a great new door and forgetting to change the lock.
This isn’t really a story about one protocol. It’s a preview of a pattern we’re going to see over and over as agentic AI moves from demos into production: the parts of the system that don’t produce a demo-able feature are the parts that get skipped. Nobody shows off a well-scoped OAuth flow in a product launch video. Everybody shows off the agent doing something impressive. That mismatch in incentives is exactly why the weak point survives as long as it does.
The teams that get ahead of this — that build agent identity and access management the way they’d build it for a human employee, with scoped roles, expirations, and offboarding — are going to be the ones who aren’t writing “so this is bad” Slack messages at 2 a.m. next year.
If you’re currently shipping or maintaining MCP integrations, here’s your actual next step: don’t wait for a scheduled audit. Pull up your current MCP connections this week and ask three questions for each one — what scope does this token actually have, how long does it live, and who would notice if it were misused? If you can’t answer all three quickly, that’s your starting point.
The agent economy is moving fast, and the plumbing is genuinely useful. But plumbing that leaks doesn’t stay quiet forever — it just waits for the moment you’re not looking. Better to find the weak point yourself than to have it found for you.
Every MCP Integration Has This Same Weak Point was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.