Keeping customer information out of persisted CrewAI Flow state under Reg S-P

Where customer information enters Flow state

A CrewAI Flow can keep structured state between steps and between runs. Whatever is written into that state, and persisted, lives in the persistence backend until something deletes it. That makes the state object a retention surface, even though it was designed as a coding convenience.

There are three practical entry points. User inputs can carry customer information directly, for example when a request is copied into a state field so later steps can read it. Tool results can return account records, documents or query output that a step then assigns to state. Model outputs can restate or summarize customer information that was present in the prompt, and a step that stores the full response keeps all of it.

It also helps to separate persisted state from transient execution context. Values that exist only while a step runs, such as local variables and in-memory objects, disappear when the run ends. State that is persisted is serialized to a durable backend so a run can resume or a later run can read it. Customer information that stays in transient context is a smaller exposure than the same information in a stored record. Before changing anything, inspect what your own persistence configuration actually serializes by running a test Flow with synthetic customer data and reading the stored record.

Why persisted state matters under Reg S-P

As amended in 2024, Reg S-P defines customer information, for covered institutions other than transfer agents, as any record containing nonpublic personal information about a customer of a financial institution. The definition applies to paper, electronic or other form, and to records in the institution's possession or handled or maintained by it or on its behalf. On a plain reading, a persisted state record containing nonpublic personal information could fall within that definition, and a third-party-hosted backend could be a place where records are maintained on the institution's behalf. Have counsel confirm how this applies to your arrangements.

Section 248.30, as of November 2026, requires every covered institution to develop, implement and maintain written policies and procedures covering administrative, technical and physical safeguards for customer information. The section also sets a customer notice deadline of no later than 30 days after the institution becomes aware that unauthorized access to or use of customer information has occurred or is reasonably likely to have occurred. It includes a provision requiring a service provider to notify the institution no later than 72 hours after becoming aware of a breach of a customer information system it maintains. The title of the section also covers disposal of customer information.

The consequence for platform teams is direct. Every additional system that holds customer information widens the scope of safeguards, incident assessment and provider oversight. NIST SP 800-122 gives a data minimization example, requesting PII only where it is absolutely necessary, and the same logic supports keeping customer fields out of state by default.

Design state and persistence boundaries to exclude customer data

Application-level design can remove most exposure before any runtime control is needed. Start from the schema, because the schema decides what can be persisted at all.

The patterns below can be combined. Each one changes what a resumed Flow can do, so test resumability rather than assuming it.

• Typed state models without customer fields: Define state with explicit, typed fields for workflow data such as step status, identifiers and routing decisions. Avoid free-form string or dictionary fields that invite whole responses or records. Trade-off: steps that need customer content must fetch it again.
• References or tokens instead of raw values: Store an opaque record identifier or token and resolve it inside the step that needs the value, under access controls in the source system. Trade-off: a resumed Flow depends on the lookup service being available and on the token remaining valid.
• Persist selectively: Persist only the state that must survive a restart, and keep customer-bearing intermediate results in transient context within a step. Trade-off: if a run fails mid-step, that step starts over.
• Filter tool output before assignment: Have each tool return only the fields the next step requires, and assign those fields to state rather than the raw result. Trade-off: filters must be maintained as tools change.
• Treat the backend as in scope: Apply access controls and encryption at rest to the persistence backend. Encryption reduces exposure to direct theft from storage, but it does not take customer information out of durable storage.

What design alone cannot guarantee

A well-typed schema stops a developer from adding a customer field. It does not stop a permitted field, such as a summary or notes string, from receiving customer information at runtime. A model can place a name or account number into any text field it is asked to fill, and a tool can return more than expected after an upstream change. Code review catches the first case once; it does not observe the thousandth run.

That gap is the argument for enforcement in the execution path. The control has to act on the content moving through model calls and tool calls, before a step assigns it to state, so that a policy applies to every interaction rather than to the interactions someone remembered to review.

Enforce allow, redact and block at model and tool-call boundaries

Runtime policy enforcement works on individual interactions. For a Flow, the useful boundaries are the request going to a model, the response coming back, the call to a tool and the result it returns. At each one, a policy can take one of three actions.

Allow lets content pass when it contains nothing the policy restricts. Redact removes or replaces restricted values, such as account numbers or government identifiers, so the step receives a sanitized result and the Flow can continue. Block stops the interaction when it should not proceed, for example when a tool result is a full customer record that no step is permitted to receive. Choose redact where the Flow can continue with partial content and block where continuing would be unsafe, and make sure Flow logic handles a blocked call explicitly instead of writing an error payload into state.

Trussed is one way to apply this. It enforces policy in the execution path across models, agents and tools, with allow, redact and block actions applied to individual interactions and tool calls, and it produces audit-ready evidence from that enforcement. Its scope is the interaction and the tool call. It does not trace a whole workflow end to end, so state written by application code that never passes through a model or tool call still depends on the schema and persistence design described above.

Evidence that the controls operated

Section 248.30 centers on written policies and procedures, so the evidence should show that the controls were designed as written and operated as written. Encryption alone shows data was protected after it was stored. It does not show that customer information was kept out.

A workable set includes the written policy that states what agent state stores may hold and who may access them, the state schema definitions under version control, and test results from synthetic customer data that confirm stored records contain no customer values. Add records of enforcement decisions on model and tool-call traffic, showing which interactions were allowed, redacted or blocked and under which policy. Periodic sampling of the persistence backend, with results retained, closes the loop by checking the stored outcome against the policy.

Evidence generated at the moment of enforcement is stronger than evidence reconstructed later, because it records what the policy did rather than what teams believe it did. Enforcement at runtime, rather than review after the fact, is what makes that possible. Retention of the evidence should be set deliberately, since it is itself a record to be governed.