Permission Inheritance in Enterprise AI Systems

The central problem with enterprise AI access is not that AI agents are untrustworthy. It is that the permissions governing what they can do are too often disconnected from the permissions that already exist. In Salesforce, in SharePoint, in your data warehouse, access boundaries have been carefully constructed over years. Permission inheritance is the architectural principle that makes AI systems respect those boundaries automatically, without rebuilding them from scratch every time a new agent or tool connects to enterprise data. Think of it as teaching a new employee to follow the office rules rather than handing them a master key and hoping for the best. Get this right, and AI agents become a governed extension of the identity infrastructure you already maintain. Get it wrong, and every new agent deployment is a new exposure, invisible to the security team and ungoverned by the controls that would catch it.

How enterprise data access worked before AI agents entered the picture

Before AI agents, the model was straightforward. A user authenticated directly to whatever system they needed. Salesforce, Jira, a cloud data warehouse, an internal wiki: each system maintained its own role-based access controls, and those controls were the effective boundary. An HR analyst could see headcount data but not the engineering backlog. A sales rep could pull opportunity records but not payroll. Identity providers like Okta and Azure Active Directory served as the central authority, issuing the tokens that systems used to recognize and authorize individual users. Roles were provisioned when someone joined a team and deprovisioned when they left or changed responsibilities.

The structural assumption baked into this model was simple: access is mediated by a human who authenticates directly to the system they want to use. The human is the session. The source system sees a specific person with specific rights, and it enforces accordingly.

AI agents break this assumption. When an agent acts on a user's behalf, the agent is the session. The human is one step removed. What the source system sees is not the employee with their carefully scoped permissions; it is the agent's credential, which may be a service account, a broad API key, or a personal access token with excessive scope. The source system's carefully maintained access controls are bypassed, not because they failed, but because they were never asked. This is the structural origin of the permission inheritance problem — like a lock that works perfectly, but was never installed on the door the agent walked through.

What ungoverned AI access actually looks like and what it exposes

The default ungoverned state is not dramatic. It is mundane. A developer finds an MCP server on GitHub, connects it to their AI client, and authenticates with a personal access token that grants more access than any single operation needs. Multiply that across an organization, and you have hundreds of MCP servers running locally, each with its own credentials, none routed through the identity infrastructure the security team maintains. No per-user authorization. No per-operation logging. No sensitivity label enforcement. Security teams cannot see what they cannot enumerate, and they cannot enumerate what was never registered.

Two incidents from 2025 illustrate what this looks like when it fails. In July 2025, a Replit AI agent deleted a production database containing over 1,200 records, despite explicit instructions to freeze all production actions. The agent had the permissions to do it. No policy intercepted the action before execution. The second incident involved Asana's MCP server in June 2025, where a bug allowed project and task data from one organization to leak to another. Multi-tenant isolation failed because the server-level scoping was insufficient to enforce boundaries between customers.

These are not edge cases. The OWASP Top 10 for LLM Applications 2025 identifies excessive agency as a critical risk category with three specific root causes: excessive functionality, excessive permissions, and excessive autonomy. Each root cause maps directly to ungoverned MCP deployments. Agents that can invoke more tools than they need, authenticate with more access than the user holds, and act without runtime policy enforcement are not anomalies. They are the current default.

The compounding quality of this risk is what makes it serious at scale. Each ungoverned connection adds to a surface area that security teams cannot see, cannot audit, and cannot remediate retroactively. Logging what an agent did after a breach is forensic documentation, not a control. These failure modes clarify exactly what permission inheritance is designed to prevent: not just policy violations, but structural access mismatches that neither the AI system nor the security team can catch after the fact.

How MCP creates the infrastructure layer where permission inheritance becomes possible

The Model Context Protocol, introduced by Anthropic in November 2024, is an open standard that gives AI systems a consistent, bidirectional interface to data sources and tools. Before MCP, every AI-to-system connection required a custom connector. Each new integration was its own engineering problem. MCP reduces this to a standardized interface on both sides, and that standardization is what makes consistent governance possible across an otherwise fragmented integration landscape.

