Regulation S-P Disposal Rule and AI Agents: Preventing Client Data Copies in Google Drive and SharePoint

What the disposal rule asks of a covered institution

Under Regulation S-P (17 CFR 248.30), every covered institution must develop, implement, and maintain written policies and procedures covering administrative, technical, and physical safeguards for customer information. The disposal standard adds that covered institutions, other than notice-registered broker-dealers, must properly dispose of consumer information and customer information by taking reasonable measures to protect against unauthorized access to or use of the information in connection with its disposal. They must also adopt written policies and procedures that address that disposal.

The 2024 amendments, published in the Federal Register on June 3, 2024, broaden the information covered by the safeguarding requirements and by the requirements for properly disposing of consumer report information. They add an incident response program, which must include procedures to assess the nature and scope of an incident and to contain and control it. They also require written records documenting compliance. Compliance timing should be confirmed against the current rule text as of November 2026.

The rule text is technology-neutral and does not mention AI agents. Applying it to agent output is interpretation. A reasonable reading is that a summary, export, or extract containing consumer or customer information falls inside your disposal procedures if it persists. Have counsel confirm where your institution draws that line, then write the definition into the procedures.

How agents create copies of client data

An agent with file-system tools does not need to be malicious or malfunctioning to leave copies behind. Ordinary task completion produces them. The common paths are the same in Google Drive and SharePoint, although each platform handles the details differently. Inventory every tool exposed to every agent, because the tool list defines the copy surface.

• New files from summarization: The agent reads a client record and writes a summary, briefing, or draft into a new document that now holds client data.
• Exports and format conversions: A spreadsheet or report is exported to another format or location, producing a second copy outside its original container.
• Duplicates and moves: Copy and move actions place client files in folders with different access and retention handling.
• Temporary artifacts: Intermediate files written during multi-step tasks, such as extracted text or staging documents, are often never cleaned up.
• Sharing links and permission changes: A share action extends access to the copy, which widens the unauthorized-access exposure the disposal standard addresses.
• Version history and deleted-item retention: Deleting an agent-created file may not remove every retained version or recycled item. Confirm how your tenant is configured.

Why prevention at the tool call beats cleanup

Discovery and deletion after the fact depends on finding every copy, and agent-created files are hard to find because they carry no reliable marker of origin. They land under whichever identity the tool ran as, in whichever folder was reachable. Identity itself is a design question. Cloud access controls are typically identity-based, so you must decide whether an agent's call runs as the requesting user, a service account, or a distinct agent identity. The choice determines what the platform's own controls can see and restrict.

Native retention, sensitivity labeling, data loss prevention, and deletion settings in Google Workspace and Microsoft 365 remain necessary. Verify their behavior against vendor documentation, and test whether they act on writes initiated by an agent through an API tool. Whatever they do, they act on the resulting file. A control in the agent's execution path acts on the request, before the copy exists. That is the difference between preventing a disposal problem and creating one to be remediated.

There is also an incident response consequence. If an incident occurs, the institution must assess its scope and contain it. Unknown copies make scoping slower and containment less certain. A record of each agent write, with its location, narrows that work.

A policy pattern for file-write and file-share actions

The pattern below uses a small, bounded decision set so that every tool call resolves to an outcome that can be explained later. It applies per interaction or tool call, not per project or workflow.

• 1. Classify actions by effect: Tag each tool action as creates a file, duplicates, exports, changes sharing, or deletes. Policy attaches to the effect, not the tool name.
• 2. Evaluate three inputs: For each call, assess the sensitivity of the content, the destination location, and the identity the agent is acting under.
• 3. Define approved destinations: Allow agent writes only to containers with known retention and disposal handling. Block or escalate writes anywhere else.
• 4. Redact before writing: When content derived from client data is permitted in an output, remove or mask the identifying fields before the write executes.
• 5. Restrict sharing by default: Block link creation and permission changes on agent-created files unless a human approves the specific action.
• 6. Record every decision: Store the decision and its rationale with the call details, so that allowed actions are as documented as blocked ones.

Evidence that shows what the agent was permitted to do and what it did

Because the rule requires written policies and written compliance records, the useful question is whether your records connect the two. A policy document states what should happen. A runtime record states what did happen on each call.

For each tool call, record the agent identity, the requested action, the target location, the data classification result, the policy decision, and the outcome. Retain the policy version in force at the time, so an examiner can see which rule produced which decision. Document who owns the disposal policy and why the chosen controls are reasonable for agent-created data.

Test the controls with realistic scenarios: summarize a client file into a new document, export a record, create a share link, write outside an approved folder. Retain the results as evidence of effectiveness. This is good practice rather than stated rule text. Action logs and decision records are candidate evidence for the written-records requirement, and counsel should confirm they are sufficient for your institution.

Finally, document how disposal reaches the copies agents are allowed to create. Writes confined to approved destinations inherit those destinations' retention and disposal handling, which gives the written procedure something concrete to point to.

Where runtime enforcement fits

Trussed enforces policy in the execution path across models, agents, tools, and MCP servers. For this problem, that means a Drive or SharePoint tool call can be allowed, redacted, blocked, rate limited, or escalated for human approval at runtime, not reviewed after the fact. Enforcement operates on individual interactions and tool calls, and it generates audit-ready evidence of each decision. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency.

It is one layer. Native retention, labeling, and DLP settings in Google Workspace and Microsoft 365 still need to be configured, and the written disposal procedures remain the institution's responsibility. When evaluating any control, ask whether it can stop an action before it executes, what record it produces for each call, how redaction decisions are captured, and how it relates to the native settings it assumes are in place.