NYDFS Part 500 Asset Inventory for n8n Workflows, Credentials, and AI Models

What 500.13 asks of the inventory

Section 500.13(a) requires each covered entity, as part of its cybersecurity program, to implement written policies and procedures designed to produce and maintain a complete, accurate and documented asset inventory of its information systems. Three elements matter for an examination. The inventory must be maintained under written policies. Those policies must set out a method to track key information for each asset, as applicable. And they must set the frequency required to update and validate the inventory.

The current policy topic list also names asset inventory, device management and end of life management, alongside vendor and third-party service provider management. Earlier versions of the regulation listed only asset inventory and device management.

NYDFS risk assessment guidance treats the inventory as the foundational input to the Risk Assessment. It names outdated or incomplete inventories, and failure to identify where NPI resides or flows, as common weaknesses. For a CISO, the practical reading is that the inventory is a governed artifact an examiner will test for currency and for its ability to answer where NPI is and who can reach it. Which obligations apply to your organization also depends on exemptions and Class A company status under the regulation.

Three asset classes, three sets of attributes

Part 500 does not classify workflows, credentials or AI models as separate asset types. Treating them separately is an interpretation of "information systems" and of the guidance that software, processes and data such as NPI are in scope. It is a useful interpretation because each class answers a different examiner question, and a single row per workflow hides most of them.

Traditional CMDB and asset discovery tools often miss these assets because they are created inside a low-code platform rather than deployed as hosts or applications. The inventory therefore needs a deliberate enumeration step against the automation platform itself, reconciled with the CMDB.

• Workflows: Name, business purpose, accountable owner, environment, trigger type including webhooks, community nodes in use, NPI classes read or written, external APIs and models called, and recovery priority.
• Credentials: Credential name and type, the system or provider it unlocks, accountable owner, workflows that use it, scope of access, rotation and review dates, and the classification of the data it can reach.
• AI models and tools: Model and provider, hosting location, the workflows that invoke it, tools and tool calls it may make, data classes it may receive, third-party service provider status, and approving owner.

Fields and ownership an examiner is likely to expect

Section 500.13(a)(1) requires a method to track key information for each asset. Your written policy should name the fields and apply them consistently. Ownership, location, classification and recovery priority are the attributes most examiners will look for, and they are the ones that make an inventory usable for risk assessment.

Ownership needs two levels. A named business owner is accountable for what the workflow does with NPI. A technical owner is accountable for configuration, credentials and change. Shared service accounts and departed employees are the usual gaps. Location should cover where the platform runs, where execution data is stored, and where any external model or API processes data. Classification should be inherited from the most sensitive data the asset can reach, not the data it usually handles.

For workflows, record NPI flow explicitly: what enters, where it goes, and which third parties receive it. That answers the guidance questions on where NPI resides, how it flows, and who has access. For hosted models and external APIs, tie the inventory entry to third-party service provider risk assessment, and to the dependency maps NYDFS has said regulated entities should develop and maintain with critical providers and material downstream providers.

Keeping the inventory current

Section 500.13(a)(2) requires the policy to set a frequency for updating and validating the inventory. A one-time export from the automation platform does not meet that requirement unless the cadence is documented and followed. Workflows are edited continuously, credentials are added by individual builders, and new model integrations can appear between reviews, so the interval and the triggers matter.

Decide three things in the policy. First, the scheduled validation interval, and who signs off on each cycle. Second, the out-of-cycle triggers, such as a new workflow touching NPI, a new credential, a new community node, a change of model provider, or a change in the tool calls a workflow may make. Third, the reconciliation method between the platform's own records and the CMDB, with exceptions tracked to closure.

The tradeoff is effort against accuracy. Frequent automated enumeration keeps records current but produces volume that owners must review. A tiered approach works well in practice: continuous enumeration for existence and change, with owner attestation more often for workflows that touch NPI than for low-risk internal automations. Document the tiers so the cadence can be defended.

What a static inventory cannot establish

An inventory can establish existence, ownership, classification and intended data access. It cannot establish what an AI model or a tool call actually did on a given execution. A workflow record may state that it may call a model and a ticketing API. It does not show which prompts carried NPI, which tool calls were attempted, or which were refused. For model risk management and examiner scrutiny, that gap matters, because the AI-specific guidance from NYDFS asks entities with AI assets to apply inventory requirements now, and the inventory itself becomes the baseline against which behavior is judged.

Runtime policy enforcement addresses the other half of the question. Trussed enforces policy in the execution path on individual interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. Enforcement is applied at runtime, not reviewed after the fact, and it generates audit-ready evidence mapped to NYDFS. That evidence shows what an AI-enabled workflow was permitted to do and what it did at the level of each interaction and tool call.

The two controls remain separate. Enforcement evidence does not replace the written inventory policy, the ownership records or the validation cycle, and it does not provide end-to-end tracing of a whole workflow. Used together, the inventory defines what should exist and who answers for it, and runtime evidence shows how the AI components behaved within those boundaries.