Agent Tool Outputs as Sensitive Customer Information Under Regulation S-P

What the rule defines and what it leaves to analysis

The 2024 amendments to Regulation S-P were effective August 2, 2024, and the current rule text reflects them as of November 2026. They affect five categories of covered institutions: broker-dealers other than notice-registered broker-dealers, funding portals, registered investment advisers, investment companies, and transfer agents registered with the Commission or another appropriate regulatory agency.

For covered institutions other than transfer agents, customer information means any record containing nonpublic personal information about a customer of a financial institution, in paper, electronic or other form, that is in the covered institution's possession or is handled or maintained by it or on its behalf. The definition applies whether or not the information pertains to the institution's own customers. Sensitive customer information is any component of customer information, alone or in conjunction with any other information, the compromise of which could create a reasonably likely risk of substantial harm or inconvenience to an individual identified with the information. The rule's examples include customer information uniquely identified with an individual that has a reasonably likely use as a means of authenticating that individual's identity.

The rule does not mention agents, tool calls or MCP servers. Everything that follows is a way to apply the definitions to agent tool outputs, and the resulting classifications are decisions for your compliance function and counsel.

Mapping tool output categories to the definitions

Two features of the definitions drive the mapping. Customer information is record-based and form-neutral, so a JSON response from an API is a record like any other. Sensitive customer information turns on harm and on combinations, so a single field should not be judged in isolation. The table gives a starting position for each category, to be recorded per tool and per field with your reasoning.

• Account identifiers: Account numbers, customer IDs and names tied to accounts. Likely records containing nonpublic personal information about a customer. Sensitivity depends on whether compromise, alone or with other fields, could support fraud or identity theft.
• Authentication data: Credentials, tokens, security answers and access devices. The most direct textual hook, since the rule's examples cover information with a reasonably likely use as a means of authentication. Treat as sensitive by default.
• Transaction details: Balances, trades, payees and dates. Customer information when tied to an identifiable customer. Apply the harm test and consider what else the same call or session returns.
• Derived or aggregated values: Model summaries, scores and rolled-up figures. The definition does not turn on form, so decide case by case. Whether aggregated data falls outside the definition is an interpretation question for counsel. Treat anything linkable to an individual as in scope for evaluation.
• Free-text fields: Case notes, ticket comments and email bodies. The definition is not limited to structured fields, so inspect content rather than field names. These fields can carry any category above.
• Combinations across calls: Fields returned by separate calls or merged by the model. Because the test reads 'alone or in conjunction with any other information', evaluate what the model context holds in aggregate, not only each response.

Choosing the runtime action for each classification

Classification only matters if it changes what happens. The rule requires written policies addressing administrative, technical and physical safeguards, with one objective being protection against unauthorized access to or use of customer information that could result in substantial harm or inconvenience. Runtime actions are the technical expression of that objective for agent access. The rule does not prescribe these actions, so treat the following as design options tied to your classification outcomes.

Allow when the output is not customer information, or the task and the requesting user's authorization justify it. Redact when the task needs the record but not the sensitive component, such as returning a transaction summary without the full account number. Block when the output is authentication data, or when no authorization supports the request. Escalate for human approval when classification is ambiguous, the potential harm is high, or a free-text field cannot be reliably inspected. Rate limit when volume is the risk, for example repeated retrieval of many customer records within one session.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval actions. Its scope is individual interactions and tool calls, which matches the unit of analysis used here. Because enforcement happens at runtime, not reviewed after the fact, the decision is made before the output reaches the model or the user. Your compliance team still owns the classification decisions that the policy expresses.

Service providers, governance and next steps

Because customer information includes records handled or maintained on the covered institution's behalf, third-party tools and MCP servers that return customer information warrant assessment as service provider relationships. The rule text includes a service provider element: protect against unauthorized access to or use of customer information, and notify the covered institution as soon as possible, no later than 72 hours after becoming aware of a breach in security resulting in unauthorized access to a customer information system the provider maintains. Check that tool provider arrangements support that notice, and that you have a workflow able to receive and act on it.

A practical sequence is to inventory every tool and MCP server an agent can call, then classify returned fields by category with written reasoning. Next, mark the points in the execution path where each category appears and assign an action to each. Finally, confirm that the evidence in the checklist exists for a sample of real tool calls. Flag aggregated and model-derived values as open questions and resolve them with counsel rather than by default. Agent access controls should trace back to your written safeguards policies, so that an examiner can follow the line from policy to enforcement to evidence.