AI Agents in Production: Identity Auth, MCP, and Agent Readiness in Practice

Bringing AI Agents from demo to production is a challenge no enterprise can sidestep today. In an episode of the podcast Everything Outside Code, Kevin Gao, Head of AI Strategy at Descope, shared a key observation: when you connect an agent to real systems, "identity and authorization" is consistently the most overlooked — and most critical — piece of the puzzle. The numbers he cited are equally striking: by routing support tickets through agents, human-intervention incidents dropped by roughly 70–80%.

This article distills the core insights from that conversation: how enterprises should think about agent identity, MCP authorization design, and when a product needs to be "agent-ready."

From Demo to Production: The Real Challenge Isn't the Shiny Demo

Kevin opened with a blunt observation: building a flashy demo and shipping an agent into a real production environment are two entirely different things. In a demo, you control everything. In the real world, there are constraints, and the system runs in an environment you can't fully control.

Most failures in the demo-to-production journey stem from a skipped step: building the backend authorization architecture. He noted that many people building MCP servers only handle "logging in to MCP" but never define fine-grained permissions for tools. Similarly, many cloud connectors offer almost no control over what a user can and cannot have an agent do on their behalf.

"Actually taking the time to properly architect and understand authorization, and implementing those authorization controls in the backend — that's the step most customers skip or never even think about," Kevin emphasized. Yes, it adds considerable complexity, but the payoff is strong control over agent behavior — which is precisely the point.

Agent as a User vs. on Behalf of a User: The Fundamental Identity Split

