Syncing Source System Access Controls to AI Agents Without Manual Reconfiguration

AI agents should inherit access controls from source systems so there is no separate copy of user permissions to keep up to date. Automatic permission inheritance across enterprise AI data sources works when MCP connections bind requests to the authenticated user and the source system enforces its existing policies before returning data. A governed MCP gateway extends that protection across server configurations as an organizational capability.

Why AI agents querying enterprise data without inherited permissions create a structural security problem

MCP reduces the work of connecting AI clients to enterprise systems. Instead of building a custom connector for every pairing, each client and data source implements the same interface, reducing the integration count from N×M to N+M. One server can then serve every compatible client. That is a useful consolidation of engineering work, but it can also concentrate access because a single MCP server can hold credentials for multiple downstream systems.

The security gap appears when those credentials determine what an agent can retrieve, regardless of who asked the question. A server that uses an elevated service account may read records that the user who made the request cannot read directly. This is the “confused deputy” failure mode. The server has authority to access the data, but uses that authority on behalf of someone who does not.

In that setup, the effective access policy is whatever the service account received when the server was configured. The user's actual permissions do not govern the request. Red Hat's January 2026 guide identifies the enterprise requirement as checking that the right people and models can call the right tools with the right permissions, while tracking running servers, their versions, and their actions. MCP supplies the integration foundation, but that foundation needs an enforcement layer tied to the requester.

What MCP does and does not provide on access control, as the protocol stands

MCP defines three primitives, which are tools for actions, resources for readable data, and prompts for reusable instruction templates. None comes with user identity or access scope by default. The protocol leaves role-based access control undefined, and authentication has historically been optional. This is a boundary of architectural scope. Standardizing how an agent calls a tool is different from deciding which records that agent may read.

Authentication requirements are becoming stricter without replacing downstream authorization. The July 2026 revision requires clients to validate the issuer parameter before redeeming an authorization code, key stored credentials by issuer, and re-register when the authorization server changes. Those requirements govern how clients handle authorization credentials. They do not define access to enterprise records. A correctly authenticated client still needs a policy that connects its requests to the user's rights in each source system.

The roadmap also includes OAuth 2.1 authentication moving from optional to default, formal tool governance, and observability moving from premium additions to standard features. Streamable HTTP is evolving to support stateless operation across multiple server instances, while stdio remains the standard for local use. Scalable transport helps servers handle deployment demands, while authentication establishes identity. Neither alone means that an agent inherits row-level restrictions or other source-system policies.

Why do permissions have to be rebuilt for every new AI tool?

Manual reconfiguration recreates the multiplication problem that MCP removes from integration work. Every new agent, team, or source requires another access definition to build and maintain. Yet enterprise permissions keep changing and belong to the people who use the tools as well as to the tools. The source system may manage a user's rights correctly while the manually configured MCP server continues operating under standing credentials.

Role changes and employee departures expose the mismatch. Revoking access in the source identity provider does not automatically remove standing credentials from every manually configured server. Those credentials stay in place until someone finds and removes them. Without a central inventory, security teams cannot see the full set of servers, credentials, reachable systems, or data flows. Manual policy upkeep therefore depends on knowing about deployments that the organization may not have recorded.

The Enterprise-Managed Authorization extension, introduced in the July 2026 specification, addresses the fragmented authorization process in which employees individually authorized each server. EMA lets IT manage access policy centrally through the identity provider. Revocation prevents new connections across MCP clients. Existing sessions end when the access token expires or is revoked by the connected authorization server. That distinction is important when assessing revocation, because stopping a new connection is not the same as terminating an active session immediately.

Periodic audits cannot substitute for enforcement at request time. Agents keep acting, while an audit can miss credentials that were granted and left active between reviews. An audit also leaves the confused-deputy mechanism in place. Traditional RBAC has a related limitation when it assumes static roles but agent permissions need to reflect the task, data sensitivity, or current threat level. Attribute-based access control and policy-as-code models check that context in real time instead of relying only on another fixed role for the agent.

How permission inheritance from source systems works in practice

Instead of using broad service-account access as the agent's authorization, the MCP server passes the authenticated user's identity token to the downstream API. The platform evaluates the request under that identity. Existing row-level security, column masking, and data classification controls then apply at query time. The agent does not need a separately defined entitlement to the same data.

For Salesforce, the requirement is therefore not simply that an MCP connector can reach CRM records. It is that the requesting user's existing access determines which records the connection can return or act on. Connectivity alone does not establish permission inheritance. The same distinction applies when assessing connections to a document management platform or Snowflake. A connector's presence is not evidence that it preserves the source's access model, and the implementation must demonstrate that behavior.

