Redacting Customer NPI from LangGraph State Before Tool Calls Under Regulation S-P

Why the tool-call boundary matters under Regulation S-P

As of November 2026, 17 CFR 248.30 requires covered institutions to maintain written policies and procedures addressing administrative, technical and physical safeguards for customer information. Those policies must include a program reasonably designed to detect, respond to and recover from unauthorized access to or use of customer information, including customer notification procedures. The response program must also include written oversight of service providers, covering due diligence and monitoring. Where a service provider has a breach in security that results in unauthorized access to a customer information system it maintains, it must notify the covered institution as soon as possible, and no later than 72 hours after becoming aware of it.

A tool call that sends customer data to an MCP server or external API is a disclosure to another system, and often to a service provider. That is where safeguarding and oversight obligations become concrete for an agent. Regulation S-P Subpart A, other than § 248.30(b), applies to nonpublic personal information (NPI) about individuals who obtain financial products or services primarily for personal, family or household purposes. For a working inventory, FTC guidance under the GLBA Privacy Rule describes NPI as personally identifiable financial information collected in connection with providing a financial product or service, with examples such as account numbers, payment history, loan or deposit balances and card purchases. Confirm your institution's own definitions of customer information and sensitive customer information with counsel. This page is not legal advice.

Map where NPI enters and persists in graph state

A LangGraph agent carries a shared state object defined by a schema. Each node returns updates, and reducers decide how those updates merge into existing values. Any field that accumulates, such as a message list or a retrieved-documents list, keeps NPI available to every later node. A tool node then builds its arguments from that state, so a field that was harmless to an early step can be sent outward several steps later.

Start the inventory with three entry points: user input, tool outputs and retrieved records. A customer typing an account number into a chat, a CRM lookup returning balances, and a retrieval step pulling a statement all write NPI into state. Then list every tool, MCP server and API that can receive state fields, and classify each as internal, service provider or third party.

Persistence is a separate question from transmission. If a checkpointer stores state between steps, whatever is in state at that moment may be written to the checkpoint store. Decide whether redaction applies only to the outbound payload or also to persisted state, and confirm the actual behavior of your checkpointer and version against LangGraph documentation before relying on it. A redacted payload does not help if raw values sit in a store that more people can read than the tool can.

Decide the action for each field at each boundary

The decision depends on the field and on the destination. A balance may be acceptable for an internal ledger service and unacceptable for a third-party summarization API. Express the decision as policy keyed to tool and field, not as code scattered across nodes.

No single detection method is sufficient. Redaction is a suppression technique, and NIST notes that it alone does not provide formal privacy guarantees. Pair pattern and entity detection, which catches free text, with field-level schema filtering, which removes known NPI fields by name before detection runs.

• Allow: The destination is approved for that field under your service provider oversight policy, and the need is documented.
• Redact: Remove or mask the value when the tool does not need it to do its job.
• Tokenize: Replace the value with a token when the tool needs a stable reference. Treat the reversible mapping as sensitive, since reversible substitution is not equivalent to encryption, and restrict access to it.
• Block: Stop the call when NPI appears in a destination that should never receive it, or when detection confidence is too low to proceed.
• Test with seeded data: Run synthetic NPI through every tool path, including nodes that skip shared middleware, and confirm nothing leaves unmodified.

In-node or middleware redaction compared with enforcement in the execution path

Application-level redaction is faster to start and sits close to the data. Its weakness is coverage. Every new node, tool or developer is another place the step can be omitted, and each implementation can behave differently. Enforcing policy in the execution path applies one rule set to every outbound call regardless of which node built it, and it can produce a uniform record. The trade-off is that it adds a component to operate and requires tool-level policy to be defined up front.

• Consistency: In-node: varies by author and node. Execution path: one policy applied to every call.
• Bypass risk: In-node: a new or modified node can skip the step. Execution path: calls cannot reach the tool without passing enforcement.
• Destination awareness: In-node: tool rules are hard-coded in graph logic. Execution path: policy varies by tool, MCP server or API.
• Evidence: In-node: depends on each node writing its own records. Execution path: one record format per call.
• Change management: In-node: policy changes need code releases. Execution path: policy changes are made once, centrally.
• Operational cost: In-node: minimal infrastructure. Execution path: an additional component in the call path.

Where Trussed fits

Trussed enforces policy in the execution path on individual tool calls, including calls to tools, MCP servers and external APIs. For each call it can allow, redact or block, enforced at runtime, not reviewed after the fact. Because enforcement sits outside agent code, a node cannot omit it, and each decision generates audit-ready evidence of the policy applied and the action taken. Trussed can be self-managed in the customer cloud, with configurable retention and data residency, which bears on where evidence about NPI handling is stored.

The scope is the individual call. Trussed does not trace whole agentic workflows. Persisted checkpoints, upstream retrieval permissions and your service provider due diligence remain separate controls that you design and own. Used together with field-level schema design and tight access to state stores, runtime enforcement gives security teams one place to define what each destination may receive and one record of what happened.