The vast majority of agents today (Codex, Claude's Cowork, etc.) operate as a specific user — with permissions mirroring that user one-to-one. Kevin sees this as a liability: you can't distinguish between "what the agent can access" and "what the user it represents can access."

His core principle: you need to be able to tell whether an agent is acting as a user or on behalf of a user. Once an agent has its own distinct identity, you can define permissions for it independently — for example, allowing it to read all Google Docs but preventing it from creating new documents visible to others.

Kevin also highlighted a major revision to the MCP spec: the authorization server has been decoupled from the MCP server. This means any company exposing APIs or products to agents can require the agent to first go through an authorization server — completing identity registration, user login, and explicit authorization — before embedding both "user context" and "agent context" into the token. Whether it's an e-commerce site, a B2C website, or a B2B SaaS product like Datadog, this mechanism provides real guardrails.

Why Agents Shouldn't Be Treated as Users

Take e-commerce as an example: you might want shopping agents to access and log into your site, but you absolutely don't want to hand them a password or have them treated as the actual person — like freely placing orders. The same logic applies in B2B contexts. Kevin's view: "Almost every company should be able to distinguish between users and agents. The only real question is how to implement it and how easy it is to do."

---

What is MCP? MCP (Model Context Protocol) is an open protocol proposed and championed by Anthropic to standardize how AI models interact with external tools and data sources. Think of it as the "USB port" of the AI world — any tool or service that implements an MCP server can be called by any MCP-compatible agent, without building a separate integration for each model. MCP's approach to authorization has evolved significantly: early versions often embedded authentication logic inside the MCP server itself, while the revision Kevin describes decouples the Authorization Server, aligning it with standard protocols like OAuth 2.0. The core value of this separation: the MCP server focuses solely on exposing tool capabilities, while identity verification and permission control are handled by a dedicated authorization server. This allows a token to carry both "user context" (which human user originated this request) and "agent context" (which agent is acting on their behalf), laying the groundwork for fine-grained permission control.

---

Support, Documentation, MCP: The Three Pillars of Agent Readiness

The most actionable part of the conversation was Kevin's breakdown of "agent readiness." In his view, preparing a product for the agent era requires building across three dimensions:

The first pillar is Support. This is often where the transformation begins. By introducing a documentation MCP server and a support agent, Descope was able to resolve 70–80% of support tickets that previously required human intervention — automatically.

The second pillar is Documentation. Documentation used to serve developers, functioning as both an activation and acquisition tool. Today, its primary consumers are increasingly AI agents. Kevin cited data showing that over 60% of visitors to documentation sites like Mintlify come from AI agents. This means docs need to be structured in easily parsable formats like Markdown and optimized for "Agent SEO." He also emphasized that documentation isn't just traditional docs — it includes "skills" that encapsulate implementation knowledge, especially for migrations and edge cases. Skills that agents write themselves often need human refinement, but once deployed, their scalability is unlimited.

The third pillar is an MCP server for the product surface. A sufficiently detailed, well-specified MCP enables customers to complete onboarding with almost no human assistance. Kevin gave the example of a customer who migrated fully from another auth vendor to Descope in a single day — a company that size would typically require extensive hands-on professional services.

---

What is Agent SEO? "Agent SEO" is an extension of traditional search engine optimization. Traditional SEO aims to get web content ranked highly by crawlers from Google and similar search engines. Agent SEO is about getting your product's content captured and understood by large language models — either through their training data or real-time retrieval. The two are fundamentally different: search engines rely on keyword matching and link authority, while LLMs prioritize content structure, semantic clarity, and technical accuracy. Agent SEO practices include: presenting documentation in Markdown rather than rich HTML (easier for models to parse), providing complete API references and code examples (enabling models to generate working code), and maintaining public MCP server specs (allowing agents to discover and call tools directly). Kevin's point about being "baked into the model's training data" represents the ultimate expression of this logic — when documentation quality is high enough, the model internalizes product knowledge during pre-training and can accurately recommend it at inference time without needing to search the web.

---

The Underrated Acquisition Channel: Getting Into the Model's "Knowledge Base"

Kevin shared a striking set of numbers: a year ago, actual closed deals coming through AI channels accounted for less than 1%. Today, that figure has reached roughly 15%. These are often small companies that had never heard of Descope — they simply asked Claude, "I want to add Passkey MFA to my app, what's the best option?" and Claude recommended Descope.

The deeper insight: what's actually driving this is getting product information "baked into" the training data of large models. When a model like Opus absorbs Descope's documentation and MCP knowledge during training, it can determine that Descope outperforms competitors internally — without needing to search the web. "If you ask about Descope, it doesn't do a web search at all — its understanding of Descope and its competitors is already sufficient."

This also explains why solid documentation matters so much for any SaaS product: as more people use agents instead of browsing the web directly, "whether the model knows you" is almost a matter of product survival.

---

What are Passkeys and MFA? Passkeys are a passwordless authentication method based on the FIDO2/WebAuthn standard. They use the device's built-in biometrics (Face ID, fingerprint) or PIN to generate a cryptographic key pair, with the private key never leaving the user's device. Compared to traditional passwords, Passkeys are inherently phishing-resistant because the key is bound to a specific domain and cannot be stolen by a spoofed site. MFA (Multi-Factor Authentication) is a security mechanism that requires an additional verification factor beyond username and password. Kevin's example — a user asking Claude "what's the best way to add Passkey MFA to my app" — perfectly illustrates the typical AI-channel acquisition path: developers building authentication features increasingly ask a large model first rather than searching the docs directly, making "whether the model understands your product" a direct factor at the very top of the sales funnel.

---

Getting Large Enterprises to Adopt: Prove End-to-End Value

For large, conservative organizations still sitting on the fence, Kevin's advice is clear: demonstrate real, end-to-end value.

He shared a case study: a junior engineer at a large insurance company used Descope's MCP server and tools to build out the entire authentication experience the product manager had envisioned — in about two hours, even spinning up a Next.js demo app. Senior engineers who had been skeptical quickly changed their stance after seeing the results, and the overall migration timeline was dramatically compressed.

"In a world awash with AI hype, ROI on a lot of projects is hard to measure. But if you can show end-to-end, very early on, just how fast and how cheap this is — people get it," Kevin said. For large enterprise customers, he's observed deployment timelines shrink from months to one or two weeks — at minimum cut in half, often more.

When Can You Ignore Agent Readiness?

When asked when a team can safely skip these investments, Kevin was candid: for a SaaS product today, completely ignoring agent readiness is almost "unimaginable."

If you truly have to prioritize, he offered two baseline recommendations:

• Invest in documentation: This is the highest-leverage move. Models crawl the web during training, so solid documentation means you'll be baked into the model — ensuring at minimum basic discoverability.
• Leave a "side door" for agents: Provide a relatively simple way for agents to authenticate and assert their identity, without requiring users to hand over passwords or OTPs to the agent. Efforts like Cloudflare's Web Bot Auth are still progressing, but even building this yourself delivers enormous control.

"Too many people today simply don't do this — they just let agents impersonate users," Kevin pointed out. Once you establish a clear distinction between users and agents, you'll be positioned to handle whatever new requirements emerge. This isn't just about auditability and observability — from an identity perspective, it's a necessary defense against agent misuse of customer accounts.

Closing Thoughts

Kevin's message is clear: when it comes to getting AI agents into production, technical "flashiness" matters far less than getting identity and authorization right. Recognizing the difference between a "user" and an "agent acting on behalf of a user" is the foundation for every guardrail, audit, and permission control. Meanwhile, the three-pillar investment in support, documentation, and MCP is already delivering measurable changes in acquisition and delivery efficiency. For any product team — even one not ready to fully embrace agents yet — the minimum viable move is to leave them a recognizable, controllable "side door."