How to prove to NYDFS examiners that a CrewAI agent never received customer NPI

Treat the examiner's question as an evidence-design problem

As of November 2026, 23 NYCRR Part 500 requires each covered entity to maintain a cybersecurity program, based on its risk assessment, that protects the confidentiality, integrity and availability of its information systems and the nonpublic information (NPI) stored on them. NYDFS guidance on AI adds that robust access controls help prevent unauthorized access to NPI, and that effective data management limits the NPI at risk of exposure. Neither prescribes a specific control for AI agents, so the design work falls to you.

It helps to separate three things. An assertion is a statement of intent, such as a policy or a system prompt telling an agent not to use customer data. Prevention is a control that acts on the data before the agent receives it. Proof is a record, independent of the agent, that lets a third party confirm the control operated. Assertions and prompt instructions rely on the agent behaving as asked. Post-hoc logs show what happened but do not show that NPI was stopped before it arrived. A claim of non-receipt needs prevention and proof together.

Confirm first that your entity is covered, since exemptions and entity-specific applicability exist under Section 500.19. Then trace the NPI boundary for AI agents back to your documented risk assessment, so the control is justified by the program rather than added beside it.

What evidence would substantiate a claim of non-receipt

A negative assertion is hard to prove directly, because you cannot enumerate everything that did not happen. The practical approach is to show that a control sat in front of every entry point, that it was configured as approved, and that it recorded its decisions in a form the agent cannot alter. Non-receipt then rests on the combined weight of those records, not on one document.

For each interaction, an examiner-ready record should let a reviewer see which policy applied, what decision was made, and when. The record should not itself reproduce the NPI it protected. Five properties matter in practice:

• Decision records: for each model call and tool call, the allow, redact or block outcome, with timestamp, agent and tool identity.
• Redaction records: which categories of NPI were detected and replaced, without storing the original values.
• Policy versions: the exact policy in force at the time of each decision, with approval history that ties back to your risk assessment.
• Coverage evidence: a current inventory showing every agent, tool and data source that sits behind enforcement.
• Integrity and retention: write-once or tamper-evident storage, a defined retention period, and access controls over who can change records.
• Independent verifiability: an export an examiner can check without relying on the agent or its operators.

An implementation pattern that enforces policy at each entry point

The pattern is to move enforcement out of the agent and into the execution path, so the decision happens before data reaches the model or tool and does not depend on the agent's behavior. Tool calls are enforced in both directions, since tool inputs can leak NPI outward and tool outputs can bring it in. Model calls are enforced on the assembled prompt, which catches NPI arriving through retrieval, memory or delegation even when earlier steps missed it.

Redaction before the model is usually preferable to blocking where the task can proceed without the NPI. Blocking suits cases where the data is the point of the request, and escalation for human approval suits exceptions. Whichever applies, the decision is recorded at the moment it is made.

• Inventory the NPI sources, applications and authorized roles for each CrewAI workflow.
• Define the NPI boundary: which fields and data types may never reach an agent, a model or a tool.
• Place enforcement on model calls and on tool calls, inbound and outbound.
• Set a policy per entry point: allow, redact or block, with escalation for approved exceptions.
• Write each decision to protected storage with the policy version and a retention period.
• Review sampled records on a schedule, and test detection against known NPI patterns.

The limits of this evidence, and what to disclose

Enforcement records prove that a control operated and what it decided. They do not prove that no NPI ever slipped through. Detection is the weak point. Pattern matching works well for structured identifiers such as account or Social Security numbers, but it can miss NPI in unstructured text, in unusual formats, or in encoded or obfuscated content. Classifier-based detection can reduce some misses but introduces its own false negatives and false positives. State the detection methods you use, test them against your own data, and report known gaps to examiners before they find them.

Scope matters too. Enforcement at the level of individual interactions and tool calls does not trace a business transaction across tasks and agents, and it does not reconstruct an end-to-end workflow. If an examiner asks for that, you will need other evidence. Finally, MFA applies to all Authorized Users accessing information systems or NPI as of November 2025, so confirm that agent service access to NPI systems is covered by your access control design.

If NPI does reach an agent improperly, your incident response must be able to meet the 72-hour window for notifying NYDFS of a cybersecurity incident. Decision records also help you establish quickly what was exposed and where.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate-for-approval outcomes. Enforcement is at runtime, not reviewed after the fact, and the enforcement itself generates audit-ready evidence mapped to NYDFS expectations. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, which lets a regulated enterprise keep evidence under its own control.

The scope is individual interactions and tool calls. Trussed does not provide end-to-end tracing of agentic workflows or transaction-level governance across tasks and agents, so those questions need separate evidence. The design method in this guide applies whichever tooling you choose.