How to Block AI Agents From Moving SharePoint Files to Personal OneDrive or External Google Drive

Treat it as an enforcement-point question

The useful question is not whether the agent may read a client file. It is where in the agent's execution path a file move can be inspected and stopped. An agent with delegated access reads a file in SharePoint, then calls a tool, connector, MCP server or API that writes the content somewhere else. Access control has already said yes to the read. Nothing in that decision says where the content may go next.

NIST draws this distinction directly. SP 800-171 Rev. 3 describes information flow control as regulating where CUI can transit within and between systems, in contrast to who is allowed to access it. SP 800-53 Rev. 5 states that information-flow enforcement includes prohibiting transfers between connected systems and verifying write permissions before accepting information from another domain. Both point to the same design: evaluate the destination of each transfer, and do it before the transfer completes, independently of whatever authority the agent claims for itself.

Map the paths an agent can use to move a file

Start with an inventory, because the control you need depends on the path. For each write-capable path, record three things: which identity performs the write, which destination the call names, and what, if anything, inspects the call before it executes. The paths below are the usual candidates. Add any others your agents can reach.

The same file can leave through more than one of these paths, so a rule that covers only one of them leaves the others open. The inventory is a living document. Each new tool, connector or MCP server an agent gains adds a row.

• Direct API calls: The agent calls a file API with delegated or application permissions and names the destination drive or folder in the request.
• Connectors: A prebuilt connector performs the copy or upload, often under a connection identity that differs from the user's.
• MCP servers: A tool exposed over MCP accepts a source and a destination and performs the write from wherever the server runs.
• Browser or computer-use actions: The agent drives a web interface and uploads a file the way a person would, through a session on a managed or unmanaged device.
• Agent-written code: The agent generates and runs a script that downloads the file and pushes it to another service.

Separate native coverage from the tool-call gap

Configure the native controls first. Sensitivity labels, DLP, conditional access, cross-tenant access settings and tenant restrictions, SharePoint external sharing limits and OneDrive sync restrictions all reduce exposure, and Google Workspace administrators have their own settings on the destination side. Each was built around a user, a device, a session or a known application. They answer questions about who is signing in, from where, and which label a file carries.

The open question is whether a given control evaluates an individual agent tool call and the destination of that specific file operation. That depends on the path. A write made by an MCP server running outside your tenant boundary, a connector under its own connection identity, and a browser action on a managed device can each be visible to one control and invisible to another. Do not assume coverage. Test each path from your inventory and place it in one of three groups: covered natively and confirmed by test, partly covered, or not evaluated at the tool-call layer.

The second and third groups need enforcement at the agent tool-call layer. The intent is consistent with a NIST CSF 2.0 implementation-examples draft, which lists blocking access to personal email, file sharing and file storage services from organizational systems and networks. An agent calling a tool is an organizational system acting, so the same intent should apply to its writes.

Define a destination-aware policy

Use a deny-by-default, permit-by-exception pattern. NIST describes deny-all, permit-by-exception for software execution, and the same logic applies by analogy to destinations: approved internal locations are named, and everything else is blocked or escalated. Model the agent as its own subject. NIST SP 1800-35 defines zero trust subjects to include non-human entities, and SP 800-171 covers processes acting on behalf of authorized users. The agent should not simply inherit a human's trust.

Evaluate these attributes on every file-writing tool call:

Then map attributes to decisions. Allow when the destination resolves to an approved internal tenant and library and the file's label and client classification permit it. Block when the destination is a personal OneDrive or any Google Drive outside an approved list. Escalate for human approval when the destination cannot be resolved, the account type is unknown, the label is missing, or a link points to an unfamiliar domain. Use redact where policy permits part of the content to move but not all of it.

Scope the rule to writes and destinations, not to reads. Agents continue to search, read and summarize SharePoint content, and internal moves between approved locations continue to work.

• Agent identity: Which agent is acting, and for which user or service.
• Tool identity: Which connector, MCP server or API is performing the write.
• Destination tenant or domain: Where the file is going, resolved from the call itself.
• Account type: Organizational, personal or unknown.
• Sensitivity label: The label on the source file.
• Client or matter classification: Whether the file belongs to a client or matter with transfer restrictions.

Verify the policy with deliberate transfer attempts

Build a test matrix of paths against destination classes. For each path in your inventory, attempt four transfers: to a personal OneDrive, to an external Google Drive, to an approved internal library, and to a destination the policy cannot classify. The expected results are block, block, allow and escalate.

Check outcomes at the destination, not only in the agent's response. Confirm that the blocked file never arrived, not merely that the agent reported an error. For escalations, confirm the approver sees the agent, the file and the destination, that approval releases exactly that transfer, and that denial leaves nothing behind. Also run regression tests for legitimate behavior: reads from SharePoint and moves between approved locations should still succeed.

Repeat the matrix whenever an agent gains a tool, an MCP server is added, or the policy changes. A path that was covered last quarter can be uncovered after a single new connector.

Produce evidence a reviewer can use, and where Trussed fits

Each enforcement event should let a security or compliance reviewer confirm, without reconstruction, what was blocked or approved and why. At minimum, record the fields below. Evidence is only credible if it is generated by the enforcement decision itself, rather than assembled from other records afterward.

Trussed enforces policy in the execution path across agents, tools and MCP servers, on individual interactions and tool calls. It supports allow, redact, block, rate limit and escalate for human approval, enforced at runtime, not reviewed after the fact. Enforcement generates audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency. The scope is the individual tool call, which is the unit this policy needs.

• Agent and tool: Which agent called which tool, connector or MCP server.
• Source file: The file and its label and classification at the time of the call.
• Destination: Tenant or domain, and account type.
• Policy and decision: The policy version applied and the result: allow, redact, block or escalate.
• Approver: For escalated calls, who approved or denied the transfer.
• Timestamp: When the decision was made.