Ten-Second Version
MCP (Model Context Protocol) is an open standard that lets AI agents connect to enterprise tools through a single universal interface. Instead of custom integrations per tool, one protocol handles them all. Your buyer cares because adoption is accelerating across their vendor ecosystem and the identity governance layer doesn't exist by default.
Read the Room
The buyer said "MCP." Before you respond, figure out which buyer you're talking to.
Exploring (Level 1):
- MCP comes up alongside other buzzwords: agentic AI, copilots, orchestration
- Future tense: "we're looking at," "we're thinking about"
- Asks what you're doing about it
- No specific frameworks or dev teams mentioned
Building (Level 2):
- Names specific MCP servers, frameworks, or custom builds
- Present tense: "we're running into," "our team is hitting"
- References a POC, a pilot, or their dev team by name
- Mentions auth, tokens, or service accounts in the same sentence as MCP
Level 1: You own this conversation. Teach them the governance gap below.
Level 2: Hold the conversation for two minutes using the governance gap framing, then hand off to your SE. Their dev team has questions you should not attempt to answer.
The Governance Gap
Adoption is real and moving fast. The MCP protocol maintainers themselves acknowledge that enterprises are already "deploying MCP and running into a predictable set of problems" (2026 MCP Roadmap). The 2026-07-28 release candidate is the largest revision since launch, with Tier 1 SDKs expected to ship support within ten weeks. People are building on this in production right now.
Here's what production looks like without governance:
- A developer stands up an MCP server to give an agent access to a tool (Slack, a database, a ticketing system).
- That server authenticates with a shared service account or static API key. The MCP spec treats authorization as optional for local deployments.
- Every user interacting through that agent shares the same credential.
- No per-user authorization. No way to trace a specific action to a specific person. No way to revoke one user without revoking everyone.
"The pattern we're seeing is agents connecting to enterprise resources through shared credentials with no individual identity, no scoping, and no audit trail. That's the governance gap MCP creates."
Level 1 buyers need to hear this framed as risk they haven't quantified. Level 2 buyers already feel it. Either way, you just moved the conversation from developer tooling to identity governance. Stay there.
Protocol Instability Works in Your Favor
The release candidate dropped May 21. The final spec publishes July 28. That's the deadline that matters.
The protocol is going stateless at the transport layer. Every MCP server currently tracking session IDs needs to be redesigned. Auth handling is being realigned with OAuth/OIDC. Error codes are changing. Biggest breaking change since the protocol launched.
"The MCP spec ships breaking changes on July 28. Any governance you build above the protocol protects you from having to re-engineer every time the spec shifts underneath."
What Okta Delivers (Be Precise Here)
The MCP maintainers have publicly acknowledged the enterprise gaps: audit trails, SSO-integrated auth, gateway behavior, and configuration portability. They've explicitly stated these will land as protocol extensions, not core spec (2026 MCP Roadmap). So the protocol leaves these problems for someone else to solve, and the buyer needs to know who.
Those gaps map directly to what Okta ships today. GA as of April 30, 2026. Position with confidence:
- Audit trails → Audit logging of agent activity and tool calls, SIEM integration, full revocation history
- SSO-integrated auth → Register agents and MCP servers in Okta Universal Directory with a human owner assigned to each; enforce least-privilege through API Access Management with dynamic policy evaluation
- Gateway behavior → Automated access reviews, certification workflows, and instant kill switch for agent identities
- Discovery → Find unknown agents and shadow MCP connections across the environment
These are confirmed GA capabilities.
These capabilities are not confirmed GA. Check with your SE or federal team before positioning them as available: Agent Gateway (virtual MCP server / aggregation proxy), Cross-App Access (XAA) for propagating user identity through agent chains (Early Access only), and FedRAMP authorization covering Okta for AI Agents specifically (not publicly confirmed; Okta Identity Governance is FedRAMP High, but AI Agents coverage requires federal team confirmation).
The line between "confident" and "verify first" matters. An overclaim on GA status in a federal account follows you for the life of the opportunity.
Federal Hook
NIST's NCCoE published a concept paper on February 5, 2026 that names MCP alongside OAuth 2.0 and OIDC as protocols requiring identity governance for AI agents. It identifies the shared-service-account pattern as an anti-pattern that breaks auditability.
"NIST's NCCoE published a concept paper in February that specifically names MCP as a protocol requiring agent identity governance. I can send you the CSRC link."
Be clear with yourself: this is a concept paper proposing a demonstration project. Federal direction, not federal requirement. Frame it accordingly and you keep your credibility.
SLED Adjustment
The NCCoE citation carries less weight with state and education buyers. The governance gap argument carries more. SLED orgs typically have less visibility into what dev teams are standing up, smaller security teams, and compliance drivers that are state-specific (state privacy laws, FERPA for education, state auditor requirements). If a SLED buyer mentions MCP, the discovery capability is your lead: "Do you have visibility into how many MCP servers are already running in your environment?" That question lands harder when the honest answer is no.
CyberArk
CyberArk has announced MCP integration. See the CyberArk competitive card before engaging on their MCP story.
What Not to Say
- Do not describe Okta as "an MCP platform" or claim Okta implements the MCP protocol. Okta governs agents and MCP servers, which is a fundamentally different job.
- Do not offer implementation guidance on MCP server architecture.
- Do not make protocol-level claims about how MCP auth works internally.
- Do not position Early Access features or unverified capabilities as GA.
- Do not claim FedRAMP coverage for AI Agents capabilities without federal team confirmation.
When to Hand Off
Tag in your SE the moment the conversation moves to MCP server architecture, specific integration patterns, token exchange mechanics, OAuth flow details, XAA implementation, or Agent Gateway deployment.
You've done your job when the buyer sees the governance gap clearly and sees Okta as the answer to it. Your SE takes the technical conversation from there.
Things to follow up on...
- MCP security incidents already: The Coalition for Secure AI documented real-world MCP breaches including Asana's tenant isolation flaw affecting up to 1,000 enterprises and WordPress plugin privilege escalation hitting over 100,000 sites, detailed in their practical guide to MCP security.
- NIST red team results: NIST's empirical research found novel attack strategies against AI agents achieved an 81% success rate in red-team exercises, a stat worth bookmarking from the Cloud Security Alliance's analysis of NIST's emerging standards work.
- Microsoft Agent 365 bundling: Microsoft's Agent 365 plan went GA May 1 at $15/user/month and bundles Entra Agent ID for agent governance, creating a "why buy separately?" objection you should understand via the Microsoft Entra Agent ID documentation.
- CyberArk's MCP play specifics: CyberArk's product docs now show dedicated MCP Server and AI Agent workload types in Secrets Manager, meaning they're positioning at the credential layer for MCP connections as detailed in their Secure AI Agents documentation.