Redacting NPI from n8n AI Agent Prompts Before LLM Calls Under NYDFS and Reg S-P

Where NPI enters an n8n AI agent prompt

An agent prompt is rarely one string written by one author. It is assembled from several components, and each one can carry nonpublic personal information (NPI) such as account numbers, Social Security numbers and customer financial details. NIST describes prompt injection as exploiting the concatenation of untrusted user input with the system prompt. The practical lesson is to treat every concatenated component as untrusted input, including components your own systems produced.

For an inventory, walk each workflow that calls an external model and list the data sources feeding the prompt. The following entry points are the usual starting set.

The inventory matters because redaction that covers only the obvious entry point leaves the others open. A workflow that sanitizes the chat trigger but passes a CRM record straight into a tool node has a gap that no review of the trigger will reveal.

• Trigger payloads: Form fields, chat messages, webhook bodies and uploaded documents supplied by users or upstream systems.
• Memory: Prior conversation turns that can carry NPI from earlier sessions into later calls.
• Retrieved context: Documents, CRM records and database rows added to the prompt for grounding.
• Tool results: Output from API calls and lookups that the agent feeds back into the next model call.
• System prompts and templates: Instructions or examples that embed real customer data, often by accident.

What NYDFS and Reg S-P require, and where each applies

As of November 2026, 23 NYCRR Part 500 is in force as amended by the Second Amendment, effective November 1, 2023. Section 500.0(a) requires each covered entity to maintain a cybersecurity program designed to protect the confidentiality, integrity and availability of its information systems and the nonpublic information stored on them. DFS has also issued an industry letter on AI risk. It creates no new requirements beyond Part 500, but it says covered entities should consider monitoring for unusual query behavior that might indicate an attempt to extract NPI, and blocking queries from personnel that might expose NPI to a public AI product or system. That language supports designing for block outcomes, not redaction alone.

Access privileges are the second Part 500 theme. A DFS consent order states that the regulation requires covered entities to limit user access privileges to systems that provide access to NPI. The same order describes a tool whose source code held complete unredacted consumer information that was hidden in the interface but viewable in a browser. The analogy for n8n is direct: masking NPI in a node's display does not remove it from the data actually transmitted to a model provider.

Under Regulation S-P, 17 CFR 248.30 requires covered institutions (brokers or dealers, investment companies, registered investment advisers and transfer agents) to maintain written policies and procedures with administrative, technical and physical safeguards for customer information. Those policies must include a program to detect, respond to and recover from unauthorized access to or use of customer information. Notice to affected individuals is required as soon as practicable, and no later than 30 days after the institution becomes aware that unauthorized access or use has occurred or is reasonably likely to have occurred. Whether a given prompt leak meets that threshold is a decision for counsel, but your triage process should be built around the 30-day clock.

Designing detection and redaction before the model call

Run detection on the final assembled prompt, not on individual inputs. That is the only point where every component has been combined and where nothing downstream can add data. Inspecting inputs separately misses NPI introduced by memory, retrieval and tool results.

The common detection techniques have different strengths, and most designs combine them. Pattern matching is predictable and easy to explain, and it suits structured identifiers such as SSNs and account numbers, but it misses unstructured references. Entity recognition handles names and free-text details, at the cost of probabilistic misses and false positives. Tokenization replaces a value with a reversible placeholder so the model can reason about the field without seeing the data, which requires protecting the token map as sensitive. Interception at the HTTP layer catches requests regardless of which node produced them. Measure misses and false positives against seeded test data for your own NPI types rather than assuming coverage.

Write the action for each detection in policy. A reasonable starting model is allow for no detection, redact for identifiers the task does not need, and block where redaction would leave the prompt unsafe or the destination is not approved. Redaction should also be one control among several. Limit the data an agent can retrieve and the tools it can call, and scope its service credentials to the minimum, because NIST notes that in agentic systems harm can arise from sequences of actions that each look benign, which limits any single-prompt check.

• Inventory every workflow that calls an external model and mark each NPI entry point.
• Place detection on the assembled prompt, before the request leaves the environment.
• Define allow, redact or block per detection type in written policy.
• Restrict agent retrieval, tools and credentials to what the task needs.
• Seed test NPI at every entry point and re-test when workflows change.

Enforcing policy in the execution path

The design above works best when enforcement sits where every model call must pass. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact and block outcomes applied to individual interactions and tool calls. Enforcement happens at runtime, not through review after the fact. It also generates audit-ready evidence mapped to NYDFS, which gives a regulated enterprise a consistent per-call record without relying on each workflow author to build one. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

The approach does not replace the broader work: the inventory, written policy, access limits on agent credentials and tools, incident triage and counsel's judgment on reportability all remain with your team.