MCP security gaps are widening as vibe coding scales fast

At a glance

What this is: This is an independent analysis of how vibe coding and default MCP settings create identity and access risk across AI-connected development workflows.

Why it matters: It matters because IAM, NHI, and agentic AI teams now need to govern tool access, scope, and visibility before insecure MCP patterns become embedded in production pipelines.

By the numbers:

• In July 2025, Knostic researchers found nearly 2,000 exposed MCP servers on the internet.
• 97% of developers had used AI tools in GitHub's 2024 survey.

👉 Read Descope's analysis of vibe coding security risks and MCP controls

Context

MCP security is becoming an identity problem as much as a development problem. When servers bind broadly, inherit excessive permissions, or accept unvetted tools, the control plane for AI-connected work becomes exposed before teams have a chance to review it.

The article's central warning is that convenience-first development habits create hidden access paths for AI tools and developers alike. That is why MCP governance now belongs alongside NHI, workload identity, and lifecycle controls rather than inside ad hoc developer workflow decisions.

Key questions

Q: What breaks when MCP servers are left on default network exposure settings?

A: Default network exposure turns a local development service into a remotely reachable attack surface. If an MCP server binds to all interfaces, anyone on the same network can interact with it unless additional network controls exist. That breaks the assumption that development convenience is harmless and makes interface binding a governance decision, not a coding preference.

Q: Why do MCP tools complicate least-privilege design for AI workflows?

A: MCP tools complicate least privilege because the model can only be safe if both the host access and the tool-level actions are constrained. A broad permission set can let an AI-connected workflow reach commands, files, or data it does not need. Teams must scope the tool, not just the user, or privilege creep will follow the integration.

Q: How do security teams know whether an MCP integration is operating outside its intended boundary?

A: Look for signs that the tool can reach more networks, files, or commands than its use case requires, or that server provenance is unclear. If the integration is accepted without clear ownership, version tracking, and scope review, it is already outside a governed boundary. Visibility into source, scope, and update history is the key indicator.

Q: Who should be accountable when an AI-connected development tool exposes sensitive systems?

A: Accountability should sit with the team that approves the tool's identity, scope, and distribution path, not only with the developer who uses it. For MCP, that means platform, security, and IAM owners need shared governance over onboarding, permissions, and recertification. If those controls are absent, no one can credibly own the resulting exposure.

Technical breakdown

Default MCP bindings and network exposure

MCP servers are often started with development-friendly defaults such as binding to 0.0.0.0, which makes the service reachable on every interface rather than only localhost. That is convenient on a laptop but dangerous on shared or public networks, because a local test service can become remotely reachable without the developer realising it. In identity terms, the server's exposure boundary is wider than its intended trust boundary. Once reachable, the next failure is not just connectivity but unauthorised interaction with tools and data paths that were never meant to be public.

Practical implication: force MCP services to bind to localhost by default and block any broad interface exposure unless it is explicitly justified.

Excessive permissions at the MCP layer

The article highlights a second, more serious failure mode: MCP servers can be granted broad permissions that exceed the task they are meant to support. When an AI-connected tool has command execution or file-system reach beyond its intended scope, the risk shifts from data leakage to host compromise. This is not just classic RBAC at the application layer. It is tool-level authorization for AI workflows, where the allowed action set must be constrained before the model or agent can act. Overscoping turns a helpful assistant into a high-impact execution path.

Practical implication: apply least privilege to MCP tools and scopes separately from user access, and review any command or filesystem permission as a high-risk grant.

Tool poisoning, spoofing, and unvetted server distribution

MCP expands the attack surface because tools, descriptions, and server identities are now part of the AI workflow. Tool poisoning occurs when malicious instructions are hidden in tool metadata that the model consumes but the user never sees. Server spoofing and rug-pull updates exploit weak provenance and change control, letting an attacker masquerade as a trusted integration or mutate a known-good package later. The core technical issue is trust without verification. In a fast-moving ecosystem, identity of the tool source matters as much as the tool's behaviour.

Practical implication: inventory MCP sources, verify provenance, and treat new or updated servers as governed identities rather than convenience plugins.

NHI Mgmt Group analysis

Developer convenience has become an identity control failure, not just a coding habit. The article shows how basic MCP defaults create exposed services, overscoped tools, and weak provenance in the same workflow. That means the trust model is failing at the point where AI-connected tools are introduced, before any advanced exploit is needed. Practitioners should read this as a governance boundary problem, not a developer training problem.

Tool-level authorization is the real control plane for AI-connected development. Traditional IAM can tell you who signed in, but it does not by itself constrain which tools an MCP-backed assistant can call or what scope those tools inherit. That is why RBAC must be extended into the MCP layer with explicit tool scoping and change control. The implication is simple: access to the host is no longer the only question; the tool inventory is now a privilege surface.

