Anthropic’s Model Context Protocol (MCP) went into production in late 2024. It spread rapidly after that. 

Since then, thousands of MCP servers have been created. Microsoft, Google, and OpenAI embraced it. The Linux Foundation took over protocol maintenance. Today, MCP is considered critical infrastructure. It sits between an AI agent and the tools and data it interacts with. Most teams implemented it the same way they implement any other integration standard. People installed it and trusted the defaults.

The understanding that emerged in 2026 is that the problem wasn’t in the infrastructure. The problem is in the permissions below this infrastructure.

This matters because it changes how people approach MCP security problems. A patch solves a specific problem on a particular server. The permission change requires asking a complicated question. 

“The understanding that emerged in 2026 is that the problem wasn’t in the infrastructure. The problem is in the permissions below this infrastructure.”

Why did that particular server require access to something it never needed to be there? According to the SANS 2026 Identity Threats Survey, which surveyed more than 500 security experts, 76 percent of businesses noted an increase in non-human identities. 74 percent of businesses use AI systems that rely on standing credentials to work independently. This same survey revealed that none of the protection measures, such as approval processes, sandboxing, or logging, is used by more than 40 percent of businesses.

Look past the individual disclosures, and the same root cause keeps showing up. In May 2025, an attacker used prompt injection against the GitHub MCP server to pull private repository data, not because the server had a bug in the traditional sense, but because the personal access token behind it was scoped far wider than the task required. Days later, a logic flaw in an Asana MCP integration allowed cross-tenant access because the permission layer never enforced the isolation boundary between customers.

Security researchers now group it under a couple of recognizable patterns: tool poisoning, where a server’s own tool description carries hidden instructions, and the confused deputy problem, where an agent inherits more trust than the task in front of it requires.

What a permissions redesign actually asks you to check

The solution that keeps coming up isn’t a better scanner, but compartmentalizing access. GitHub’s Engineering Blog, which discusses developing secure remote MCP servers, suggests the following: every instance must have its own secrets for the specific task, all requests must be limited to the acting user, and authorization must be based on action rather than assumed after user authentication. Replace fixed, permanent tokens with dynamic, temporary credentials generated on the fly.

“Replace fixed, permanent tokens with dynamic, temporary credentials generated on the fly.”

This solution is tiered and has been working until now. In Webflow, we treat MCP integrations in the same way as we treat other third-party components with access to customer data.

Each credential the team gives to an AI agent was probably a good idea when it was provisioned. The tough call isn’t whether that access was a good idea at the time. It’s whether it is anymore, and most teams aren’t in the habit of making it.

Some things to consider while integrating any MCP:

What can this credential reach now, rather than the scope for which it was intended? The scope of access is likely to creep. No review will be scheduled until something breaks.

Is authorization granted on a per-site, per-repository, or per-Workspace basis, or all or nothing? Be leery of any integration that only provides organizational access. If an integration doesn’t give you control over scope at connection time, that’s the finding, not a footnote.

Does the AI agent inherit the person’s existing credentials, or create entirely new credentials that bypass those permissions? The latter is how a GitHub personal access token can have more access to repos than the user who authorized it.

Does logging assign accountability for what the agent does in the same way it does for a human? If the agent’s activities are invisible or unattributable, incident response starts at ground zero.

Do changes from the agent go straight into production, or do they pass through a reviewable process like draft, branch, and approval queue first? This is just applying the security discipline the team already has around human access controls to a newer class of entity.

Identity comes before access

Before you can talk about what an agent is allowed to do, you have to answer a harder question: what is an agent, identity-wise? Right now the honest answer for most of the industry is “a human’s OAuth token wearing a trenchcoat.” The agent doesn’t have its own identity. It inherits the scope, the blast radius, and often the literal credential of whoever spun it up.

That’s a problem the moment agents stop being ephemeral. Most agents today live for minutes to hours: a task starts, the agent runs, it dies. But that’s changing. We’re heading toward agents that run for weeks or months, and a thing that lives that long needs its own identity, not a borrowed one, with permissions that get stricter, not looser, as the lifespan grows.

“Right now the honest answer for most of the industry is ‘a human’s OAuth token wearing a trenchcoat.'”