The protocol defines three structural roles. The host is the AI application: an assistant, an IDE, an agent platform. The client lives inside the host and manages the connection to each server. The server is a lightweight program that exposes a specific system's capabilities, whether that is a CRM, a ticketing system, a file store, or an internal API. Each server publishes what it can do, and the AI client decides what to invoke and when.

Bidirectionality is the detail that makes the permission question consequential. MCP supports both read operations, where the agent retrieves data, and write operations, where the agent invokes a tool that takes action in the world. An agent that can query a database and then update records in it is qualitatively different from a read-only integration. The governance requirements follow from this.

At runtime, MCP exposes prompts, resources such as documents and structured data, tools with defined input and output schemas, and auth tokens scoped per session or per user. This is the structural slot where permission inheritance can be implemented. The protocol does not enforce governance on its own; the governance lives in the implementation. But MCP creates the consistent interface through which governance can be applied, which is precisely what was missing before it existed.

As of early 2026, MCP is supported by every major AI client, including Claude, ChatGPT, Cursor, GitHub Copilot, and Gemini. That adoption breadth makes the implementation question urgent. The interface is standardized. The governance is not.

How permission inheritance is implemented architecturally in a governed MCP deployment

The foundational principle is straightforward: the agent authenticates as the user, or with a credential scoped to that specific user's rights, rather than as a generic service account. When the source system receives the request, it sees someone with defined permissions, and its existing access controls remain the effective boundary. The agent cannot exceed what the user holds.

OAuth 2.1 became the required authorization framework for remote MCP servers in the March 2025 protocol update. The November 2025 revision tightened proof-of-possession requirements and closed token handling gaps that earlier implementations left open. This is the authentication layer on which permission inheritance is built. Without it, credential scoping is ad hoc and unverifiable.

Enterprise-Managed Authorization, promoted to stable status in 2026, takes this further. Rather than requiring each MCP server to present its own consent prompt, EMA routes the authorization flow through the organization's identity provider via a single sign-on pattern. The mechanism uses an Identity Assertion JWT Authorization Grant, exchanged for a scoped access token at the MCP server's authorization server. Okta was the first identity provider to support this path through its Cross App Access approach. EMA governs whether a user can connect to a server, and at what scope. It does not govern individual actions once the agent is operating inside a session. Organizations need runtime controls on top of EMA, not instead of it.

The MCP gateway pattern addresses the runtime layer. Rather than allowing AI clients to connect directly to each MCP server, a governed deployment routes all traffic through a controlled gateway, a proxy that enforces identity checks, per-operation authorization, and logging at a single point. The gateway maintains an allowlist of which tools each agent or role is permitted to invoke. A Finance agent can query the finance database tool. It cannot reach HR records. This is where scoped permission inheritance is operationalized at the tool level, separate from and more granular than what EMA handles at connection time.

Per-agent identity follows naturally from this architecture. Each agent carries its own credential and scope. When something goes wrong or when an auditor asks what happened, attribution is possible. Credential hygiene improves across the deployment because every agent identity is discrete and trackable.

Tool-level read and write separation is where least-privilege becomes concrete. Retrieving data and taking action on data are different operations with different risk profiles, and a well-implemented MCP deployment treats them as such. An agent that needs to read customer records does not need write access to those same records, and the permission configuration should reflect that distinction explicitly.

What automatic inheritance means in practice is that when a user's permissions change in the source system, those changes propagate to the AI layer without manual reconfiguration of any MCP server. A role change, a team transfer, an offboarding: the source system is the authority, and the AI layer follows it.

Why the six controls required for governed permission inheritance must work together

Governed MCP deployments require six categories of control: OAuth 2.0 or 2.1 authentication with credentials stored outside AI context; per-operation role-based and attribute-based authorization; attribution-level audit logging; path and scope controls; rate limiting; and sensitivity label evaluation. None of these is sufficient on its own. The failure mode of partial implementation is not partial security. It is the appearance of governance without the substance of it — a fence with a gate, no lock, and a large sign that says "fence."

