Reg S-P Access Controls for AI Agents That Read Customer Account Records

What Reg S-P asks for, and what it leaves to design

Regulation S-P (17 CFR 248.30) requires every covered institution to develop, implement and maintain written policies and procedures addressing administrative, technical and physical safeguards for customer information. Those policies must be reasonably designed to protect against unauthorized access to or use of customer information that could result in substantial harm or inconvenience to any customer.

The final amendments, published in the Federal Register in June 2024, add detail on the response program. As of November 2026, the current text requires a program reasonably designed to detect, respond to and recover from unauthorized access to or use of customer information, including customer notification procedures. The program must include steps to assess the nature and scope of an incident, identify the customer information systems and types of customer information involved, and contain and control the incident. Detected unauthorized access and the response to it must be documented in writing. The program must also include policies requiring oversight of service providers.

An AI agent that reads account records through a tool, API or MCP server is a path to customer information, so these provisions apply to it. The standard is "reasonably designed," which means the institution has to be able to explain why an agent's access was shaped the way it was. Explicit least-privilege language is easiest to find outside Reg S-P. The FTC Safeguards Rule (16 CFR 314.4) calls for limiting authorized users' access to the customer information they need for their duties, and its definition of authorized user includes agents. NIST SP 800-53 Rev. 5 describes least privilege for processes acting on behalf of users. These are useful reference points, but they are not Reg S-P obligations, and a compliance mapping should keep them labeled that way.

The FTC's 2021 release adds one idea worth borrowing: the access-control provision does not prescribe particular measures, and more sensitive information may warrant more stringent controls. That supports a tiered design in which not every read of customer information is treated alike.

Where each control belongs: identity, data and runtime

Separating the layers makes it clear what each can and cannot do for an agent.

The identity layer authenticates the agent and the person or service on whose behalf it acts, and assigns least-privilege scopes. The limit, as a matter of design, is that identity typically decides who may connect, not whether a particular record or field is appropriate for the task at hand. A single broad service credential used by several agents defeats per-task scoping, because every agent inherits the widest permission.

The data layer classifies customer information and applies field-level restrictions. Reg S-P's definition of sensitive customer information is a practical anchor: one limb covers information identifying an individual or account, such as an account number, name or online user name, combined with authenticating information that could be used to gain access to the account. Classifying fields this way before deciding agent behavior gives the policy something concrete to refer to.

The runtime layer makes the decision at each tool call. Because an agent is a process acting on behalf of a user or service, authorization applies to every call, not only at login. A decision made and recorded at the call is also what lets you later show what the agent was permitted to do and what it did. Trussed is one way to do this: it enforces policy in the execution path across agents, tools and MCP servers, with allow, redact, block, rate limit and escalate outcomes applied to individual interactions and tool calls. Enforced at runtime, not reviewed after the fact, the decision happens before data reaches the model.

Defining which agent reads are allowed, redacted, blocked or escalated

Start by inventorying the agents, tools, APIs and servers that can reach customer account records, and the credentials each one uses. This inventory also supports the incident response requirement to identify the systems and types of customer information involved.

Next, define a read scope for each task, then map each field class to one of four outcomes. The four outcomes are a design recommendation, not a Reg S-P requirement. Write the mapping down and tie it to the reasonably designed standard, so the rationale for each scope is reviewable.

• Allow: Field classes that the task needs and that carry low sensitivity, requested under a credential scoped to that task.
• Redact: Records the task needs where an account number or authenticating data is not needed. Remove or mask the field before it reaches the model.
• Block: Reads outside the task's scope, reads of authenticating information the task never requires, and calls from an agent without a valid acting principal.
• Escalate: Sensitive reads that may be legitimate but warrant human approval, with the decision and approver recorded.

Incident response, service providers and governance

The response program expects the ability to contain and control an incident to prevent further unauthorized access or use. For agents, that means being able to revoke or block an agent's access quickly, without waiting for a credential rotation across every system the credential touches. Test this the same way you would test any containment step.

Service provider oversight is the other place agents create exposure. Reg S-P defines a service provider as any person or entity that receives, maintains, processes or is otherwise permitted access to customer information through services provided directly to the covered institution. An AI vendor or hosted tool that can access customer information may meet that definition, though that is a legal determination for each institution. Where it does, the policies must be reasonably designed to ensure the provider takes appropriate measures to protect customer information and notifies you as soon as possible, and no later than 72 hours, after becoming aware of a breach involving a customer information system it maintains. Oversight includes due diligence and monitoring. The final amendments replaced a proposed written-contract requirement with this policy-based approach, so contract terms alone do not discharge it.

On governance, assign an owner for agent access policies and a review cadence. A periodic review of access controls appears in the FTC rule, which makes it a reasonable practice here but not a Reg S-P requirement. Record changes to scopes, redaction rules and escalation thresholds, and keep the Reg S-P text separate from FTC and NIST references in your mapping.