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.

Shadow IT used to be a SaaS problem. Someone on the marketing team signed up for a tool, connected it to Google Workspace, and your first signal was an OAuth grant you didn’t authorize. Annoying. Detectable. Containable.

That era is over.

The new shadow IT doesn’t show up in your OAuth logs. It shows up as infrastructure running in your cloud account, built by a well-meaning engineer who asked an AI agent to stand it up in an afternoon. No ticket, no review, no security team involvement. Just someone with a good idea and a tool that removed all the friction that had slowed them down.

“The new shadow IT doesn’t show up in your OAuth logs. It shows up as infrastructure running in your cloud account.”

That friction wasn’t just inefficiency. Some of it was doing real security work.

The problem with good intent

Classic shadow IT had a whiff of someone knowingly going around IT. A team that didn’t want to wait for procurement. The security story was at least partially about policy enforcement.

That’s not what this is.

The engineer who vibe codes an internal tool for their team isn’t trying to circumvent anything; they’re trying to help. They have access to an AI agent that can write code, generate Pulumi programs, and stand up infrastructure faster than any review process can handle. And unless they’ve spent time thinking about cloud security, they have no reason to know that what they just shipped is a problem.

That’s what makes this harder: you can’t enforce your way out of it; you have to get ahead of it quickly.

Here’s what the bad day looks like: an engineer builds a lightweight internal app to automate something their team does manually. They ask the AI agent to handle the infrastructure. The agent provisions resources in the team’s AWS account, opens the necessary ports, and deploys the app. It works, and the team absolutely loves it. Nobody files a ticket because there’s nothing to file. Six weeks later, your CSPM flags a public-facing endpoint with an over-permissioned IAM role attached. By then the app has been running in production long enough that lateral movement is a realistic scenario, not a theoretical one.

The intent was good. The outcome has a blast radius.

Why this is different from SaaS sprawl

When shadow IT meant unauthorized SaaS, your detection surface was defined. OAuth grants, network traffic, expense reports, SSO anomalies. The tool existed outside your infrastructure. It was external. You could find it, you could cut it off, and the damage was usually bounded.

“This is the shift worth naming clearly: we’ve moved from SaaS sprawl to code sprawl.”

Agent-built internal tooling lives inside your infrastructure. It has IAM roles. It may have direct access to production data, internal APIs, or sensitive systems. It looks legitimate because it was built by a legitimate employee using legitimate tooling. There’s no obvious seam to detect at. The code doesn’t announce itself as ungoverned. It just runs.

This is the shift worth naming clearly: we’ve moved from SaaS sprawl to code sprawl. The detection playbook for one doesn’t translate to the other.

A baseline worth actually using

The goal here isn’t to slow engineers down. It’s to make the safe path the easy path. The baseline we’re building toward at Webflow has two layers, and that distinction matters.

Platform controls are things you configure once at the org or account level that make it structurally harder to do the wrong thing by accident.

IAM least-privilege guardrails. The permissions available to team-level AWS accounts should be scoped by default. An engineer shouldn’t be able to provision a public-facing resource with a broadly permissioned role without hitting a guardrail. The guardrail doesn’t stop the work. It stops the worst version of the work from shipping silently.

Secrets manager enforcement. Hardcoded credentials in vibe-coded apps are not a hypothetical. They’re a near-certainty if you don’t make the right path obvious. Enforcing secrets manager usage at the infrastructure level removes the decision entirely from the individual engineer.

“The goal here isn’t to slow engineers down. It’s to make the safe path the easy path.”

VPN-gated deployment targets. Internal tooling should land behind your corporate VPN by default. If something genuinely needs to be public-facing, that should require an explicit decision, not an accidental default.

Process controls are what have to happen at the tool level before anything ships.

Automated baseline check. Before a security-informed human looks at anything, automatically run the code and the infrastructure configuration against your baseline. Flag violations, tier them by severity, and give the engineer specific remediation guidance. This is the layer a Claude skill or similar tooling can own. The human review then focuses on what the automated check surfaced rather than starting from scratch.

Security-informed code review with Security escalation. Every internally built tool that touches production infrastructure needs a human with security context to look at it before it ships. For lower-risk tooling, that’s a peer engineer who understands the blast radius of what they’re reviewing. For anything with cloud infrastructure, direct data access, or novel IAM roles, it escalates to a formal Security review. Same control, tiered by risk. The key point is that the reviewer actually needs to understand the code. With vibe-coded tools, the author may not fully understand what they built. That makes the review more important, not a formality. It’s not just a quality gate. It’s a comprehension gate.

The safety net

The baseline is preventive. Detection is what catches what slips through.

Your CSPM is the right tool for finding misconfigurations in what already exists. Wiz and tools like it will surface the public-facing endpoint, the over-permissioned role, the storage bucket without appropriate access controls.

But CSPM only finds what’s already deployed. The baseline and the review process are what you’re counting on to prevent that. Detection is the catch layer, not the first line.

The harder detection problem is knowing something exists in the first place. A vibe-coded tool running locally or in a team account may leave no trace in your normal visibility layer. No deployment pipeline. No change ticket. No asset inventory entry.

This is where behavioral signals in your cloud telemetry start to matter. IAM role creation outside your normal pipeline activity. New public-facing resources appearing without a corresponding change record. API calls originating from developer machines directly into production accounts rather than through your standard tooling. None of these signals are definitive on their own. In combination, they start to look like something that deserves a closer look.

Most teams aren’t looking for these signals specifically in the context of agent-built tooling. That’s the gap worth closing.

The codified baseline

Documentation that lives in a wiki is a baseline that nobody uses when they need it. The better path is to make the baseline available within the tools engineers are already using, at the point of building.

A Claude skill or similar AI-native tooling that reviews architecture descriptions or generated infrastructure against your specific security baseline is more useful than a checklist in Confluence. The engineer gets specific, actionable feedback before a human reviewer ever sees it. The security team gets a first pass that’s already been filtered for the obvious failures. The review is better because it starts from a more complete picture.

None of this works if engineers don’t know the skill or if the review process doesn’t exist. Awareness is its own prevention layer. Introducing both during onboarding makes the safe path visible, and letting the skill’s feedback do double duty as education on why each check matters makes it stick. A guardrail that doesn’t announce itself isn’t preventive.

That’s where we’re headed internally. The blog post is the argument for why this matters. The skill is what operationalizes it.

The takeaway

Vibe-coded internal tools are not going away. The friction that used to slow down ungoverned infrastructure is gone, and it’s not coming back. The question is whether your security baseline catches up before your CSPM does.

Platform controls make the safe path the default. Process controls make sure a human with security context sees everything before it ships. Detection gives you a catch layer for what slips through anyway.

“Build the baseline before the CSPM finds it for you.”

None of this requires a dedicated AppSec team or a SOC. It requires a clear baseline, the tooling to enforce it, and engineers who understand what they’re reviewing. That’s a problem a small, well-structured security team can solve. Platform controls are owned at the org or SecEng level, set once and applied everywhere. Process controls are distributed: a peer engineer with security context handles lower-risk tooling, while anything touching cloud infrastructure, direct data access, or novel IAM escalates to a formal Security review. That’s distributed responsibility with a clear escalation path, not a single team reviewing everything.

Build the baseline before the CSPM finds it for you.

This article was originally published on August 13, 2026, on webflow.com.

The post Vibe-coded apps are the new shadow IT appeared first on The New Stack.