Keeping Customer Data Out of CrewAI Agent Handoffs Under Regulation S-P

Where customer data moves in a CrewAI handoff

In a multi-agent workflow, one agent's work becomes another agent's input. In CrewAI that happens through several channels: the context supplied to a task, the output an agent returns, memory that persists across steps, and the arguments and results of tool calls. Each channel can carry nonpublic personal information without anyone deciding that it should.

The usual cause is accumulation. A first agent retrieves a customer record to answer a narrow question. Its full output becomes context for a second agent that only needed a summary. That agent passes a fragment into a search tool or a third-party API. No individual step looks like a disclosure, yet the data has crossed three boundaries.

Before designing controls, inventory these channels for each workflow you run. Confirm in testing what actually travels across each one, because defaults differ from what developers assume. For every channel, record which agent writes to it, which agent reads from it, and which tools sit downstream. That inventory is the foundation for every policy you write later.

Mapping handoff channels to Regulation S-P safeguards

As of November 2026, 17 CFR 248.30 requires every covered institution to develop, implement and maintain written policies and procedures with administrative, technical and physical safeguards for customer information. These must be reasonably designed to ensure the security and confidentiality of that information, protect against anticipated threats or hazards to its security or integrity, and protect against unauthorized access to or use of it that could result in substantial harm or inconvenience to a customer.

Customer information is defined as any record containing nonpublic personal information about a customer, in any form, that the institution possesses or that is handled or maintained on its behalf. For design purposes, treat data held in agent state or passed between agents as within that definition, and have counsel confirm how the rule applies to your agent systems.

The 2024 amendments add two requirements that bear directly on handoffs. The first is a program to detect, respond to and recover from unauthorized access to or use of customer information, including customer notification. Assessing an incident means identifying which systems and which types of customer information were involved. The second is oversight of service providers, which can reasonably extend to model providers and tool vendors that receive customer information in a handoff. Counsel should confirm that interpretation.

• Task context and agent outputs: Confidentiality and unauthorized access: limit what the next agent receives to what its task needs.
• Memory: Unauthorized use: control what is written to shared state and which agents can read it.
• Tool inputs: Service provider oversight: control what customer information leaves for external tools and vendors.
• Tool outputs: Incident scoping: know which data types came back into the workflow and where they went next.

Designing enforcement at the interaction and tool call level

Enforcement has to sit in the execution path, so that a decision is made before data moves rather than after a reviewer finds it. Prompt instructions telling an agent not to share customer data are one control among several. They are not an enforced restriction, and they should not be the only barrier.

Start with entitlements. Define which agents may receive which data types, and which tools may be called with them. Apply attenuation on delegation: a sub-agent should never receive broader data or tool permissions than the agent that delegated to it. Use ephemeral, task-scoped credentials for tool access instead of static reusable secrets.

Then choose an outcome for each combination of agent, tool and data type. Four are practical.

• Allow: The agent and tool are entitled to the data type. Permit the call and record the decision.
• Redact: The task does not need the identifying fields. Remove or mask them before the data crosses the boundary.
• Block: The recipient has no entitlement. Stop the interaction or tool call and return a defined refusal.
• Escalate: The action is consequential or ambiguous. Hold it for human approval before it proceeds.

Limits and tradeoffs of each pattern

Redaction depends on detection. Structured identifiers such as account numbers are easier to catch than personal details embedded in free text, so expect misses and tune policies against real workflow traffic. Redaction can also degrade task quality when an agent needs the removed field, which is a design signal to revisit the agent's scope.

Blocking is the most reliable outcome but the most disruptive, since a blocked call can stall a workflow unless you design a fallback. Allow-lists are only as current as their maintenance, and they need an owner and a change process. Because the written policies and procedures must be maintained, version the enforcement rules and document changes to them.

Human approval does not scale to every call. Reserve it for consequential actions and sensitive data, and keep the approval request specific enough that a reviewer can decide quickly.

The evidence enforcement should produce

Regulation S-P does not prescribe a log format for agent controls, so treat the following as good practice rather than a stated requirement. The goal is to show afterward what was permitted, redacted or blocked, and to scope an incident quickly if one occurs.

For each decision, capture the agent and tool involved, the data types detected, the policy and policy version applied, the outcome, and the time. Where a human approved or rejected an action, record who decided and when. Records should be generated by the enforcement itself, not reconstructed from application output, so they reflect what the control actually did.

Set retention and data residency with legal and compliance input, and make both configurable. Evidence about customer data flows is itself sensitive, so decide where it is stored and who can read it before you deploy.