Tool poisoning is a named concept worth tracking because it describes invisible instruction abuse inside trusted context. Unlike obvious malware, tool poisoning works through metadata that the model ingests as part of normal execution. That makes detection harder and governance more important, because users can approve an integration without seeing the malicious instruction path. Practitioners should treat unseen tool context as a controlled identity surface, not a benign implementation detail.

Visibility into AI-assisted access must extend across the full lifecycle of the MCP relationship. The article correctly connects which users are working with which agents, which servers are in use, and what scopes and credentials are attached. That is lifecycle governance in practice, not just security telemetry. The implication is that teams need an inventory of agent-to-tool relationships that can be reviewed, recertified, and removed when no longer justified.

MCP security is moving toward governed identity infrastructure rather than developer-managed trust. As adoption grows, organisations will need controls that make insecure defaults harder to ship than secure ones. That direction aligns with OWASP NHI and zero trust thinking: establish identity, scope, and provenance before the tool is allowed to participate in a workflow. Practitioners should expect MCP governance to become a standard part of agentic platform design.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented any policies to govern AI agents, even though 92% agree that governing them is critical to enterprise security.
• That gap is why readers should also review OWASP Agentic Applications Top 10 for the control patterns most relevant to MCP-era tool risk.

What this signals

Tool-level governance is becoming the practical boundary for AI-enabled development. As teams add MCP servers and other agent-connected tools, they are no longer just managing developer productivity. They are managing which identities can invoke which tools, with what scope, and under what provenance rules. That means the next maturity step is not more review overhead, but a governed trust registry that can support recertification and deprovisioning.

With 80% of organisations already seeing AI agents act beyond intended scope in our research, the move from experiment to operational dependency is already creating control failures. The lesson for practitioners is to treat agent-connected tooling as a privileged identity surface and to align it with lifecycle controls, not informal repository trust.

Identity blast radius: this is the practical concept to watch as MCP adoption grows. When a tool can be discovered, copied, or updated outside a governed channel, the identity of the tool itself becomes part of the attack surface. Practitioners should connect this to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs and to the OWASP Agentic AI Top 10 when building policy and review gates.

For practitioners

• Harden MCP server exposure defaults Require localhost binding for development servers and block 0.0.0.0 unless a specific business justification is recorded and approved.
• Separate tool scope from user scope Define explicit tool-level permissions for each MCP integration so the assistant cannot inherit broad command, file, or data access by default.
• Inventory and recertify MCP server trust Maintain a live register of approved servers, owners, versions, and scopes, then recertify them on a fixed lifecycle cadence.
• Test for tool poisoning and spoofing Scan tool descriptions, package names, and update channels for hidden instructions, typosquatting, and silent changes before adoption.

Key takeaways

• MCP security failures are often caused by convenience defaults, not sophisticated exploitation.
• Exposed interfaces, excessive permissions, and unvetted tool sources combine into a measurable identity risk for AI-connected workflows.
• Teams should govern MCP servers as identities, with scope, provenance, and lifecycle controls that match their privilege level.

Key terms

• Mcp Server: An MCP server exposes tools and data sources to an AI application through the Model Context Protocol. In practice, it becomes a governed integration point whose exposure, scope, and provenance must be controlled like any other privileged non-human identity surface.
• Tool Poisoning: Tool poisoning is the abuse of tool metadata or descriptions so an AI model ingests malicious instructions that the user does not see. The danger is not only code execution but also covert steering of agent behaviour through trusted context.
• Tool-Level Authorization: Tool-level authorization is the practice of limiting which functions, actions, or resources an AI-connected workflow can invoke. It goes beyond user login by constraining the operational surface of the tool itself, which is essential when agents can act faster than human review cycles.
• Identity Blast Radius: Identity blast radius is the amount of damage that can result when an identity or tool is over-scoped, over-trusted, or reused too broadly. For AI-connected systems, it describes how quickly a compromised integration can spread access across data, commands, and dependent services.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact MCP misconfiguration examples discussed at the hackathon launch party, including default binding and overscoped permissions.
• The named tool-poisoning, spoofing, and rug-pull patterns that help teams threat-model untrusted MCP distribution.
• The practical security controls Descope associates with OAuth 2.1, PKCE, DCR, consent, and tool-level scoping for agentic flows.
• The session recap context from the Descope Global MCP Hackathon Launch Party and the referenced speakers.

👉 Descope's full post covers the MCP attack patterns, configuration pitfalls, and developer-centric controls in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.