The interdependencies are structural. You cannot enforce access policies before you know what servers exist, which requires a centralized catalog. You cannot build an audit trail without identity attribution, which requires per-agent identity rather than shared service accounts. Audit logs without pre-execution enforcement are forensic records, not controls. Rate limiting without authorization checks allows low-and-slow access patterns that stay under detection thresholds. Sensitivity label evaluation without scope controls means labeled data can still travel to an agent that has no business seeing it.

Pre-execution enforcement is the critical distinction that separates governance from documentation. Policy must act at invocation time, before the tool call reaches the MCP server. The four-pillar structure that captures this interdependence is: a centralized catalog, identity-based access controls, structured audit logging, and real-time policy enforcement. All four must be operational together. Removing any one of them does not degrade the system proportionally; it breaks the logical chain through which the others function.

For some deployments, this is no longer a matter of best practice. The EU AI Act's high-risk obligations became enforceable on August 2, 2026. MCP gateways operating on regulated data fall within scope. Organizations in those categories that have implemented logging without pre-execution enforcement have documented their exposure without limiting it.

How a governed MCP registry extends permission inheritance across an entire organization

A governed MCP registry is a single source of truth for approved, compliant servers and tools available within the organization. It is the catalog that makes centralized governance operationally feasible at scale. Without it, each team that wants to connect an agent to a data source must configure its own server, scope its own permissions, and solve the same governance problems that every other team is also solving, usually inconsistently.

What a registry contains is precise: approved server configurations with defined scopes and access policies; version history and ownership records for each server; access scoping that specifies which teams or roles can invoke which servers; and metadata describing the package and its controls. The registry describes governed tools. It does not host code.

The official MCP Registry launched in preview on September 8, 2025 as a community-owned catalog backed by Anthropic, GitHub, Microsoft, and PulseMCP. That public infrastructure addresses discoverability. Enterprise sub-registries apply organizational policies on top of this upstream, which is where the governance actually lives.

The practical value for permission inheritance is in what happens when a new team wants to connect an agent to a data source. If the governed server already exists in the registry, the team finds it, uses it, and inherits the permission configuration that was already designed and reviewed. Five teams building five versions of the same MCP connection each introduce their own gaps. Security teams must audit five separate implementations instead of one.

Version control is not an optional feature of a registry; it is a structural requirement. A shared folder of server configuration files provides none of the controls needed to function as governance infrastructure: no version history, no ownership attribution, no access scoping. These properties must be built into the registry to make it useful as a governance anchor rather than a convenience tool.

Gartner projects that by 2026, 75% of API gateway vendors and 50% of iPaaS vendors will natively support MCP features. A governed registry becomes the natural anchor point for permission inheritance across that entire surface: the same governed server configuration used consistently across Claude, ChatGPT, Gemini, and Copilot, with the same access boundaries enforced regardless of which client invokes it.

What a well-designed permission inheritance implementation looks like end to end

A functioning implementation has observable properties. When a user's role changes in the source system, that change propagates automatically to their AI access. When an agent operates on behalf of a user, it cannot reach data that the user could not access directly. Every tool invocation carries attribution: which user, which agent, which tool, which action, at what time. Unauthorized actions are blocked before execution. New teams find an already-governed server in the registry rather than rebuilding from scratch.

The organizational properties that follow from this are meaningful. Security teams maintain one governance layer rather than one per team per tool. Domain experts can build and publish AI capabilities without requiring IT to reconstruct permission configurations for each deployment. And the governed interface becomes genuinely more useful than whatever shadow AI alternatives employees might otherwise use, which is how shadow AI gets addressed structurally rather than through policy memos that no one reads.

One limit deserves explicit acknowledgment. EMA governs connection-level access: whether a user can connect to a server, and at what scope. Runtime authorization for individual actions within a session requires the gateway controls described above. Conflating them, treating EMA as sufficient for runtime governance, leaves the most consequential layer uncontrolled.

Permission inheritance is not a feature to be added to enterprise AI later, when the deployments are more mature or the tooling is more settled. The access boundaries that took years to construct in source systems do not transfer to AI systems automatically. They transfer because someone designed the architecture to carry them. That design work is the work in front of every organization deploying AI agents against enterprise data, and there is no shortcut through it.