Every MCP Integration Has This Same Weak Point

Last Updated on July 30, 2026 by Editorial Team Author(s): “The AI Engineer” Originally published on Towards AI. created by GEMINI 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. What MCP Actually Is (In Plain Language) 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 Weak Point, Specifically 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: 1. Over-broad consent screens 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. 2. Tokens that outlive their purpose 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. 3. Constrained delegation that isn’t actually constrained 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. Why This Isn’t Just a Theoretical Risk 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: The abandoned integration: A marketing team connects an agent to a customer database for a one-time campaign. The campaign ends. The token doesn’t expire. Six months later, nobody remembers it exists — until a routine audit does. The chained agent problem: An agent with access to a support ticketing system delegates a sub-task to another agent for “drafting a response.” That sub-agent, through a shared token, ends up with more system access than the task required. The insider-adjacent risk: An employee leaves the company, but the agent they configured — with its own persistent credentials — keeps running under the same access it always had, because offboarding checklists don’t yet include “agent permissions.” 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. How Teams Are Handling It Right Now (And What’s Missing) 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 […]