Think of it like the difference between a contractor you bring in for an afternoon and a contingent worker embedded in your systems for a quarter. You wouldn’t give the afternoon contractor a permanent badge, and you shouldn’t give the quarter-long agent the same access as a five-minute script.

OAuth wasn’t built for this, and it’s not just a missing feature; it’s a structural mismatch, and at root a UX failure: a consent model built for a human in the loop, applied to a process that has none. 

Its whole model assumes a human sits in front of a scope dialog and makes an informed choice, and we all know how that goes: nobody reads the scope list; they click allow. That already-shaky assumption collapses completely when there’s no human reading anything. 

The base spec has no concept of “this client is an agent” or “this grant is expected to run for six months,” just a server-set expiry after the fact. A few IETF drafts are starting to sketch a fix: binding token lifetime to a task’s actual lifecycle and tagging agents with stable identities distinct from the human who invoked them. Still, those are early-stage proposals, not deployed standard(s).

We don’t have a clean answer for where the line sits between “short-lived task, broad-ish access” and “long-lived agent, locked down tight.” Webflow’s security team is actively working through this, and we’re comparing notes with peers across the industry rather than pretending we’ve solved it. But the framing itself matters: treat agent lifespan as a first-class input to your permission model, not an afterthought.

Permissions aren’t a checkbox at provisioning

A permissions redesign, a protocol update, and an identity model represent three distinct levels of the same problem. For each level to remain effective, the other two must be effective too. 

If you create a credential with the correct scope on Day One, but then no one ever verifies that the credential remains valid, your efforts were wasted. Similarly, if you develop a new protocol that finally distinguishes an agent from the human behind it, but all integrations continue to provide standing, all-or-nothing access by default, you have done little good. Neither approach addresses the deeper question at the root of both: what an agent is permitted to do should depend on how long it will exist. 

“The teams who get this right will be the teams who stopped viewing scope, identity, and lifetime as three separate evaluations, and began treating them as a single setting.”

Right now, nearly all components of the technology stack don’t know how to ask that question, much less answer it. The teams who get this right will not be the ones who developed a more efficient scanning tool. Rather, they will be the teams who stopped viewing scope, identity, and lifetime as three separate evaluations that occur once per agent instance, and began treating them as a single setting that must be evaluated each time the agent’s function or existence changes.

This article was originally published on September 9, 2026, on webflow.com.

The post Why MCP security is about permissions overhaul appeared first on The New Stack.

Bob from finance built a scheduling tool last month. He described it to an AI assistant on a Sunday afternoon, wired it into Slack and three internal APIs before dinner, and by Monday three departments depended on it. That story is funny right up until you check what token it is running on. 

What changed a few weeks ago 

On July 28, 2026, the Model Context Protocol’s maintainers shipped a specification update built almost entirely around authorization: issuer validation, issuer-bound client credentials, and Client ID Metadata Documents as the preferred way for clients to register. Put plainly, that is the protocol’s own stewards admitting the original trust model didn’t survive contact with production.

If the people who wrote the spec needed a security overhaul this deep in, the tool Bob built on a Sunday does not get a pass either, and Bob has never heard of issuer validation. 

Three ways this actually breaks 

Tool descriptions carry instructions, not just documentation. In May 2025, researchers at Invariant Labs showed that GitHub’s own MCP server could be hijacked through a poisoned public issue: an attacker’s text in an issue body was read as an instruction by the agent and used the victim’s token to pull data from private repositories. No compromised code, no malicious tool, just a description field nobody thought to sanitize.

A 2026 benchmark called MCPTox tested this pattern against 45 live MCP servers and 20 models, measuring a 36.5 percent average attack success rate and 72.8 percent against the worst-performing model. Bob’s tool has the same basic shape: it reads Slack messages and ticket text to decide what to reprioritize. It can’t tell the difference between a coworker’s request and a string engineered to look like one, because nobody asked it to. 

Scopes default to everything. The common failure isn’t a missing permission model; it is an ignored one. A server that needs read-only calendar access asks for read, write, and admin across the board because that is what the tutorial used. Across the MCP ecosystem, 88 percent of servers require credentials to function, but only 8.5 percent actually use OAuth.

