Vercel OAuth breach exposes the governance gap in MCP security

At a glance

What this is: A third-party AI tool breach led to exposed OAuth tokens and unauthorized access into Vercel’s internal environment, exposing how connected AI tools can widen identity trust boundaries.

Why it matters: IAM, NHI, and AI governance teams need to treat employee-authorised tool connections as governed access paths, not one-time setup choices, because compromise at the edge can cascade into core systems.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Obot's analysis of the Vercel OAuth breach and MCP security exposure

Context

MCP security is emerging as an identity governance problem, not just an application integration problem. When an employee grants OAuth access to an AI productivity tool, the organisation is extending trust into a third-party identity path that can later be used to reach core systems.

The Vercel incident shows how a compromise in that third-party path can bypass the downstream company’s own infrastructure controls. The immediate question for NHI, IAM, and platform teams is not whether tools are useful, but whether their access has been centrally inventoried, scoped, and revocable.

This pattern is increasingly typical in organisations that adopt AI tools quickly and connect them directly to Google Workspace, GitHub, deployment pipelines, and secrets-bearing environments. What looks like a convenience layer becomes a standing trust boundary unless lifecycle governance is applied.

Key questions

Q: How should security teams govern AI agents that use OAuth access?

A: Security teams should inventory each agent, limit scopes to the minimum required, assign an owner, and monitor its behaviour continuously. They should also define revocation steps before an incident occurs, because delegated OAuth access can become a lateral-movement path when an agent is compromised. Governance should cover discovery, approval, review, and offboarding as a single control loop.

Q: Why do AI agents create more identity risk than ordinary SaaS integrations?

A: AI agents can operate continuously, chain multiple tools, and act on delegated permissions with little human oversight. That makes their effective privilege broader than the original approval suggests. The risk is not only access, but the speed and persistence with which the agent can turn access into credential exposure or lateral movement.

Q: What breaks when OAuth grants are never revisited after initial setup?

A: Stale grants preserve access long after the original business need has changed, which means a compromised token can still reach systems no one actively intended it to reach. Without periodic review, employees can accumulate third-party permissions that become invisible but highly reachable attack paths.

Q: Who is accountable when a sanctioned AI tool causes a data breach?

A: Accountability should sit with the owner of the identity and permissions behind the tool, not only the team that approved the application. If a sanctioned AI workflow can reach sensitive data, the organisation must govern its access path, logging, and containment as rigorously as any other high-risk identity.

Technical breakdown

OAuth token exposure in AI tool supply chains

OAuth gives a third-party application delegated access to a user’s account without sharing the password. In this case, the AI tool held tokens that were later exposed, turning a routine authorisation into a reusable credential path. That matters because the attacker did not need to defeat Vercel’s primary authentication stack. They only needed one valid delegated token tied to an employee account, then a path from that account into connected systems. The real technical issue is that OAuth scope and downstream reach are often broader than operators remember after setup.

Practical implication: inventory every third-party OAuth grant tied to employee accounts and review the exact scopes currently enabled.

Why connected AI tools create identity blast radius

A connected AI tool can sit between a human identity and multiple enterprise platforms, including Google Workspace, GitHub, deployment services, and collaboration tools. If that intermediary is compromised, the attacker inherits the permissions already granted to it, not the permissions security teams think they are managing centrally. This is why the blast radius is determined at connection time. Without a control plane, the organisation has no single place to see what the tool can reach, no uniform policy layer, and no clean revocation point when risk changes.

Practical implication: route high-trust integrations through a governed access layer rather than allowing direct, persistent tool-to-system grants.

MCP gateway architecture and least-privilege enforcement

Model Context Protocol matters here because it standardises how AI systems connect to tools and data sources. That standardisation is useful, but it also concentrates risk if every connection is treated as a permanent permission. A governed gateway changes the architecture by mediating tool access, enforcing scoped permissions, and logging use against policy. In identity terms, this is connection-layer governance for machine-mediated access. It does not eliminate compromise, but it makes access auditable, revocable, and easier to contain when an upstream tool is breached.

Practical implication: apply least privilege at the connection layer, not just at the account or application layer.

Threat narrative

Attacker objective: The objective was to move from a compromised delegated credential into internal systems and sensitive development or deployment data.

1. Entry occurred when the attacker obtained OAuth tokens exposed through a breached third-party AI productivity tool.
2. Escalation followed when the token was used to access an employee’s Google Workspace account and then pivot into Vercel’s internal environment.
3. Impact extended across environment variables and integrations such as GitHub and Linear, with potential downstream exposure to deployment and npm-related assets.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Connection-layer governance is now part of identity security, not a side concern. The Vercel case shows that the most dangerous trust boundary may sit between an employee and the third-party AI tool they approved months earlier. That boundary can outlive the original risk assessment, the original role, and the original operational need. For practitioners, the important shift is that access governance must extend to connected tools, not stop at the primary workforce account.

