Table of Contents
This post is part of our session recap series from the Descope Global MCP Hackathon Launch Party. You can catch the recording of all sessions here.
Aparna Sinha, Senior Vice President of Product at Vercel, has deployed agentic AI in two very different contexts: building a platform for a regulated bank at Capital One, and shipping Vercel’s public MCP server earlier this year. She’s navigated both the strict requirements of compliance-minded enterprises and the reality of launching a public-facing MCP server that developers actually use.
At the Descope Global MCP Hackathon Launch Party, Sinha discussed what Vercel learned from going live with their MCP server, and the architectural decisions that determined how it all came together. Her experience surfaced several challenges that aren’t getting enough attention.
This article draws from these observations to provide three key lessons for those deploying agentic AI at enterprise scale:
Read-only vs. write access is an essential security decision
Multi-user agents need purpose-built identity infrastructure
Big platforms are waiting on business models, not solving technical problems
Let’s explore how these core considerations affect whether agentic projects make it past their proof of concept stage.
Read-only vs. write access is an essential security decision
Vercel’s MCP server launched with a deliberate constraint: it’s read-only. You can view your deployments, check logs, inspect your team structure and projects. You cannot, however, trigger new deployments or modify anything. This was a conscious security decision.
“Obviously, we would like to make it more active,” Sinha explained. “We’d like people to be able to make deployments, but that is pretty complicated.”
Vercel also chose to deploy a remote server rather than a local one. Most companies that have shipped MCP servers went local, which gives developers more responsibility and shifts liability away from the provider. Vercel decided the remote approach would be more useful, but that raised the stakes on security. Read-only access was part of how they managed the risk.
The result is an MCP server that works for troubleshooting and inspection without exposing write operations to whatever client happens to be connected. This is especially crucial for the current MCP ecosystem, which relies heavily upon slightly niche client registration modalities, like the open system of Dynamic Client Registration (DCR) or the more recently adopted Client ID Metadata Documents (CIMD).
As Sinha noted, Vercel supports connections from Claude Code, Cursor, and VS Code. Each of those clients has different trust models, so read-only access ensures that the potential harm from misuse or unexpected behavior is minimal (regardless of which client is calling).
This principle echoes what Andre Landgraf emphasized in his MCP security presentation at the same event: “If nothing can ever write, then it’s hard for an LLM to screw up. All it can do is compose.” The question isn’t what an AI agent could theoretically do with tool access; it’s what happens when it goes off the rails unsupervised.
Multi-user agents need purpose-built identity infrastructure
Traditional authN and authZ assume human presence. You authenticate the user, check their permissions, grant or deny access. Agentic systems promise AI systems with at least some level of autonomy (meaning human absence), fundamentally breaking this model.
Sinha described the challenge Vercel encountered with Devin, the coding agent from Cognition Labs. Some Vercel users employ Devin to perform operations on their behalf, and Devin can operate in shared Slack channels where multiple team members interact with it.
“We don’t know who is actually accessing Devin,” Sinha explained. “Devin is performing operations on Vercel on behalf of this team, and maybe not the entire team should have access to all of it. Maybe not the entire team are actually [Vercel] users.”
The questions stack up quickly: Which team member initiated the request? Are they a paying Vercel user, or not? Do they all have the same permissions, or just some? When an agent acts on behalf of a group, whose identity gets propagated through the tool chain?
Vercel’s MCP server has OAuth enabled, but OAuth alone doesn’t answer these questions. The MCP authorization spec formally adopted OAuth 2.1, which provides proven foundations and flexibility. But it also calls for requirements that exceed many organizations’ immediate expertise and willingness to tackle: Proof Key for Code Exchange (PKCE), DCR/CIMD, token storage, and scope management across agent interactions.
What’s really needed is visibility into how agent identities link to human identities, scoped actions tied to explicit user consent (i.e., human in the loop), and access control that governs which tools are available before they’re ever invoked.
Simply put, traditional IAM wasn’t designed for contexts where an AI intermediary acts on behalf of multiple users with different permission levels. Solving problems like Vercel’s challenge with Devin requires purpose-built infrastructure that treat agentic identity as its own concern rather than repurposing existing auth flows.
Big platforms are waiting on business models, not solving technical problems
Vercel doesn’t charge for agents to access its infrastructure. “So, we don’t even have a pricing model for that,” Sinha acknowledged. For a developer platform, that’s normal: Agent access to deployment logs doesn’t threaten their core business. They shipped a read-only MCP server and kept moving toward better developer tooling that could support that evolving ecosystem.
For other platforms you’d expect to lead the charge, however, the calculus is quite different. An audience member raised a question as to why certain big-name organizations haven’t fully rolled out MCP servers. Why are many enterprises holding back on building with MCP?
Sinha distinguished between technical and strategic barriers: “I believe the technical challenges are the smaller ones. The big challenge is, if you open up your MCP server, you open up your data to anybody to consume. Then what?”
The concern isn’t isolated to authentication or OAuth flows. There’s a series of monetization hurdles these platforms need to see resolved first. They see an opportunity in building agents themselves, not just providing ways for others to build on top of an MCP server.
Until there’s a monetization model that accounts for this, and keeps the revenue opportunities in-house, the big players will likely wait it out.
But not all large enterprises are waiting with them. “Most of our customers today are focused on internal use,” Sinha observed. “They are standing up their own MCP servers with API access. It’s not very hard. You can absolutely build an MCP server—in fact, vibe code an MCP server—and host, then go from there.”
The takeaway is clear: If your agentic AI strategy depends on a major player shipping an MCP server, you’ll be waiting along with them. The technical barriers are significant, but solvable. For now, however, the business model considerations are not.
Moving from proof of concept to enterprise-scale agents
Sinha’s parting prediction was succinct: “Everything is going to go agentic.” The question we’re facing today isn’t whether organizations are going to deploy agentic AI en masse, but whether your big agentic idea will get into production before someone beats you to the punch.
The three lessons we discussed here aren’t blockers in any lasting sense. They’re considerations for how you’ll need to navigate the next steps toward production-readiness. Organizations that treat these as directions on a map will ship their agents sooner, and those that see them as warning signs will keep waiting for a perfect moment that never comes.
The common thread is identity: treating agents as their own distinct identity, linked to a human identity, to make them traceable (and monetizeable). Read-only access is a stopgap until granular, appropriately scoped permissions make agents trustworthy enough for write operations. The multi-user agent problem doesn’t go away until you can trace agent actions back to specific users with their own permissions. And enterprises can’t build or monetize their own MCP servers without auth infrastructure that handles OAuth 2.1, client registration, and tool-level access control.
Descope’s Agentic Identity Hub was built to solve these specific problems. It provides the identity infrastructure layer that helps organizations:
Protect MCP servers with spec-compliant OAuth 2.1, PKCE, DCR, user consent flows, and tool-level scoping
Enable AI agents to easily connect with 50+ third-party solutions without worrying about token management or storage
Provision and manage AI agent identities alongside user identities
Whether you’re shipping your own MCP server or connecting agents to external systems, Descope will handle the auth infrastructure so you can focus on building the next big thing.
Sign up for a Free Forever Descope Account to start mapping enterprise-grade MCP auth flows, or book a demo to see how Descope can get your agentic architecture from proof of concept into production.
