How to Stop an Agent From Deleting or Overwriting SharePoint Files Under Books-and-Records Retention

What an agent can do to a retained record

An agent reaches SharePoint through Microsoft Graph, a connector, or an MCP server. Whatever the path, destructive behavior reduces to a short list of operations. Each one is a distinct tool call with its own method and parameters, so each needs its own rule.

The list below is the starting inventory for a policy. The enforcement condition describes what a runtime rule should look for before the call is forwarded.

• Delete: Removes a file or folder. Block against any retained location.
• Overwrite by upload or replace: Writes new content over an existing file. Block when the target path already exists in a retained location.
• Move: Relocates a record out of a retained location. Evaluate both source and destination.
• Check-in: Commits changes to a checked-out file. Treat as a write and apply the same rule as overwrite.
• Version purge: Deletes prior versions of a file. Block outright for agents, since earlier versions are part of the record history.
• Recycle bin purge: Permanently removes items already deleted. Block outright for agents.

What platform retention covers, and where it stops

Retention labels, retention policies, preservation hold libraries, records declaration and sensitivity labels operate at the content and tenant layer. They define what must be preserved. They do not evaluate the intent or parameters of an individual agent tool call, and they do not know whether a call came from an agent that should never have been attempting it.

Three gaps recur in agent deployments. Over-broad OAuth scopes let an agent attempt operations its task never needed. Service principals using application permissions can act without user-level checks applying. And overwrite and version behavior may differ across operations and configurations, so a control that stops a delete may not stop a replace.

Do not assume. Build a test matrix: run each operation in the table above with the agent's actual credential against a retained location in a non-production tenant, and record whether it was refused, preserved a recoverable copy, or succeeded. The results show which operations the runtime layer must block outright and which have a tested backstop. Keep platform retention enabled either way. Runtime enforcement adds a layer and does not replace it.

What the books-and-records objective asks of agent actions

As of November 2026, SEC Rule 17a-4 (17 CFR 240.17a-4) governs records preserved by certain exchange members, brokers and dealers. The Commission's electronic recordkeeping material describes retention periods for records required under Rule 17a-3 as generally three or six years. It describes the objective of the WORM requirement as preventing the alteration, over-writing or erasure of records.

That material also describes an audit-trail alternative. It records, among other things, the individuals creating, modifying or deleting a record, and it must permit re-creation of the original record and its interim iterations. By itself it would prevent neither a change nor a deletion. It makes the original recoverable.

For agents, the mapping is direct. Under the WORM objective, delete, overwrite, move and version-purge calls against retained records should not succeed. Under the audit-trail approach, every such action needs an attributed record and a tested path to recover the original. Confirm with counsel which approach your firm relies on, checked against the current rule text. Federal agency records rules such as 36 CFR Part 1236 also call for preventing unauthorized modification or deletion and keeping audit trails. They apply to federal agencies, so treat them only as an analogous control reference.

Build the layers in order

Start with identity and permissions, because every later control depends on knowing which agent acted and with what authority. Then fix where records live, confirm the platform backstop, and put enforcement in the path of every route the agent can use.

• Give each agent its own identity: Separate it from human users and shared service accounts, with its own credential lifecycle, so logs and decisions attribute actions to the agent.
• Attenuate delegated authority: An agent acting for a user should never hold more authority than that user. Downstream tools should receive no more than the agent holds.
• Apply least privilege: Default to read-only. Grant write only where the task requires it, prefer grants scoped to specific sites over tenant-wide write, and avoid broad application permissions.
• Segregate retained records: Keep records in defined sites and libraries separate from working content, so a rule can name a location and block destructive calls against it.
• Confirm the platform backstop: Apply retention, records and hold configuration to those locations and verify it with the test matrix.
• Cover every route: Put the enforcement point in the execution path for each Graph call, connector and MCP server the agent can reach, so no route bypasses it.

Runtime policy for tool calls

Policy enforcement in the execution path evaluates each call before SharePoint receives it. Useful conditions are the operation, the target site and library, the agent identity, the initiating principal, and the call parameters. The decisions follow from those conditions.

Allow reads, including search and download, within the agent's granted scope. Block delete, replace, check-in, move and version-purge calls against retained locations. Redact where returned content should not reach the agent or the user it serves. Escalate genuine exceptions, such as a records manager correcting a misfiled document, to a human approver. The approved call should run once, against a named target, and the approval should expire.

Trussed enforces policy in the execution path across agents, tools and MCP servers, scoped to individual interactions and tool calls, with allow, redact, block, rate limit and escalate for human approval. Decisions are enforced at runtime, not reviewed after the fact. How exceptions are approved, and by whom, is an organizational decision that the policy should reflect and not invent.