Stacklok now supports Enterprise-Managed Authorization
The industry just took a real step toward governing enterprise AI agents. Anthropic, Microsoft, and Okta adopted Enterprise-Managed Authorization (EMA), a new MCP extension that lets your identity provider grant server access centrally, so that users get their approved servers at login with no per-app consent prompts or risk of personal accounts slipping into work systems.
Stacklok’s open source project, ToolHive, supports it today.
What EMA is and what it enables
EMA is built on an emerging IETF standard, the Identity Assertion Authorization Grant (ID-JAG). It makes your identity provider the authoritative decision-maker for agent access.
Define the policy once, in the IdP you already trust. Each user gets only what their role allows (from first login), not the blanket access a shared service service account carries.
It also answers the question every enterprise AI architecture review keeps landing on. When an agent takes an action, on whose behalf is it acting? With EMA, every tool call carries the real identity of the person who started the work.
Where ToolHive comes in
The place this matters most is the outside systems your enterprise runs on. Your agents are already taking real actions there, filing tickets, updating records, and moving work forward in the tools your teams use every day. Making an agent act as the real employee behind it, rather than a shared service account, is the hard part.
This is exactly where Stacklok’s open source project, ToolHive, fits. ToolHive already sits in front of the SaaS servers your agents connect to, as the MCP governance layer. Any server you proxy through ToolHive can now use EMA to authenticate through your identity provider, and ToolHive handles that connection for you. Nothing about how you run ToolHive needs to change to enable this. As long as the authorization server used by the MCP server supports XAA, it works seamlessly. There is no new flow to build and no re-architecting of your agents. Route a connection through ToolHive and it inherits real-user, IdP-governed identity.
So every action an agent takes in a proxied system carries the identity of the real person behind it, governed by the identity provider you already run. When an employee’s access changes in your IdP, their agents’ access changes with it, immediately. Your security team keeps one place to decide who can do what, and every action is tied to a real, named person.
Here is what that looks like in practice. An agent files a Jira ticket on behalf of a support rep. The ticket is created as that rep, not a shared service account, so it is fully attributable. And if the rep’s access was pulled this morning, the agent simply cannot act as them.
What this changes for your security team
Real identity on every action. The outside system sees the actual person behind each action, not a service account. When an auditor asks what your AI agents did last quarter, you have an answer.
Your IdP back in control. Set policy once and it is enforced every time an agent acts. Admins grant or revoke an agent’s ability to act on behalf of users at a specific system, from the same console they already use.
Revocation that works. When someone’s access ends in your IdP, their agents lose it on the very next action. There is no separate agent access to track down and shut off.
A smaller blast radius. ToolHive holds no shared passwords or standing credentials for a breach to expose. Access is granted only for the moment an agent acts.
Get started
You want your agents to not just act, but act on behalf of someone, with the same identity, the same or down-scoped permissions, and the same accountability as the people they work for.
Want to see it in your environment? Book a demo, get started with ToolHive, or join the conversation with our team on Discord.
July 06, 2026
