How to Restrict AI Agent Access to Specific SharePoint Sites and Folders with MCP

AI agents are starting to connect to Microsoft 365, SharePoint, and other enterprise systems through MCP. That creates a useful new automation surface, but it also raises an immediate access-control question: what if the signed-in user has broad SharePoint access, while the agent should only touch one site, library, or folder?

That question shows up quickly in real Copilot Studio and Agent 365 projects. A recruiting agent may need to read and update job-description documents. A legal agent may need one contract library. An operations agent may need a narrow project folder. In each case, user access and agent access should not be treated as the same thing.

The SharePoint MCP problem

Microsoft documents a Work IQ SharePoint MCP server that exposes SharePoint tools for finding sites, working with document libraries, reading files, creating files, moving files, sharing files, and working with lists. In Microsoft’s documentation, the SharePoint Work IQ MCP server ID is mcp_SharePointRemoteServer.

That is powerful because agents can use natural language to work with SharePoint content. It is also sensitive because the MCP server can act with delegated user context. If a user can access many sites, the agent may be able to reach far more than the business workflow actually requires.

Delegated permissions are not agent least privilege

Delegated identity is important. The enterprise still needs to know which user initiated the action. But delegated identity alone does not answer a separate question: what is this agent allowed to do for this workflow?

For human users, broad SharePoint access may be acceptable because they navigate, decide, and are accountable for their own actions. For an AI agent, the safer model is narrower. The agent should be constrained by site, document library, folder, tool, action, and runtime context.

Prompt instructions are not access control

A prompt such as “only use the Job Descriptions folder” can guide the agent, but it is not a security boundary. Prompt instructions can be misunderstood, overridden by conflicting context, or bypassed when the agent chooses a tool path the prompt writer did not anticipate.

Production MCP deployments need deterministic enforcement outside the prompt. If a tool call targets the wrong site, tries to search broadly, or attempts a write action that is not approved for the workflow, the request should be denied before it reaches the downstream MCP server.

A gateway pattern for SharePoint MCP access

A cleaner pattern is to place an identity-aware MCP gateway between the agent and the enterprise MCP server. Copilot Studio supports adding an existing MCP server by entering a server URL, and Agent 365 supports registering remote MCP servers for admin approval through its BYO MCP server flow.

In this model, the agent connects to the Datawiza Agent Gateway URL. Datawiza evaluates the user identity, agent identity, tool name, requested action, and SharePoint target before forwarding the approved MCP request to the underlying SharePoint or Work IQ-style MCP endpoint.

Example: a Job Descriptions agent

Consider a Copilot Studio agent for HR and recruiting. The agent should help create, read, and update job-description files, but only inside a specific SharePoint site and folder.

A least-privilege policy could allow:

• Access only to the approved recruiting site.
• Access only to the Job Descriptions library or folder.
• Read and create draft files for approved users.
• Write actions only for users in the right group.

The same policy could deny:

• Broad SharePoint search across unrelated sites.
• Access to executive, finance, legal, or customer folders.
• Delete, share, or move actions unless explicitly approved.
• Requests that omit the expected site, library, or folder context.

Where Datawiza Agent Gateway fits

Datawiza Agent Gateway provides identity-aware access control for AI agents accessing enterprise systems via MCP servers and APIs. For SharePoint-style MCP use cases, it can enforce least privilege before agent tool calls reach sensitive enterprise data.

The same policy layer can also help security and platform teams audit which user, agent, tool, action, and resource were involved in each request. That matters when AI agents move from demos to production and become part of real enterprise workflows.

For related MCP security patterns, see our guides to MCP server authentication and authorization, MCP gateway vs. API gateway, and why agent API access takes longer than expected in production.

Important note on built-in Microsoft catalog tools

This pattern does not mean every prebuilt Microsoft catalog tool can be modified in place. If a built-in Work IQ SharePoint tool is hardcoded inside a Microsoft-managed path, an external gateway may not be able to insert itself transparently into that exact built-in connection.

The practical deployment path is to register Datawiza Agent Gateway as the custom or BYO MCP server URL where Copilot Studio or Agent 365 supports that model. The agent connects to the gateway endpoint, and the gateway forwards only approved requests to the downstream MCP or API layer.

Final thought

MCP makes it easier for AI agents to use enterprise systems. But easier connectivity should not mean unlimited delegated access. For SharePoint and similar systems, the right production model is identity-aware, policy-enforced, and auditable.

Want to control what your AI agents can access through MCP and APIs? Book a demo with Datawiza to see how Datawiza Agent Gateway can help enforce least-privilege access for enterprise AI agents.

References

Microsoft Work IQ SharePoint MCP server reference

Microsoft Copilot Studio documentation for adding an existing MCP server

Microsoft documentation for managing tools and BYO MCP servers in Agent 365