Enterprise AI Platforms That Automatically Inherit Permissions From SharePoint Salesforce and Snowflake

Enterprise AI platforms should inherit SharePoint, Salesforce, and Snowflake permissions from the requesting user at runtime, rather than rebuild those rules in a separate permission store. The defining capability is source-system enforcement, backed by user-attributed audits and controls over individual tools. Automatic permission inheritance lets AI use the access rules already in place, but safe use also needs controls over what agents retrieve, expose, and do.

Why permission inheritance is the real enterprise AI problem to solve

An AI agent connected to enterprise data creates a governance gap if it bypasses or duplicates the controls already protecting that data. SharePoint, Salesforce, and Snowflake have access rules built over years, often shaped around specific roles, records, and responsibilities. A separate AI permission layer adds another place to keep secure and up to date. Policy alone cannot close that structural gap. The practical test is whether the source system still decides what the requesting user can access.

An agent acting for a broadly authorized user can bring a restricted board deck, a closed diligence room, or confidential records into a shared AI session. The retrieval may violate no source-system permission rule, while the session exposes the content to others. This is authorized over-reach. It explains why the architecture must answer two different questions, which are who may retrieve data and what may happen to it afterward.

What automatic permission inheritance actually means, and what it does not

Automatic permission inheritance means an agent’s access derives at runtime from the authenticating user’s existing entitlements in the source system. It does not come from a shared service account configured during setup, a static API key, or a separately maintained permission definition inside the AI platform. The identity must be that of the user making the request.

The agent authenticates as the specific user, the source system enforces access decisions, and the source audit trail attributes actions to that user. OAuth alone does not establish all three. The authentication mechanism must support an architecture in which the source remains the authority, rather than leaving the AI platform to guess what that source would permit.

This is more precise than saying an agent can only do what its user can do. Inheritance prevents unauthorized lateral movement into data the user cannot reach, leaving some consequences of authorized retrieval unexamined. A user may legitimately read sensitive material without that material being suitable for a shared AI session. That remaining distinction becomes the job of the governance layer above source permissions.

How Snowflake implements permission inheritance through its managed MCP server

Snowflake’s managed Model Context Protocol (MCP) server lets agents retrieve data from Snowflake accounts without deploying separate infrastructure. Access runs through the same role-based access control (RBAC) that governs other Snowflake queries. The existing permission system remains in charge. Authentication uses Snowflake OAuth by default, with optional External OAuth so clients can authenticate through the organization’s existing identity provider rather than rely on an identity defined inside the AI platform.

The server boundary is not the tool boundary. Snowflake’s documentation states that access to an MCP server does not grant access to the tools it exposes, and each tool needs a separate permission grant. RBAC therefore governs both the server and its tools. This separation makes least privilege concrete, because permission to connect is not permission to invoke everything available through that connection.

Snowflake recommends exposing only a governed Cortex Agent as the client-facing interface. The external MCP client then receives one governed entry point, while the agent selects Cortex Analyst, Cortex Search, or custom tools internally. Credential handling needs the same discipline. Snowflake warns against hardcoded tokens and says a Programmatic Access Token, if used, should have only the least-privileged role needed, because a leaked token exposes the privileges attached to it.

The architecture also extends beyond Snowflake data. MCP Connectors let Cortex Agents reach external systems, including Atlassian, GitHub, and Salesforce, through OAuth-backed external MCP server objects. Administrators configure those objects, and users authenticate with the third-party service. This gives agents access to outside tools without requiring them to leave Snowflake’s control plane.

How Salesforce enforces per-user identity through MCP rather than shared service accounts

Salesforce applies the same identity principle to a CRM organized around record-level access. Every MCP transaction runs as the authenticated user. When an agent updates a record, the audit trail therefore shows it under that person’s name. The agent can act only if the user has permission. This preserves the link between a business action and the person authorized to take it.

Authentication uses per-user OAuth 2.0 with PKCE and a dedicated scope that does not extend to Salesforce’s existing REST APIs. MCP access has an explicit boundary. Salesforce’s April 2026 developer announcement states that hosted MCP servers are generally available for Enterprise Edition orgs and above, with Salesforce handling hosting, authentication, and permission enforcement. Each org must explicitly enable them, so nothing is exposed by default. Salesforce says its Headless 360 MCP Server gives agents trusted business capabilities that the organization chooses to expose, with no raw APIs or free access across the underlying data model.

How SharePoint permission inheritance works and where Microsoft's current rollout stands

Search can traverse every site the authorizing user can read, including access inherited from prior roles, closed diligence rooms, and forgotten shared sites. Those permissions still belong to the user. An agent honoring them may therefore retrieve more than the user had in mind when asking a narrow question.

