Keeping Agents from Modifying Drive and SharePoint Files on Legal Hold

Why holds and permissions alone leave a gap

A legal hold exists to keep content intact so that nothing relevant is lost or altered. Permission models exist to decide who or what may reach content. Both were built around people and application-level grants. Neither answers the question that matters when an agent is acting: is this specific operation, requested right now, about to touch this specific held file?

Agents make that question urgent. An agent holding delegated credentials can chain several actions quickly, and a request that looks routine, such as tidying a folder, reorganizing documents, or regenerating a summary into an existing file, may overwrite, rename, move, or delete content that someone is obliged to preserve. Digital files are easy to change, and an unwanted edit is hard to prove or reverse after the fact.

The design stance in this guide is therefore simple. Treat native holds and least-privilege scoping as necessary, and do not assume either one stops an agent-initiated write. Add a decision point in the execution path that evaluates each call before it reaches the Drive or SharePoint API.

Layer one: narrow the credential and the scope

The first layer reduces what an agent could do even if every other control failed. Access decisions should rely on least-privilege, per-request, context-based principles, tied to identities for users, services, and devices. For agents, that means an identity of their own rather than a borrowed human session.

Split broad credentials. Rather than one delegated credential serving many purposes, break the deputy into separate entities that each hold a single credential mapped closely to one application or service. An agent that summarizes documents should not share a credential with one that files them.

Restrict permissions and ownership on key folders and files, and avoid administrator-level access for programmatic actors, which can modify shared files that nobody intended to expose. Where an agent only reads, grant read-only access at the API and OAuth scope level and verify that no write-capable scope remains attached to the app registration or client.

• One credential per agent purpose, not one per team or per platform.
• Read-only scopes for any agent that retrieves or summarizes content.
• No administrator or owner-level rights for programmatic identities.
• Separate agents that need write access from agents that do not, and keep write-capable agents away from folders likely to contain held matter content.

Layer two: identify held content at the time of the call

Scoping narrows the surface but cannot know which files are held today. The enforcement point needs a way to answer, for a given file, whether it is under hold at that moment. Common designs combine a maintained list of held locations, matters, or labels, populated from your legal and e-discovery process, with a lookup at call time that resolves the target file or its parent path against that list.

Three decisions matter here. First, freshness: a hold placed this morning must be visible to the next call, so define how quickly the hold list updates and how long a cached answer may be trusted. Second, granularity: decide whether you can resolve at file level or must treat an entire folder, site, or drive as held. Coarser is safer and more disruptive. Third, failure behavior: if the lookup fails or returns an uncertain answer, the default should be to treat the file as held for any modifying operation.

Move and rename deserve explicit attention. A file moved out of a held location can drop out of a path-based match, so resolve hold status on both the source and the destination, and on the file identifier where possible rather than the path alone.

Choosing between block and escalate

Blocking is the right default for delete and overwrite on held content, because there is rarely a legitimate agent-initiated reason. Escalation suits cases where a custodian or legal team may sanction a change, for example a corrected metadata field. Escalation needs an owner: name who can approve, set a timeout that resolves to denial, and record the approver, decision, and reason for each one.

Trussed enforces policy on individual agent tool calls and MCP server interactions in the execution path, with decisions that include allow, block, and escalate for human approval, enforced at runtime, not reviewed after the fact. Its scope is the individual interaction or tool call. It does not provide transaction-level governance or end-to-end tracing of agentic workflows, so the hold list and the surrounding legal process remain yours to maintain.

Evidence to retain

Preservation is only defensible if you can show it happened. Systems holding evidence should have individual authentication, access controls, and logging, so each agent needs its own identity that appears in the record. For each decision, retain the agent identity, the target file and its hold status at the time, the operation requested, the outcome, the timestamp, and for escalations the approver and rationale. Retain the policy version in force so a reviewer can see what the agent was permitted to do.

Protect the records themselves. Hash evidence as close to collection as possible, and use hash chains to make the stored hashes tamper-evident. Where version history is available, keep it as a supporting change trail, and consider monitoring held files for content changes as a detective backstop. It reports a problem after the fact and does not prevent one.

Also check your deletion routines. Scheduled cleanup and retention jobs can conflict with holds, so any automated deletion workflow, agent-driven or not, should consult hold status before it runs. Legal and audit stakeholders will want this evidence exportable, with retention you control.