Enterprise-Ready MCP Permissions

Your enterprise customers have a new question on their security questionnaires: "When our employees connect an AI assistant to your product, who decides what it can access?"

For most Model Context Protocol (MCP) servers today, the answer is "whoever clicked Connect." That works for a solo developer wiring up Cursor on a weekend. It does not work for a 5,000-person company whose security team needs to know what every AI agent can reach, and under what conditions.

Enterprise IT teams want AI permissions to follow the same rules as everything else: managed centrally, tied to roles, auditable, and removed when someone leaves. PropelAuth's MCP organization scopes, paired with Enterprise SSO, let you give them that inside your product, without building a separate permissions system for AI.

The short answer: MCP authorization in your product can follow your customer's existing roles. Organization scopes limit which roles can grant an AI client access to shared data, and Enterprise SSO lets the customer's identity provider control who signs in and which role they hold.

Why per-user consent falls short for MCP authorization#

Standard MCP authorization is an OAuth 2.1 flow. A user connects Claude, ChatGPT, or Cursor to your MCP server, sees a consent screen, and approves a set of scopes. The AI client can then act on their behalf.

The gap is that the consent decision belongs entirely to the individual. If your MCP server exposes a tool that exports every customer record in the account, any member of that account can hand it to an AI client. Nobody in IT approved it and no policy was consulted.

In B2B, most of the data worth protecting belongs to the organization rather than the person who happens to be logged in. That makes MCP access control an organization-level problem, not only a user-level one.

MCP organization scopes: role-based access control for AI agents#

PropelAuth supports two kinds of MCP scopes. User scopes cover personal data and private resources. An organization scope (org scope) is a permission for shared, organization-level resources that only certain roles are allowed to grant to an AI client.

Say you create a scope called write:org_sensitive_resource and restrict it to Owners and Admins. When an Admin connects their AI client, they can grant it. When a regular member connects, the scope appears grayed out on the consent screen and can't be selected. The member still connects and still gets the tools appropriate to their role, but the sensitive ones stay out of reach.

Your customer's existing role structure becomes the policy for AI access, so nobody has to maintain a second set of permissions just for agents. For the feature details, see our MCP organization scopes announcement.

Enterprise SSO for MCP: the identity provider stays in charge#

Org scopes decide what each role can grant. Enterprise SSO decides who is in those roles to begin with, and it puts that decision in the hands of your customer's IT team.

Connecting an AI client starts with a company login. MCP authentication uses the same login methods as the rest of your product. When a customer's organization has an Enterprise SSO connection over SAML or OpenID Connect (OIDC), an employee connecting Claude or Cursor signs in through their company's Okta, Microsoft Entra ID, or other identity provider, exactly as they would in the browser. Whatever sign-in policies that identity provider enforces, such as MFA, apply to the AI connection too.

Roles can come from the identity provider. During Enterprise SSO setup, your customer can map roles from their identity provider to the roles in your product. That creates a chain their IT team already understands: a group in Okta maps to a role in your product, and that role determines which org scopes a person can grant to an AI client. When IT moves someone out of the group, what they can hand to an AI assistant changes with their role, and nobody has to log in to your product to make it happen.

Offboarding follows the directory. When an employee is deactivated in the identity provider, they can no longer complete an SSO sign-in. That means they can't connect a new AI client, and they can't re-authenticate an existing one. MCP session duration, which you configure, sets the upper limit on how long an existing connection lasts before re-authentication is required, so it's worth choosing that value with offboarding in mind. If your customer also wants accounts created and removed automatically, that's the job of SCIM provisioning.

Your customer's IT admin sets all of this up on their side through the Enterprise SSO setup page, which has step-by-step guides for Okta, Entra, Google, and other providers.

MCP governance: least privilege, token checks, and audit logs#

Least privilege is available to everyone. Users can deselect individual scopes on the consent screen, so even an Admin can connect an assistant with read-only access if that's all the task requires.

Every request can be checked against scopes and roles. Your MCP server validates access tokens through the introspection endpoint, which returns the granted scopes along with the user's organization, their roles, and their permissions. Your tools can check both what was granted and who the user is.

There's a paper trail. MCP audit logs record when clients are created, updated, and deleted, and when consent is granted or revoked, filterable by client, event type, date, and actor. When a security team asks who connected what, you have the answer.

How to enforce MCP scopes in your server#

Enforcement is a few lines per tool. The introspection response carries everything you need:

{
    "active": true,
    "client_id": "{MCP_CLIENT_ID}",
    "username": "example@acmeinc.com",
    "scope": "read:user_data tools:execute google_calendar:read",
    "sub": "{USER_ID}",
    "aud": "https://myserver.com/mcp",
    "iss": "{YOUR_AUTH_URL}",
    "exp": 1768515193,
    "iat": 1768511593,

    // If using org scopes
    "org_id": "{ORG_ID}",
    "users_org_roles": [
        "Admin"
    ],
    "users_org_permissions": [
        "can_view_resource",
        "can_edit_resource",
        ...
    ]
}

def export_customer_records(token_info):
    if not token_info["active"]:
        raise PermissionError("token is not active")

    scopes = token_info["scope"].split()
    if "read:org_customer_data" not in scopes:
        raise PermissionError("read:org_customer_data scope required")

    org_id = token_info["org_id"]
    return fetch_records_for_org(org_id)

Setup happens in the PropelAuth dashboard: open the MCP page, go to Org Scopes, create a scope, and choose which roles can grant it. The consent screen enforces the restriction automatically. If the customer's organization already has Enterprise SSO enabled, there's nothing extra to configure for MCP, because AI clients go through the same login.

A good pattern is one scope per sensitive capability rather than one broad scope for the whole server. If a tool touches billing, customer data, or configuration, give it its own scope and decide deliberately which roles can grant it. We walk through that pattern end to end in Authentication and Authorization for Internal MCP Servers.

MCP security is becoming a buying requirement#

AI connections are moving from individual experiments to company-wide rollouts, and the security review is moving with them. Enterprises are asking their vendors how AI access is governed, and "each user decides for themselves" is an answer that stalls deals.

With org scopes and Enterprise SSO, you can tell them that AI access in your product starts with their identity provider, is limited by roles their IT team controls, is time-boxed, and is logged.

Read the MCP authentication docs to get started.