Reg S-P Customer Information Safeguards Checklist for CrewAI and OpenAI Agents SDK Multi-Agent Systems

What the amended rule asks of a covered institution

Under the amendments, covered institutions are any broker or dealer, investment company, registered investment adviser, or transfer agent. Each must develop, implement, and maintain written policies and procedures addressing administrative, technical, and physical safeguards for customer information. As of November 2026, the current eCFR text of 17 CFR 248.30 also requires an incident response program reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information.

That program must include procedures 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 to prevent further unauthorized access or use. It must also include procedures for notifying affected individuals whose sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization.

Notice is due as soon as practicable, but not later than 30 days, after the institution becomes aware that unauthorized access or use has occurred or is reasonably likely to have occurred. The United States Attorney General may determine that notice poses a substantial risk to national security or public safety, which can delay notice for up to 30 days beyond the original deadline. On service providers, the rule's provisions include a requirement that the provider notify the covered institution as soon as possible, and no later than 72 hours, after becoming aware of a security breach resulting in unauthorized access to a customer information system it maintains.

Where customer information moves in a multi-agent system

CrewAI and the OpenAI Agents SDK are different frameworks, but a deployment built on either one creates the same four kinds of exposure. Agents invoke tools that query or write to internal systems. Agents pass work and context to one another. Context or memory accumulates content that later steps can read. Prompts and tool results are sent to a model provider outside the institution. Each of these is a place where customer information can be read, forwarded, or transmitted.

The rule's scope assessment duty has a direct architectural consequence. To identify which customer information systems and data types an incident touched, a firm needs to know which agents, tools, and providers could reach them. If that map exists only as a design diagram, it will not reflect what agents actually did. Confirm framework-specific behavior against your own code and the vendor documentation for the versions you run, because defaults for tool access, handoff content, and context persistence are implementation details that change.

A further point from published NIST security work on multi-agent systems: point-in-time testing cannot characterize how such a system behaves. That argues for controls that act on each interaction as it happens, not only for review before release.

Runtime controls versus procedural obligations

Some items on the checklist can be enforced on the individual interaction. Whether an agent may call a tool, whether a field is redacted before a handoff or model call, whether a request is blocked, and whether a sensitive action waits for human approval are all decisions that can be applied at runtime. Controls reviewed after the fact can show that something went wrong, but they do not prevent the exposure. For a safeguards program, the stronger position is that the technical controls in your written policies are the ones the system actually enforces.

Other obligations remain organizational. Writing the policies, training staff, deciding when notice is required, handling an Attorney General delay, negotiating provider contracts, and reviewing incident outcomes are procedural. A runtime layer can supply facts to these processes, but it does not replace them. The classification of each control is the firm's own judgment, and it should be written down so that the policy distinguishes what is enforced from what is reviewed.

There is a tradeoff to plan for. Tighter runtime rules reduce exposure but can interrupt legitimate agent tasks, so redaction and escalation thresholds should be tuned with business owners before they are applied to production traffic.

Evidence to design for

Reg S-P does not prescribe a format for AI agent records, so the evidence set is a design choice that should support your own policies and incident procedures. Useful records answer a short list of questions. What was each agent permitted to do? Which tool calls, handoffs, and model provider calls occurred, and what was the policy decision on each: allowed, redacted, blocked, or escalated? Who approved escalated actions? Which customer information systems and data types were involved?

Those records serve two purposes. During an incident, they let you assess scope per agent instead of reconstructing it from memory. During an examination, they let you show that the safeguards described in your written procedures operated as stated. Link the records to the checklist items above so each requirement has a corresponding artifact.

Set retention and data residency for this evidence deliberately, and align both with your recordkeeping obligations and with where customer information is allowed to reside. Evidence that itself contains customer information needs the same safeguards as the systems it describes.

Where a runtime enforcement layer fits

A runtime enforcement layer sits in the execution path between agents and the tools, models, and data they use. It complements existing compliance processes. It does not take over incident response, notification decisions, or vendor management. Its role is to apply the policy decisions in items 2 and 3 of the checklist and to produce records for items 1, 4, and 5.

Trussed is one example. It enforces policy in the execution path across models, agents, tools, and MCP servers, with actions to allow, redact, block, rate limit, or escalate for human approval. Its scope is individual interactions and tool calls. It does not provide workflow-level tracing or transaction-level governance across agents. Trussed generates audit-ready evidence from enforcement, currently mapped to HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. Reg S-P is not among those mappings, so the evidence would support a firm's own Reg S-P mapping and not serve as a built-in one. It can be self-managed in the customer cloud, with configurable retention and data residency.

Whatever you evaluate, ask the same questions. Does it act before the call completes? Does it cover both tool calls and model provider calls? Can its records be tied to a specific agent and decision? Can you control where the records are stored and how long they are kept?