Most of what is running was never scoped in the first place, so there is no scope left to creep. Bob did not sit down and choose a scope. He reused the admin-level API key already sitting in his password manager from a reporting dashboard he set up two years ago, because requesting a narrower one meant filing a ticket, and filing a ticket was the entire bureaucracy he was trying to avoid. 

Static tokens do not rotate, and nobody is watching them not rotate. Splunk’s own MCP Server app logged session and auth tokens in cleartext until it was patched in version 1.0.3, tracked as CVE-2026-20205. That vendor has a security team.

By some estimates, over half of MCP servers in the wild run on static API keys or personal access tokens that are rarely rotated, and close to half of enterprise AI activity runs through personal accounts rather than service accounts, meaning the credential doing the work belongs to somebody’s identity, not the system’s.

Bob’s token is that same reporting-dashboard key. It has been valid since it was issued; it will stay valid until somebody remembers to kill it, and the only record of what it has touched this month lives in Bob’s memory — which is not a log. 

What we have actually seen 

While setting up our own MCP integrations across customer and prospect environments over the past several months, we found that more than 20 percent of the MCP-related access policies we reviewed were either broken or missing entirely.

We found that more than 20 percent of the MCP-related access policies we reviewed were either broken or missing entirely.

In most cases, the MCP server in question was authenticated with someone’s personal token rather than a service account. None of those tokens had a documented rotation schedule. None of the servers had logs of what they touched. If Bob’s tool had been in that batch, and statistically it probably would have been, nobody would have known until something went wrong, because right now nothing is watching for it to go wrong. 

The honest caveat 

None of this means every vibe-coded integration needs a change advisory board. Most of what Bob built is harmless, and gating every weekend project behind a formal review process is exactly how you get back to the eighteen-month procurement cycle nobody missed. Governance has its own cost, paid in the good ideas that never ship because process ate the weekend momentum that made them possible.

The problem is not that these tools exist. It is that most organizations currently cannot tell the difference between the harmless ones and the ones holding a token that reaches production, and they are trying to solve that with the same review board that made Bob route around them in the first place. 

The actual decision 

The question in front of every platform team right now is not whether to allow AI-built integrations. That decision was already made over a weekend, without anyone in the room. It is whether you find out what a given MCP server can touch from an inventory you built on purpose, or from an incident report after the fact. Bob’s scheduling tool is still running. It has not caused an incident, and it probably never will.

But the difference between Bob’s tool and the next one that makes the news isn’t the code; it is whether anyone can say what token it holds, what it can reach, and when it was last rotated. 

The post Researchers found that 1 in 5 MCP access policies came back broken or missing appeared first on The New Stack.

Michael Loewy, co-founder of the Tide Foundation, says the security industry was already losing ground to hackers before AI. Everything from a typo to a state actor could create a breach.

“Before AI even came into the developer consciousness, a developer or a platform owner needed to be perfect all the time — perfectly patched, free of errors, free of bugs — and an attacker only needed to be right once to get in,” Loewy tells The New Stack. “It’s virtually impossible, which is why we’re seeing breaches in the news every day, and the biggest companies in the world getting breached. It could be one poorly written line of code, one misconfiguration, and then you’re done.”

AI has, of course, compounded the risks.

Loewy warns that vast amounts of inadequately reviewed, error-prone code are being produced just as advanced AI models are becoming highly skilled at discovering and exploiting vulnerabilities. Meanwhile, AI agents are creating software and performing sensitive, privileged actions.

Attackers gain access by getting past authentication and authorization. But what Loewy and co-founder Ben Waters are most worried about is the authority agents gain once inside.

Authority, as they define it, is the power to decide who or what can get into which system, who can access and decrypt which data, and who can authenticate, authorize and assign permissions. It lives in the systems we’re forced to unquestioningly trust in the form of admin credentials, root keys, identity providers, and service accounts. As Loewy says, “the problem is that it always lives somewhere, and someone always has access to it.”

Tide’s answer is a model it calls “emergent authority.” Under it, authority isn’t permanently held by any person, system, administrator, or AI. Instead, it is generated only when identity, policy, context, and intent align — before it disappears again. Loewy and Waters spoke exclusively with The New Stack about what that means for developers.

The flaws of the all-eggs, one-basket approach

Most systems at most organizations keep application secrets, user credentials, and permissions in one place, then build more and more defenses around that central location, such as firewalls, key vaults, multi-factor authentication, and endpoint detection and response.