Persistent OAuth grants create identity blast radius that security teams rarely model well. The problem is not simply that a tool was compromised. The deeper issue is that a delegated grant can preserve broad reach long after the business need has changed. That makes this a lifecycle problem as much as an access-control problem, because grants created at onboarding often remain untouched through role changes and environment expansion. The practical conclusion is that OAuth lifecycles need the same discipline as other NHI credentials.

Model Context Protocol use cases expose a governance gap the market has only started to name. When AI tools connect to data and actions through standardised protocols, the security question becomes who can reach what, under what policy, and through which revocation point. The named concept here is identity blast radius: the amount of enterprise access that can be inherited from one compromised tool connection. For identity programmes, the lesson is that standardisation without policy control simply makes overreach easier to repeat.

NHI and IAM teams need to stop treating employee-approved tools as low-risk shadow integrations. The identity subject is still a human account, but the security behaviour is machine-mediated access that can touch code, secrets, and deployment systems. That means human IAM, NHI governance, and platform security now intersect in the same control plane. The implication is clear: governance models built only for user login events will miss the access path that actually matters.

The attack pattern validates centralised revocation as a core control, not a convenience feature. If one compromised third-party tool can reach multiple internal services, then revocation has to be immediate, visible, and scoped to the integration layer. That is the point where IAM, PAM, and NHI governance converge. Practitioners should treat revocation latency, not just credential strength, as a material risk measure.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which leaves most integrations over-permissioned by default.
• If you are mapping this risk to guidance, start with OWASP Non-Human Identity Top 10 for the credential and privilege patterns that make these breaches persistent.

What this signals

Identity blast radius is the right lens for AI-connected tooling: once a third-party integration can reach workspace, code, and deployment systems, compromise of the tool becomes a multi-system access event. Security teams should measure how many grants can be revoked from a single control point and how quickly they can do it.

With 53% of MCP servers exposing credentials through hard-coded configuration values, the governance problem is already visible in the underlying integration layer, not just in the user-facing app. That is why connection-layer policy should sit alongside the principles in OWASP Non-Human Identity Top 10.

For identity programmes, the next maturity step is to treat AI tool onboarding like any other privileged access lifecycle event. If the grant cannot be inventoried, recertified, and revoked, it is not a managed entitlement, it is residual trust waiting to be abused.

For practitioners

• Audit all employee-connected AI tool grants Build a live inventory of OAuth grants attached to workforce accounts, including coding assistants, productivity tools, and collaboration apps. Record scopes, last-used dates, owning teams, and revocation paths so you can remove stale access quickly.
• Move high-trust integrations behind a control layer Route access to Google Workspace, GitHub, deployment systems, and secrets-bearing tools through a governed connection layer that can enforce policy and revoke access centrally.
• Review secrets exposure in connected environments Check environment variables, deploy keys, API tokens, and integration credentials for anything reachable through AI-connected workflows, then rotate the exposed items at the source rather than only in the consuming service.
• Tie OAuth grants to lifecycle reviews Add third-party tool access to access recertification, role change, and offboarding processes so grants are reviewed when risk or job function changes, not only when a user reports a problem.

Key takeaways

• The Vercel incident shows that a compromised AI productivity tool can turn one OAuth grant into a broad internal access path.
• The underlying control failure is lifecycle blindness: third-party tool permissions persist after the original risk assessment is obsolete.
• Centralised inventory, scoped revocation, and connection-layer policy are now core identity controls for AI-connected environments.

Key terms

• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• OAuth Grant Lifecycle: OAuth grant lifecycle is the process of approving, reviewing, scoping, and revoking third-party application access over time. It matters because a valid grant can become a long-lived entitlement if teams do not track ownership, scope drift, and offboarding with the same discipline used for other identities.
• Connection-Layer Governance: The controls that sit between an application or AI tool and the enterprise systems it can reach. It combines scope enforcement, centralized visibility, logging, and revocation so that third-party access stays auditable and recoverable.

What's in the full analysis

Obot's full research post covers the operational detail this post intentionally leaves for the source:

• A step-by-step account of how the OAuth token exposure enabled the pivot from the AI tool into employee-linked enterprise systems.
• The specific environment variable and integration exposure details that shape incident response and post-breach scoping.
• The source article's own remediation guidance for Vercel-related environments, including token rotation and sensitive variable handling.
• The vendor's discussion of MCP gateway architecture and why it changes the connection-layer trust model.

👉 Obot's full post covers the breach chain, exposed integrations, and the governance implications for AI tool access.

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 building or maturing an IAM programme, it is worth exploring.