Reg S-P Service Provider Oversight When Agents Use Slack, Microsoft 365, and Google Drive MCP Servers

What the amended rule requires of service provider oversight

Regulation S-P is codified at 17 CFR 248.30. The final amendments were published in the Federal Register on June 3, 2024, and as of November 2026 the current rule text includes the service provider provisions.

The incident response program must include the establishment, maintenance and enforcement of written policies and procedures reasonably designed to require oversight of service providers, including through due diligence and monitoring. Those policies must be reasonably designed to ensure the institution notifies affected individuals as the rule sets out. They must also ensure service providers notify the institution as soon as possible, and no later than 72 hours after becoming aware of a breach in security that resulted in unauthorized access to a customer information system the provider maintains.

Two points matter for governance. First, an institution may sign a written agreement under which a provider notifies affected individuals on its behalf, but the obligation to ensure notification stays with the institution. Second, the program must include procedures to assess the nature and scope of an incident and to identify the customer information systems and types of customer information that may have been accessed or used without authorization. The word "enforcement" in the rule text signals that documented policy alone is not the standard.

The rule defines a service provider functionally: any person or entity that receives, maintains, processes, or is otherwise permitted access to customer information through services provided directly to a covered institution.

The data paths MCP servers create

An MCP server exposes tools that an agent can call. Each call carries content in two directions: what the agent sends (a query, a message body, file content) and what comes back (messages, document text, file contents). When the platform behind the server holds customer information, each call is a path through which that information can be read, written or moved. The tools a given server exposes, and the permissions behind them, depend on the server and its configuration.

In Slack, the exposure is conversational. Channels and threads often contain customer details pasted in during support or operations work. An agent that reads a channel to summarize it, or posts a draft reply, can pull customer information into a model context or push it into a wider audience.

In Microsoft 365, the exposure is documents and mail held in collaboration storage. An agent that searches, reads or drafts content can combine customer information from several documents in one response.

In Google Drive, the exposure is stored files and shared locations. Search, read, create and sharing actions each carry different risk, and a sharing action changes who can access the file.

These paths have several hops: agent to MCP server, server to platform, and often a model in between. NIST guidance on zero trust describes per-request, least-privilege authorization and credential authentication at each hop. That is general architecture guidance, not a Reg S-P requirement, but it is a useful model for the agent path.

Because the service provider definition is functional, each path should be assessed against it. Whether a particular MCP server, whether operated by the platform or by a third party, falls within the definition is a question for legal review.

What contracts and diligence cover, and what needs runtime enforcement

Contracts, due diligence and periodic review operate before or around the moment of use. They are necessary, but they cannot see an individual tool call. The split below is an analytical reading of the rule, not language from it.

• Selection and safeguards: Contracts and diligence: security review of the provider and connector, and contractual safeguard terms. Runtime: policy deciding what each call may read or write.
• Monitoring: Contracts and diligence: periodic review and provider reporting. Runtime: visibility into agent activity as calls occur, not only at review time.
• 72-hour breach notice: Contracts and diligence: notification clauses and escalation contacts. Runtime: does not replace provider notice, but limits and records what the agent exposed.
• Incident scoping: Contracts and diligence: documented assessment procedures. Runtime: per-call records showing which systems and information types the agent touched.
• Customer notification: Contracts and diligence: any written agreement for a provider to notify on the institution's behalf. Runtime: not applicable; accountability stays with the institution.

Audit-ready evidence for agent tool calls

An examiner reviewing service provider oversight will want more than a policy document. No evidence format is prescribed in the rule, so the practical test is whether the record answers the questions the rule raises: what did the agent touch, under what policy, and what was permitted to leave.

A useful per-call record includes the agent identity and the user or process it acted for, the MCP server and tool called, the platform involved, the policy version applied, the action taken (allow, redact, block, rate limit or escalate), the categories of customer information detected, any approval and approver, and a timestamp. Records of this kind support the incident-scoping procedures, because they let the institution identify which customer information systems and information types were touched. Retention periods and data residency for these records are decisions to settle with counsel.

Trussed enforces policy in the execution path across agents, tools and MCP servers, at the level of individual interactions and tool calls. Audit-ready evidence is generated by that enforcement rather than assembled after the fact, so the record reflects what was enforced at runtime. Deployment is self-managed in the customer cloud, with configurable retention and data residency.