“That root paradigm is flawed. Tide seeks to overcome that by using cryptography to compute authority in pieces so that it can’t be reassembled.”

“Even if your code is perfectly free of bugs, it’s sitting in someone else’s cloud on someone else’s operating system. There’s this whole suite of dependencies where the code and everything needs to be perfectly patched all the time, everywhere, and configured correctly for your security to be perfect,” Waters explains in our interview. “That root paradigm is flawed. Tide seeks to overcome that by using cryptography to compute authority in pieces so that it can’t be reassembled.”

In reality, just about every system is porous. Tide’s goal is that if and when you are breached, and the attacker has root on your server, there is nothing there for them to inherit, because the authority has been architecturally distributed elsewhere.

From IoT middleware to distributed authority by default

Founded about a decade ago, Tide started as an Internet of Things analytics platform sitting between brands and consumers’ connected health devices, smart homes, and wearables. Its regulated customers demanded proof that no breach could leak highly sensitive information, trigger a GDPR fine, or destroy a reputation.

The infrastructure the team built to secure itself became the product, and, with it, a way out of the perpetual safety-speed tension between DevSecOps and product teams. At the pace of AI, this tension has only sharpened.

That infrastructure is now the developer product, TideCloak, which fits where your identity and access management system sits and handles authentication, authorization, end-to-end encryption, and governance on top of Tide’s Cybersecurity Fabric, so consequential authority remains out of everyone’s and everything’s reach.

The implementation is fully inspectable through Tide’s open-source public GitHub repositories. The accompanying white paper on emergent authority was published using a chatbot to explain the underlying concepts and cryptography.

Let your coding agent do the integration.

The part most likely to interest developers is how you’re meant to adopt it, not by reading those loads of documentation, but by handing the job to your coding agent.

“We needed this security apparatus or infrastructure that we’ve created to be something that can be seamlessly integrated into an existing project or best practice in a greenfield project, in a way where the developer doesn’t need to read loads of documentation,” Loewy says.

On Monday, Tide released Raziel, an MCP server named after the archangel of secrets, that gives AI assistants deep knowledge of Tide authentication, threshold cryptography, end-to-end encryption, and governance. Point your agent at it, and it can recommend self-hosted versus managed hosting and generate verified playbooks for the integration. A TideCloak quickstart covers the greenfield case for those who’d rather start from a clean project.

Where most security tooling begins by looking for ways an attacker might get in, one of Raziel’s prompts instead maps out your blast radius.

“We’ve said: they’re already in. Here’s what they’re going to find. Here’s where they can impersonate any user. Here’s where they can assign themselves access to whatever they want.”

“Where a typical cybersecurity scanner tries to find vulnerabilities- how someone’s going to get into your platform — we’ve started the opposite way,” Loewy explains. “We’ve said: they’re already in. Here’s what they’re going to find. Here’s where they can impersonate any user. Here’s where they can assign themselves access to whatever they want.”

Tide has also partnered with a Lloyd’s of London underwriter, enabling organizations integrating TideCloak to obtain preferential cyber insurance terms. He says that “It’s a rare case of a security claim being backed by capital.”

Coordination at scale, without custody at scale

The team likens their ambition to DNS. They hope that one day soon Tide will become infrastructure that nobody owns and everybody benefits from.

Tide is not just about breach prevention. To let an AI agent, a contractor, a partner, or a new vendor do anything consequential, you have to trust them with dangerous power. That trust requirement caps how far you can safely delegate or automate.

“The point isn’t just safer systems. Once nobody has to hold dangerous power to get something done, you can delegate real responsibility to an agent, a contractor, or a five-person startup without creating a dangerous insider.”

“The point isn’t just safer systems. Once nobody has to hold dangerous power to get something done, you can delegate real responsibility to an agent, a contractor, or a five-person startup without creating a dangerous insider,” Loewy says. “That’s what lets developers ship with AI at full speed. It’s coordination at scale without custody at scale.”

If that holds up in practice, Tide’s biggest effect may not be on cybersecurity at all, but on the cost of delegation, and on how much a small team, working with agents, can safely be trusted to build.

The post Why authority is the attack surface AI security keeps missing appeared first on The New Stack.