MCP Finally Gets an Enterprise Control Plane

.png)
Why SSO for AI Agents Is Bigger Than Another Product Announcement
Core thesis: Enterprise-managed authorization does not only make Claude connectors easier to deploy. It moves MCP governance into the identity layer, creating a path for SSO, revocation, and just-in-time access for AI agents - while making shadow MCP the next major enterprise risk.
When Anthropic and Okta announced enterprise-managed authorization for MCP connectors, it would be easy to view it as another integration announcement.
I think it is much more than that.
Anthropic has already shown, more than once, that when it introduces a new architectural pattern for AI, the rest of the industry pays attention. MCP is the best example. When Anthropic introduced the Model Context Protocol in November 2024, I was skeptical. Not because the idea was not powerful, but because it was too powerful.
MCP created a universal way for AI assistants and agents to connect to tools, systems, data, and workflows. That is exactly what enterprises need in order to make AI useful. But it also opened the door to a new class of risks: AI supply chain attacks, shadow tooling, unmanaged tool access, and new authorization bottlenecks. In some cases, it created the risk of bypassing the very controls security teams have spent years building around zero trust, least privilege, and identity governance.
At the time, I was not sure MCP would survive.
I was wrong.
MCP did not just survive. It became one of the fastest-adopted standards in the AI ecosystem. Other vendors, including OpenAI and many agent orchestration platforms, adopted it. SaaS vendors began exposing their own MCP servers. Enterprises began asking for it. Developers started treating MCP as the default integration layer between agents and applications.
And now, with enterprise-managed authorization, MCP is entering its next phase: enterprise governance.
The real announcement is not Okta plus Claude. It is MCP plus identity.
The important part of this announcement is not that one identity provider is now connected to one AI assistant.
The important part is that authorization for MCP is starting to move into the identity layer enterprises already trust.
Until now, many MCP connections followed a familiar but problematic pattern: an admin could enable a connector, but individual users still had to authorize access themselves. That creates friction for users, but more importantly, it creates fragmentation for security teams. Who connected what? Which tools are available to which users? What happens when a user changes roles? What happens when an employee leaves? What happens when an agent continues to operate with old access?
Enterprise-managed authorization changes that model. Instead of every user connecting every tool independently, admins can authorize connectors centrally. Users and their agents inherit access based on IdP groups and roles. Revocation can happen through the same identity workflows already used for SaaS applications. Access to MCP connectors becomes part of the enterprise identity lifecycle, not a separate surface area.
That is a big shift. It means MCP is starting to look less like an uncontrolled developer convenience and more like an enterprise-ready access model.
SSO is not dead. It is becoming the control plane for agents.
Over the past year, I have heard many people argue that traditional controls like SSO are not enough for AI agents.
I agree with part of that argument.
For on-prem environments, local tools, custom workflows, and agentic systems operating outside the SaaS control plane, traditional identity controls will need significant adaptation. Agents introduce new questions: Who is acting? On whose behalf? With what intent? Against which resource? For how long? Under what policy?
But in SaaS, the story is different. In SaaS, SSO is still alive and kicking.
This announcement proves it. The enterprise does not need to throw away the identity stack in order to govern AI agents. It needs to extend it. The same IdP groups, roles, lifecycle policies, and revocation paths that govern human access can also become the foundation for agent access.
That does not solve every AI security problem. But it solves an important one: bringing MCP access back into the enterprise governance plane.
It also creates a path toward something even more powerful: just-in-time access for agents. If MCP connectors can be governed through SSO and identity groups, then granting an agent access to a tool can become a workflow step. Need an agent to analyze tickets in Jira for the next 30 minutes? Grant scoped access. Need it to query a data warehouse for one task? Approve just-in-time access. Need to revoke it after the workflow completes? Automate it.
That is where this is heading.
The next problem is not MCP. It is shadow MCP.
The biggest risk now is not that enterprises will use MCP. They will.
The bigger risk is that they will use it without knowing where it exists.
This is the same pattern we have seen for years with SaaS. Enterprises invested heavily in SSO, yet every organization still has shadow SaaS and local accounts. Users create direct accounts. Departments adopt tools outside IT. OAuth connections accumulate. Service accounts live forever. Local admin access survives long after offboarding.
MCP is going to follow the same path.
Even if enterprise-managed authorization becomes the standard, there will still be MCP servers connected locally. There will still be developer-built connectors. There will still be personal tokens. There will still be agents connected to tools outside the IdP. There will still be local accounts and unmanaged authorizations that security teams cannot see.
In other words, the MCP governance problem will become the shadow MCP problem.
And the question for enterprises will not be, 'Do we support MCP?' The question will be, 'Which MCP connections are federated, governed, and revocable - and which ones are local, unmanaged, and invisible?'
That distinction matters. Federated MCP connections can inherit enterprise policy. Local MCP connections can bypass it. Federated connections can be offboarded through the IdP. Local connections may persist. Federated connections can be scoped by groups and roles. Local connections may depend on a personal token, a static credential, or a user clicking approve without understanding the downstream access.
This is the same battle enterprises have fought with SaaS accounts for years. MCP simply brings it into the agentic AI era.
Okta is not the first signal. It is the strongest market signal.
It is also important to say: Okta is not the first company to support SSO for MCP.
Many SaaS vendors and identity providers have already been moving in this direction. At Reco, for example, we use Descope CIAM and already support SSO authentication for MCP, driven by requests from large enterprise customers. The demand is real because enterprises do not want a parallel authentication model for agents. They want MCP to fit into the identity architecture they already operate.
But Okta and Anthropic together create a stronger market signal.
When Anthropic defines a pattern around MCP and a major identity provider supports it as an enterprise authorization model, the market tends to follow. MCP itself proved that. What began as a protocol announcement became an industry standard. Enterprise-managed authorization may follow the same trajectory.
That is why this announcement matters. It is not just a feature. It is a signal that the next phase of agent adoption will be governed through identity.
What enterprises should do next
Security and identity teams should treat this moment as an inflection point.
First, map your MCP exposure. Identify which applications, agents, development environments, and SaaS tools are exposing or consuming MCP servers.
Second, separate federated from local access. Which MCP connections are governed through SSO, IdP groups, roles, and lifecycle policies? Which rely on personal tokens, local accounts, unmanaged OAuth grants, or ad hoc developer configurations?
Third, define policy for agent access. Agents should not receive broad standing access just because the user has it. Access should be scoped, time-bound where possible, and tied to the workflow the agent is performing.
Fourth, monitor for shadow MCP. Just as organizations monitor for shadow SaaS and unmanaged OAuth apps, they will need visibility into MCP servers, MCP clients, connectors, tools, users, agents, and data flows.
Finally, prepare for JIT agent access. The future is not only 'which agent has access?' It is 'which agent needs access, for which task, for how long, and under whose authority?'
The bottom line
MCP gave agents a standard way to connect to the enterprise.
Enterprise-managed authorization gives the enterprise a standard way to govern those connections.
That is the real milestone.
The industry is moving from 'Can agents connect to tools?' to 'Can we govern those connections at enterprise scale?' The answer is starting to be yes.
But as with every major SaaS shift, the existence of a governed path does not eliminate the unmanaged path. SSO for MCP is a major step forward, but it also makes the next challenge clear: finding and controlling the MCP connections that do not go through SSO.
Because the future enterprise risk will not simply be AI agents. It will be unmanaged AI agents connected to unmanaged tools through unmanaged MCP.
Sources and factual anchors
- Anthropic, "Centrally manage authorization for MCP connectors," June 18, 2026.
https://claude.com/blog/enterprise-managed-auth - Okta, "Okta becomes a featured identity provider powering secure AI agent connections for Anthropic’s Claude," June 18, 2026.
https://www.okta.com/newsroom/press-releases/okta-becomes-a-featured-identity-provider-powering-secure-ai-agent-connections-for-claude-enterprise/ - Anthropic, "Introducing the Model Context Protocol," November 25, 2024.
https://www.anthropic.com/news/model-context-protocol - OpenAI Agents SDK documentation, "Model context protocol (MCP).
https://www.anthropic.com/news/model-context-protocol - Reco AI messaging foundation: Dynamic SaaS Security, SaaS Sprawl, AI Sprawl, Shadow SaaS, Shadow AI, Identity & Access Governance.

Tal Shapira
ABOUT THE AUTHOR
Tal is the Cofounder & CTO of Reco. Tal has a Ph.D. from the school of Electrical Engineering at Tel Aviv University, where his research focused on deep learning, computer networks, and cybersecurity. Tal is a graduate of the Talpiot Excellence Program, and a former head of a cybersecurity R&D group within the Israeli Prime Minister's Office. In addition to serving as the CTO, Tal is a member of the AI Controls Security Working Group with the Cloud Security Alliance.
Tal is the Cofounder & CTO of Reco. Tal has a Ph.D. from the school of Electrical Engineering at Tel Aviv University, where his research focused on deep learning, computer networks, and cybersecurity. Tal is a graduate of the Talpiot Excellence Program, and a former head of a cybersecurity R&D group within the Israeli Prime Minister's Office. In addition to serving as the CTO, Tal is a member of the AI Controls Security Working Group with the Cloud Security Alliance.