ServiceNow provides a more specific implementation example. Its Now Assist MCP server shipped in Zurich Patch 4 with Now Assist Skills as tools, then expanded through Action Fabric at Knowledge 2026 in May 2026. The full tool set, including Knowledge Graph, Subflows, and Scripted REST APIs, requires Zurich Patch 9 or later. Configuration is part of the security claim. When AI Gateway is enabled, actions pass through AI Control Tower for identity verification and permission scoping, with managed OAuth, enterprise audit trails, session management, and role-based tool packages in the MCP Server Console.

Governed data catalogs apply the same principle to discovery. Their MCP servers filter asset results through the platform's access policy engine at query time, rather than returning unrestricted results for the agent to sort out. Context remains attached to the permitted assets. Ownership, lineage, quality scores, and access classifications travel with each result. That makes the returned context useful without asking the model to enforce the boundary itself.

The MCP gateway as the organizational enforcement point for inherited permissions

A well-scoped server protects only the traffic that uses it. If teams independently deploy other servers with hardcoded tokens in local configuration files, inherited permissions in approved connections coexist with ungoverned access elsewhere. Solving it requires both a sound connector implementation and an organizational enforcement point. A centralized MCP gateway provides the control plane through which security teams can see and govern the fleet.

OAuth 2.1-based identity binding connects the agent to scoped user permissions, while a tool allowlist limits which capabilities each agent may invoke. Human approval adds a separate action boundary. Database deletions, financial transactions, bulk record changes, and outbound data transfers need explicit approval even when the permissions in place allow them. Permission to access a system is not unrestricted permission to automate every consequential action within it.

Department isolation makes this scope manageable. Each team or function gets an MCP endpoint with only the tools and data it needs for its work, instead of sharing a server that uses broad credentials. Connected sources still control the permissions for their data. The governed registry records which servers exist, who owns them, and what they can reach.

What "correctly implemented" permission inheritance looks like across four enterprise functions

In RevOps and sales, Salesloft, merged with Clari, announced its July 2026 MCP expansion covering Cadence and activity data, Clari Copilot call intelligence, forecasting, and deal inspection, with connectors for ChatGPT, Microsoft Copilot, and Google Gemini. With correctly implemented inheritance, a sales representative's agent sees only the accounts and pipeline data within the organization's full revenue dataset that representative may view.

A developer opening a Linear ticket can have an agent retrieve feature requests, deal values, and security requirements from sales calls, compare customer use cases with the codebase, and propose an implementation for review, but only within that developer's access to the connected systems.

An agent that routes tickets through Zendesk, Intercom, and Slack inherits the support representative's access to customer records, so a Tier 1 representative cannot use an MCP query to get account-level financial data that only account managers may read.

A governed catalog returns only assets permitted for the requesting user or service principal, with ownership, upstream lineage, quality scores, and access classifications attached to those results.

Across these functions, permission decisions happen at the data layer. With correct enforcement, restricted data never reaches the agent through that request, so a prompt or injected instruction cannot make the source return records outside the bound identity's scope. The mechanism works across these use cases because it relies on the system that already controls the data, rather than on the model's willingness to obey an instruction.

The implementation checklist for trusting inherited permissions

For practitioners evaluating an implementation, the first check is whether identity binding reaches the downstream permission decision. The evidence must show that the requester, rather than an elevated standing account, determines access. A successful login is not sufficient proof. Enterprise-Managed Authorization should let IT use the identity provider to control which agents and servers employees can use. Revocation checks must distinguish blocked new connections from existing sessions that remain active until token expiry or authorization-server revocation.

Each agent should invoke only the tools explicitly approved for its function. Source permissions and tool allowlists answer different questions. The former limits accessible data, while the latter limits available actions. Human approval gates must also cover database deletions, financial transactions, bulk record changes, and outbound data transfers regardless of whether the agent technically has permission to perform them.

Every record needs the requesting user's identity, the tool called, the parameters passed, and the result returned. Approval must also be traceable to who approved what and when. Without that evidence, permission inheritance remains an assertion that the organization cannot examine after an action. Logs must show that the controls worked as well as that a server received traffic.

Finally, the inventory must cover the organization, including servers outside a security team's known inventory. A central registry should record every MCP server, who owns it, which systems it connects to, and which credentials it holds. Governed reuse also needs version control and access scoping for skills and server configurations. When one team solves permission inheritance for Salesforce, another should inherit that governed solution as a shared, discoverable implementation.