How to Build an AI Agent Customer Data Inventory That Satisfies NYDFS Part 500 and Reg S-P

What the inventory has to cover

As of November 2026, 23 NYCRR Part 500 is in force as amended. Section 500.13 requires written policies and procedures designed to produce and maintain a complete, accurate and documented asset inventory of information systems. Those policies must set how often the inventory is updated and validated. Amended Regulation S-P defines customer information as any record containing nonpublic personal information about a customer, including records handled or maintained on the institution's behalf, and requires an incident response program built to detect, respond to and recover from unauthorized access to or use of that information.

Agents strain both texts because they are not static applications. An agent reads customer records, sends them to a model, calls tools, and may pass results to other systems, all within one interaction. A conventional asset inventory or CMDB can list the application, the database and the vendor. It usually cannot show which agent touched which data class, through which model and tool, under which policy.

The regulatory text does not say whether an agent, an MCP server or a model endpoint is itself an inventoried information system. Treating each as one is a reasonable interpretation, and it should be confirmed with counsel. The NYDFS October 2024 industry letter on AI-related cybersecurity risk adds no new requirements. It does say data inventories help firms assess risk, ensure compliance and know what NPI and systems were exposed after a breach. Frame the inventory as a way to meet existing obligations, not as a new AI mandate.

The record schema: baseline plus agent-specific fields

Begin with the Part 500 baseline. Since November 1, 2025, the inventory must include a method to track, for each information system, its owner, location, classification or sensitivity, support expiration date and recovery time objectives. Carry those fields onto every agent record, then add the fields below. No regulation prescribes these agent fields. They are a practitioner design informed by Part 500, Reg S-P and NIST AI 600-1, which suggests recording underlying foundation models, their versions and access modes, human oversight roles, and upstream data dependencies.

• Identity and ownership: Unique agent identifier, business purpose, a named owner, and the human oversight role responsible for approvals and exceptions.
• Models and versions: Each model the agent can call, its version, access mode and hosting location.
• Tools and MCP servers: Every tool and MCP server the agent may invoke, and the systems behind them. This captures agent-to-system relationships and upstream dependencies.
• NPI data classes: Categories of customer information the agent can read, transform or transmit, tied to the firm's classification scheme.
• Third-party providers: Model providers, tool hosts and MCP hosts that handle NPI on the firm's behalf.
• Permissions and retention: Granted permissions, the policy that applies, and retention for prompts, outputs, logs and caches that hold NPI.

Mapping each element to a requirement

Each field should trace to a stated obligation, so an examiner can see why it exists. The mapping below uses only what the regulatory text and NYDFS guidance state. Fields that support access privilege, third-party oversight and risk assessment work should also be reviewed against the full text of those provisions with counsel.

• Owner, location, classification, support expiration, recovery time objectives: Section 500.13 inventory tracking, required since November 1, 2025, applied per agent and per connected system.
• Agent identity, models, tools, MCP servers: The requirement for a complete, accurate and documented inventory of information systems, assuming agents and their components are treated as systems.
• NPI data classes: Reg S-P customer information scope, and the incident response duty to identify the systems and types of customer information possibly accessed or used without authorization.
• Third-party providers: Reg S-P coverage of customer information handled or maintained on the institution's behalf. This is an inference applied to model and tool hosts.
• Retention: The NYDFS AI letter statement that NPI no longer needed for legitimate business purposes must be disposed of, including NPI used for AI.
• Update and validation frequency: Section 500.13 policies must set the frequency. NYDFS template guidance points to annual review and review on significant change.

Keeping the inventory current: runtime evidence versus attestation

A spreadsheet reviewed annually will drift from agent behavior. A new tool, a model swap or a permission change can alter the access path in a day. The written policy should therefore name update triggers, such as a new tool or MCP server, a model or version change, and a permission change, in addition to the periodic review.

Some fields can be populated and checked from records produced as agents run. These include which models and tools were actually invoked, which NPI data classes appeared in interactions, which permissions were exercised or denied, what policy decision applied, and whether a human approved an escalation. Comparing those records with the declared record exposes undeclared tools, unexpected data classes and unused permissions. That turns validation from a periodic reading exercise into a continuous comparison.

Other fields cannot come from runtime records. Ownership, business purpose, recovery time objectives, support expiration dates and classification decisions are human determinations and still need attestation. Document an exceptions process for them. Mark each field in the schema as runtime-populated or attested, so an examiner can see how every value is sourced and how often it is verified.

Regulation S-P gives the same design a second use. It is triggered by unauthorized access or use, not only by exfiltration, and notice to affected individuals is due as soon as practicable and no later than 30 days after the institution becomes aware of an incident. Per-interaction records of agent, tool and data class let a team scope an incident quickly. The inventory record then shows which systems and customer information types to examine first.

What an inventory cannot do

An inventory documents scope and access paths. It does not prevent unauthorized access or use. Pair it with access controls, multi-factor authentication for authorized users accessing information systems or NPI, and a tested incident response program.

It also cannot find what it was never told about. Agents built outside approved channels will not appear until data discovery or network-level review surfaces them. Vendor due diligence on model providers and tool hosts remains a separate process, and the inventory only records the outcome. Runtime evidence covers only traffic that passes the enforcement point, so coverage gaps need to be tracked as inventory exceptions.

Finally, the link between the inventory and Reg S-P notification depends on the definition of sensitive customer information. Map the data classes in your scheme to that definition with counsel, so a record can show quickly whether an event could trigger notice.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Each interaction can be allowed, redacted, blocked, rate limited or escalated for human approval. Enforcement is at runtime, not reviewed after the fact, and it produces audit-ready evidence mapped to NYDFS and other frameworks. That evidence can populate the runtime-sourced fields described above.

Trussed deploys self-managed in the customer cloud, with configurable retention and data residency, which bears directly on the retention and location fields. Insurance is the regulated financial sector where Trussed is deepest. Trussed does not replace data discovery, vendor due diligence or attestation for the fields that need them.