MCP enterprise-managed authorization, explained.

An AI model on its own is a very good writer with no hands. It can describe how to reassign a task or file an expense, but it cannot reach into the system and do it. The Model Context Protocol, usually written as MCP, is one of the ways that changes. It is an open standard for connecting a model to tools, so that the model can ask a running program to perform a real action and get a real result back. The moment you give a model hands, one question stops being academic and becomes the whole game: which actions is it allowed to take, and as whom. That question is what enterprise-managed authorization tries to answer, and it is worth understanding before agents get pointed at anything important.

I will keep this grounded. Some parts of this area are still settling, and where a precise mechanism is still being standardized I will describe the concept rather than assert exact wire details. The shape of the problem, though, is stable and clear, and the shape is what matters for anyone deciding how much to trust an agent.

What MCP actually is

Strip away the branding and MCP is a contract between two roles. On one side is a client, the application hosting the model. On the other is a server, a program that exposes a set of tools the model is allowed to call. A tool is just a named action with defined inputs and outputs: "create a task," "look up a customer," "send a draft for approval." The server describes the tools it offers, the client makes them available to the model, and when the model decides to use one, the request travels to the server, runs, and returns a result the model can read. I wrote a plainer introduction to the idea in a post on why we gave our AI an MCP server, and the short version is that MCP turns a model from something that talks about your systems into something that can operate them through a well-defined door.

The value is obvious and so is the danger. A well-defined door is still a door. If any model, prompted by anyone, can walk through it and call any tool the server exposes, you have not built an assistant, you have built a liability with a friendly interface. This is why authorization is not an add-on to MCP. It is the part that decides whether the whole thing is safe to switch on.

The problem authorization has to solve

Think about what an agent is in a company setting. It acts, often quickly, sometimes without a human watching each step. It can be steered by text it reads, which means a cleverly worded document or message can try to talk it into doing something it should not. And it usually needs to touch systems that hold real consequences: money, records, access, communication. Put those together and you get a specific requirement. The agent must never be able to do more than the person it is acting for is allowed to do, and ideally it should be able to do considerably less.

Two ideas carry most of the weight here. The first is that an agent should act as the user, not as itself with some godlike service account. If I ask an agent to update my projects, it should touch what I can touch and nothing else. The second is scope: even within what the user can do, the agent should be granted only the narrow set of permissions the current task requires, for as short a time as possible. This is the principle of least privilege applied to software that can act on your behalf, and I have written about how hard it is to do well in a post on least privilege in practice.

Where the identity provider comes in

"Enterprise-managed" is the important half of the phrase. It means the company, through its identity provider, is the authority that decides what agents may do, rather than that decision living inside each individual tool or, worse, inside the model's own judgment. The identity provider is the same system that already governs human access through single sign-on. Extending it to govern agents keeps one source of truth for who, and what, is allowed.

In practice this looks like a few connected controls. The identity provider can decide which MCP servers and which tools within them an agent is permitted to reach at all, so an agent connected to a finance system might be allowed to read balances but not move money. It can tie the agent's activity to a specific user's identity, so the audit trail shows both the human and the agent that acted for them. And it can set the terms under which permission is granted, including how long it lasts. The company gets to write these rules once, centrally, instead of hoping every tool implements its own version correctly.

Token exchange, described carefully

The mechanism that lets an agent act as the user, with only the permissions a task needs, is generally a form of token exchange. I will describe the concept and stay away from claiming exact protocol specifics, because this is an area where standards are still maturing.

Here is the idea. When you sign in, your identity provider issues a token that represents you and what you are allowed to do. An agent acting on your behalf should not simply reuse that broad token everywhere; that would hand every downstream tool your full set of permissions. Instead, the agent can exchange the original token for a narrower one, scoped down to the specific action and system at hand, and often time-limited. The downstream MCP server receives this scoped token, checks it, and only then performs the action. If the token does not carry the right scope, the tool refuses. The result is that the agent inherits your identity but not your entire reach, and each hop can be tightened rather than widened.

The practical payoff of doing it this way is threefold. Access can be revoked centrally, because the tokens flow from the identity provider. Actions are attributable, because the token ties back to a real user. And the blast radius of a mistake or a manipulated agent is bounded by the scope of the token it was holding, not by everything the user could theoretically do. None of that removes the need for judgment, but it changes an unbounded risk into a bounded one.

A concrete walk-through

Abstract principles are easy to nod along to and hard to trust, so here is a small, ordinary example. Suppose I ask my assistant to close out a finished project: mark its tasks done, file the final summary, and let the client know it shipped. Behind that one sentence are several distinct actions across what would normally be several systems.

Under a naive design, the assistant would run as a powerful service account with broad access, read my instruction, and do all of it directly. If a task description or an email in that project contained text crafted to redirect the agent, the agent might follow it, and its wide access would set the ceiling on the damage. Under enterprise-managed authorization, the sequence looks different. The assistant acts under my identity, so it can only touch the project I could touch. For each action it holds a token scoped to just that action: permission to update these tasks, permission to file this document, permission to send this message, and nothing wider. If the current step only needs to mark tasks complete, the token it carries cannot move money or change anyone's access, no matter what a manipulated instruction tells it to attempt. And every step lands in the audit log tied to my name and the agent that acted for me. The task still gets done. The difference is that a mistake, or a hostile instruction, hits a wall instead of a wide-open field.

Why this matters more every month

A year ago, most AI at work summarized things. Increasingly it does things. The difference between a model that drafts a reply and an agent that sends it, files it, and updates three records is the difference between a helpful colleague and one you have handed a set of keys. As more products expose MCP servers and more agents start calling them, the questions stop being about model quality and start being about governance. Who authorized this action. Under whose identity. With what scope. For how long. Enterprise-managed authorization exists so those questions have answers that a security team wrote in advance, not answers improvised after an incident. I made the broader case for treating this as a first-class concern in a post on why enterprise trust is earned slowly.

How wrxstack thinks about its assistant and its MCP server

I build the Atlas assistant on these principles rather than around them. The assistant acts under the acting person's own permissions, keeps a log of what it did, and asks for approval before anything consequential. That is the same shape as the model above: act as the user, stay within scope, leave a trail. Atlas offers SSO over SAML and OIDC and keeps an audit log, which are the pieces that make identity and attribution real rather than aspirational. You can see how that fits together on the assistant product page and the security page.

I also want to be honest about the boundary of what wrxstack is. It is an AI work platform, not an identity provider. It integrates with the identity system your company already runs; it does not try to replace Okta, Auth0, or WorkOS, and it does not offer directory sync or SCIM. Enterprise-managed authorization in the fullest sense is a collaboration between the identity provider your company owns and the products it connects to. wrxstack's job is to be a well-behaved product on the receiving end of those rules: to act as the user, honor scope, and record everything, so that when the identity layer tightens the rules, the assistant simply does less rather than finding a way around them.