June 19, 2026. The biggest AI news this week was not a new model. It was the industry quietly agreeing on how AI agents should get into the tools your business runs on. On June 18, the Enterprise-Managed Authorization extension to the Model Context Protocol (MCP) reached stable, and three of the biggest names in software shipped support for it on the same day: Anthropic across Claude, Microsoft inside Visual Studio Code, and Okta as the first identity provider. MCP is the open, Linux Foundation hosted standard that lets AI assistants connect to outside tools and data. This update is about who is allowed to make those connections, and that turns out to be the question every company adopting AI is about to face. Full details are on the Model Context Protocol blog and Anthropic's announcement.
What shipped
Until this week, switching on an MCP connector took two steps. An admin enabled a connector for the organization, and then every single user authorized it themselves through a separate consent screen. That per-user approval tax is why most connectors stayed switched off in real companies: onboarding a new hire meant a queue of one-by-one approvals, security teams could not enforce a consistent policy, and nothing stopped someone from linking a personal account to a work tool. Enterprise-Managed Authorization removes that second step. An admin authorizes a connector once through the company identity provider, and every user inherits access on first login, scoped to the groups and roles they already have. The end user does nothing. Their tools are simply there the first time they open Claude.
Under the hood, during single sign-on the client receives a signed identity token from your provider and exchanges it for a scoped access token from the tool, so the user never sees a per-tool consent screen. The practical effects are the ones operators care about: one place to grant or revoke access, one audit trail across every connector, and the ability to shorten token lifetimes so that when someone is offboarded, their agent access expires fast instead of lingering on a forgotten token.
Key developments
- The Enterprise-Managed Authorization extension to MCP is now stable, an open standard that any tool, client, or identity provider can implement the same way.
- Anthropic implemented it across Claude, Claude Code, and Cowork; Microsoft added support in Visual Studio Code; Okta is the first supported identity provider, through its Cross App Access protocol.
- Tools live at launch include Asana, Atlassian (Jira and Confluence), Canva, Figma, Granola, Linear, and Supabase, with Slack and more on the way.
- Early adopters are already rolling it out: HubSpot, Webflow, and Ramp, which says it now provisions 2,000 employees through Okta with zero extra steps.
- Access is governed centrally: scope by role, manage revocation in the identity provider, and keep one auditable trail instead of scattered per-user grants.
- It landed the same week Anthropic made Workload Identity Federation generally available, covered in our companion brief, so both directions of agent access, into your tools and into the model, got a security upgrade at once.
Why this matters for operators
For most of the businesses we work with, the value of AI shows up the moment an assistant can actually see the CRM, the project tracker, the design files, or the database. The instinct is to connect everything and move fast. The risk is that an AI agent with a standing connection to your tools is a new kind of insider, and until this week most companies had no clean way to control what it could reach or to switch it off in a hurry. Enterprise-Managed Authorization reframes the question. It stops being "can the agent connect" and becomes "who authorized this, what is it scoped to, and can we revoke it in one click." That is the difference between an AI rollout your security team signs off on and one they quietly block. It is the same shift we flagged when HubSpot's Breeze agents went MCP-native, and HubSpot is one of the first companies adopting this standard.
How to apply it, even if you are not an enterprise
You do not need Okta or a Claude Enterprise plan to use the lesson. The principle ports straight down to a small team or an agency.
- Pick one place to grant and revoke AI tool access, and route every connection through it, rather than letting staff wire up their own.
- Scope by least privilege. An assistant that drafts replies does not need write access to your billing system. Give each agent the narrowest access that does the job.
- Never connect a personal account to a work tool. Require the corporate login, so data cannot quietly cross between the two.
- Keep an audit trail of what is connected to what, and review it. If you cannot list every tool your AI can currently touch, that is the first thing to fix.
- Kill access at offboarding. When a person or a project ends, their agent connections should end with them, the same day.
For agencies, this is now part of the build. When we set up an automation that lets an AI touch a client's stack, the access layer is part of the deliverable, not an afterthought. That holds whether the agent lives in a custom automation, an OpenClaw setup, or an n8n workflow. Clients in regulated industries will increasingly require exactly this, and being able to answer "here is who authorized it, scoped to this, with this audit trail" is becoming a reason they choose one AI automation agency over another.
The honest caveats
The Claude implementation is in beta and starts on Team and Enterprise plans, and Okta is the only identity provider at launch, with others to follow. More importantly, identity solves who can connect, not what the agent should be allowed to do once it is in. A perfectly authorized agent can still take a bad action if it is over-scoped or poorly tested, which is why least-privilege scoping, real-world testing before you ship, and a human on any irreversible step still matter as much as ever. If you want this set up properly, it is worth bringing in an AI engineer once, rather than retrofitting access control after something leaks.
The takeaway for 2026 is simple. The headline models get the attention, but the boring plumbing is what decides whether AI is safe to put to work. This week the industry agreed on a standard for the front door. The teams that adopt it, and treat agent access like any other privileged access, are the ones who will be able to say yes to AI instead of nervously saying no.
Frequently Asked Questions
It is an extension to the Model Context Protocol, made stable on June 18, 2026, that lets an organization control which AI connectors its people can use through its identity provider. An admin authorizes a tool once, and users get access automatically on first login, scoped to the groups and roles they already have, with no per-tool consent screen.
Before, an admin enabled a connector and then every user had to authorize it themselves, tool by tool. That friction left most connectors switched off and gave security teams no central control or audit trail. Enterprise-Managed Authorization makes the identity provider the single decision point, so access is granted once, inherited everywhere, and revoked in one place.
At launch the client side includes Claude (chat, Claude Code, and Cowork) and Visual Studio Code, with Okta as the first identity provider. Supported tools include Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase, with Slack and more coming. HubSpot, Webflow, and Ramp are among the early adopters.
No. The Claude feature starts on Team and Enterprise plans, but the principle works for any size. Route AI tool access through one place to grant and revoke, scope each agent to least privilege, block personal accounts on work tools, keep an audit trail, and remove access at offboarding. Those habits protect a five-person team as much as a five-thousand-person one.
It makes access controllable and auditable, which is a big step, but it does not decide what an agent should be allowed to do once connected. An over-scoped or poorly tested agent can still cause harm. You still need least-privilege scoping, real-world testing before each change, and a human reviewing any irreversible action.
We build the access and guardrail layer as part of every agent engagement: scoping each agent to the narrowest permissions, routing connections through the client's identity system where possible, keeping an audit trail, and adding human checks on sensitive actions, so an AI rollout is something your security team approves rather than blocks.