Blocking an Agent from Creating Anonymous or External Sharing Links in SharePoint via the Microsoft 365 MCP Server

Why agent-initiated link creation needs its own control

An agent connected to SharePoint through the Microsoft 365 MCP server can call tools that create sharing links. If the agent's delegated or application permissions allow it, those calls can produce anonymous links or links addressed to external recipients. No person reviews the request before the link exists, and a link to a sensitive document can leave the organization the moment it is created.

Tenant-level sharing settings, site-level restrictions, sensitivity labels and Graph permission scopes each constrain this risk. The gap is granularity. These controls describe what is permitted for an identity, a site or a piece of content. None of them looks at one tool call, reads its parameters and decides whether that specific request is acceptable. A permission scope that allows link creation allows it for every audience the platform supports, unless another setting narrows it.

That is the case for a second layer. Native controls should be configured as tightly as the business allows. Per-call enforcement then covers what remains.

Identify the tool calls that create links

Start with an inventory of the tools your MCP server exposes to each agent. Classify every tool into one of four groups: tools that create a sharing link on a file or folder, tools that grant permissions to named recipients, tools that change or widen an existing link or permission, and tools that copy or export content to a location outside the tenant. The last group matters because a sharing link is not the only way content leaves. A policy that covers only link creation leaves other outbound paths open.

For each tool in the first three groups, record the arguments that determine exposure. These typically include the link audience (anyone, organization, or specific people), the recipient list, the permission level and any expiry. The audience and recipient arguments are the ones your policy will evaluate. Map each MCP tool to the underlying Microsoft Graph operation it invokes, so that a rule written against a tool name still holds if a second tool reaches the same operation.

If an agent does not need to share anything, remove the sharing tools from its toolset. A tool the agent cannot see is a stronger control than a rule that rejects its calls.

Layer two: enforce policy on the MCP tool call

Native controls are coupled to the application they protect. They evaluate what that application knows, and they are unlikely to carry agent-specific context such as which agent made the call or what the call was meant to do. A separate policy enforcement point in the request path closes that gap.

The model is attribute-based access control as NIST SP 800-162 describes it: an authorization decision evaluates attributes of the subject, the object, the requested operation and, where relevant, the environment against policy. NIST SP 800-207 places the same idea at a policy enforcement point, where a request is evaluated before a channel to the resource is established. For this use case, the subject is the calling agent and its user, the object is the target drive item or site and its classification, and the operation is the tool name plus its arguments, notably link audience and recipients.

Trussed enforces policy in the execution path on MCP tool calls, with outcomes of allow, redact, block or escalate for human approval, and the decision is made at runtime, not reviewed after the fact. In this scenario, the policy reads the tool name and arguments of each link-creation request and applies the rule for that scope before the call reaches SharePoint. The same pattern applies to any MCP gateway or enforcement point that can read tool name and arguments.

A starting policy by link scope

Decide the outcome per scope and document it. NIST SP 800-53 Rev. 5 treats anonymous accounts as a type an organization may choose to prohibit. Anonymous link creation is not the same thing as an anonymous account, but the same explicit, recorded decision applies. The table is a design suggestion to adapt, not a standard.

• Anonymous (anyone) link: Block. Treat as default-deny for every agent unless a specific, approved exception exists.
• Link or permission for an external recipient: Escalate for human approval. Show the approver the document, its label, the recipient and the permission level.
• Organization-wide link: Allow or escalate depending on the document's classification and the agent's task.
• Specific internal recipients: Allow within the agent's approved scope, subject to the native controls above.
• Unrecognized tool, audience or argument: Block. An unknown value should never default to permitted.
• Export or copy to an outside location: Apply the same block or escalate rule, so that link restrictions are not bypassed by another path.

Audit evidence and the gaps native controls leave

An enforced decision is only useful to an auditor if it can be reconstructed. The record for each tool call should capture the agent and user identity, the tool name, the arguments evaluated, the target item and its label, the scope that triggered the rule, the policy version, the decision, the approver and outcome for escalations, and a timestamp. These fields are a design proposal, since no standard prescribes them for tool-call decisions, but they answer the questions a reviewer will ask: who requested what, what rule applied, and what happened.

Trussed generates audit-ready evidence from enforcement itself, so the record is a product of the decision and not a reconstruction from separate logs. That evidence is mapped to frameworks including NIST, and it is retained in a self-managed deployment in the customer's cloud with configurable retention and data residency.

The remaining gaps are worth stating plainly. Native controls cannot tell an agent's call from a user's call unless the agent has its own identity, and even then they permit or deny by scope, not by arguments. Runtime policy covers only the calls that pass through the enforcement point, so agents must not have a direct route to the same Graph operations. Escalation also depends on approvers who can judge the request, which is why the approval view should include the document, label and recipient. Test the policy with each audience and recipient type before an agent goes live.