Microsoft’s official Work IQ SharePoint MCP server is a preview feature as of mid-2026. Its maker surfaces, including Copilot Studio/Foundry, require a Microsoft 365 Copilot license. That requirement affects the deployment route available to an organization. The underlying Work IQ API became generally available on June 16, 2026, independently of Copilot licensing and on a consumption basis. Organizations without the required license for the preview maker surfaces must use third-party implementations for that MCP route.

StackOne’s SharePoint MCP server uses a one-time administrator app registration in Microsoft Entra ID. Each user then links their own Microsoft account through OAuth, and the agent acts on their behalf with delegated Microsoft Graph permissions. The shared setup does not replace individual identity. Its role is to establish the connection through which each user delegates access.

The June 2026 Enterprise-Managed Authorization (EMA) extension to the MCP specification formalizes identity inheritance further. Enterprise identity providers take charge of granting MCP server access, so users reach authorized servers through the enterprise identity they already have. Users authenticate once rather than handle separate consent screens for each server. This removes the need to set up OAuth for each server and avoids personal/work account mix-ups, bringing those connections under the identity system the enterprise already uses.

Why permission inheritance alone is not sufficient — and what the remaining governance gap requires

Permission inheritance is a necessary part of enterprise AI governance that controls what an agent may retrieve. SharePoint MCP retrieval can return personal and health information, financial records, contracts, source code, and secrets that the authorizing user can see. Inheritance itself does not inspect that content. A complete architecture needs another layer to govern what may pass onward.

The tools themselves introduce a separate risk. Snowflake’s enterprise MCP gateway guide identifies tool poisoning and tool shadowing as production risks. Tool poisoning uses forged tool descriptions to manipulate agent behavior, while tool shadowing lets a server override trusted tools in an agent’s toolchain. Neither depends on reading a forbidden document. They target how the agent chooses and executes its tools.

Traditional API gateways were built for deterministic app-to-app traffic with static credentials and typically ask whether a client may reach an endpoint. MCP governance requires a more specific decision about whether an agent may execute a particular tool call, with particular parameters, for a particular user at the time of the request. Endpoint access is too coarse a test. The decision must account for the action the agent is attempting.

The architectural response is to combine source permissions with data loss prevention (DLP) and full agent auditing. The source enforces access, while the additional layer governs what may leave that boundary and records intent, tool choices, parameters, and blocked attempts alongside HTTP metadata. Credentials need their own protection as well. Under the zero-secret exposure principle, a gateway intercepts tool execution and injects authorized credentials at runtime, so raw production credentials never enter the agent’s context window.

What should buyers look for to avoid rebuilding permissions across all three systems

For buyers, the evaluation starts with user-delegated authentication on every tool call across SharePoint, Salesforce, and Snowflake. Support in only one system is not enough. A platform must also leave access decisions with each source. Together, these criteria distinguish inherited access from a parallel permission system that creates more maintenance work.

Snowflake makes server and tool RBAC explicit, while Salesforce emphasizes per-user transactions, bounded MCP authentication, and trusted business capabilities. Microsoft’s Work IQ offering adds a deployment distinction between preview maker surfaces and generally available API access, while StackOne provides a delegated SharePoint connection. None of those details alone establishes a complete cross-system governance layer. A buyer’s shortlist should distinguish source connectivity from the platform controls placed above it.

Per-tool permissions must limit what a user can do once they have server access, and a governed registry must let IT and security choose which capabilities people can use and who can use them. Discovery needs a controlled home. A searchable catalog with approval workflows and RBAC gives employees approved tools relevant to their function. Full audits must then link the user named in source logs to what the agent tried to do, which tools and parameters it chose, and which attempts were blocked.

A RevOps server can expose Salesforce capabilities, a data team’s server can expose Snowflake Cortex tools, and a knowledge team’s server can expose SharePoint search. Each limits the tools available to its function. The registry acts as an internal app store for agent capabilities, rather than leaving employees to public directories or shared drives. That control over how people find tools helps deal with shadow agents whose local MCP servers connect to production systems that are missing from the security inventory.

How governed permission inheritance scales across an organization without duplicating effort

Five teams that connect to the same Salesforce org can build the same permission logic five times, each with a service account to maintain and a gap in its audits. A governed registry replaces those separate efforts with a shared capability. A skill built by RevOps and published once becomes available to other teams whose members have the appropriate Salesforce permissions.

Each user can reach only the data their source permissions allow, even when several teams use the same published skill. The same governed MCP server can also provide consistent context across Claude, ChatGPT, Cursor, and Slack. Source permission changes then propagate across those AI clients automatically, rather than requiring a separate update to each integration when a role changes.

Snowflake’s gateway guide asks organizations to focus on whether they have a control layer for MCP traffic, beyond whether they have the traffic itself. A registry and gateway make inherited access auditable, revocable, and scoped to the user. The payoff is less duplicated work across the organization. Good permission inheritance is not a constraint on enterprise AI’s usefulness, but what makes that usefulness trustworthy enough to scale.