Making OpenAI Agents SDK Deployments Ready for NYDFS Part 500 Asset Inventory Requirements

What 500.13 asks for, and what an examiner will test

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. The policies must include a method to track key information for each asset, and the frequency required to update and validate the inventory. The cybersecurity program itself must cover asset inventory, device management and end of life management, as well as vendor and third-party service provider management.

DFS's AI guidance adds no new requirements beyond Part 500. It does say that covered entities with AI assets should consider implementing the asset inventory requirements immediately, at least for those assets. In practice, you should apply 500.13 and 500.11 to AI assets rather than build a separate AI regime. The annual compliance filing is due April 15 and is either a certification of material compliance or an acknowledgment of noncompliance with a remediation timeline, so inventory gaps affect what your entity can certify. Confirm early whether a limited exemption under 500.19(a) applies to you.

Three questions follow from the text. Which Agents SDK components does your written policy define as information systems? What attributes do you track for each? How do you show the inventory was updated and validated at the frequency you set? Because the regulation says "complete" and "accurate", an examiner can reasonably ask how you know nothing is running that is missing from the inventory. Before you finalize your fields, read the full 500.13(a)(1) list in the current consolidated regulation.

Mapping Agents SDK constructs to inventory records

Whether a given SDK component is an inventory asset is an interpretive decision, and your policy should record it along with the reasoning. A workable default is to treat each construct below as its own record, linked to the agent that uses it. The attribute sets are engineering recommendations. Check them against the regulation's required list.

• Agent definitions: Name, owning team, business purpose, instructions version, repository and deployment location, environment, data classification of what the agent can reach, and the date of last review.
• Function tools and hosted tools: Tool name, function or provider, the systems and data it can touch, read or write capability, authentication method, and which agents may call it.
• Handoffs: Source and target agents, the conditions that permit a handoff, and any change in data access or permissions between them.
• MCP server connections: Server endpoint, operator (internal or third party), tools exposed, credentials used, transport, and approval status.
• Model endpoints: Provider, model identifier and version, hosting location, the agents using it, and the date it was last assessed.
• Check and tracing configuration: Input and output checks configured in the SDK, whether tracing is enabled, where trace data is sent, and who owns the configuration.

Where declaration-based inventories fall short

Agent components are defined in code and configuration and change often. A developer can add a tool, point an agent at a new MCP server, or change a model identifier in a routine pull request that never reaches an inventory owner. A spreadsheet or registry populated by hand then describes what was approved at one point in time, not what runs.

The usual response is to generate the declared inventory from the repository and deployment configuration. That helps, and you should do it. It still reflects intent. It will not show a tool resolved at runtime, a server configured through an environment variable, or an agent deployed from a branch the scanner never covers.

The approach we recommend is to keep two inventories. The declared inventory comes from code and configuration. The observed inventory comes from runtime records of which agents, tools, MCP servers and models were actually invoked. Reconcile them on the validation frequency your policy sets. An observed component with no declared record is an unregistered asset. A declared component that never appears at runtime may be dormant or retired, and it still needs a decision. This is an engineering control, not something the regulation prescribes, but it gives you a direct answer when asked how you know the inventory is accurate.

Runtime enforcement as inventory evidence

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Each decision (allow, redact, block, rate limit, or escalate for human approval) applies to an individual interaction or tool call and produces audit-ready evidence mapped to NYDFS. Because enforcement is applied at runtime and not reviewed after the fact, those records show which components were used and what policy decided in each case.

For inventory work, that evidence serves three purposes. It feeds the observed inventory, so an agent calling a tool or MCP server absent from the declared inventory is visible. A policy that permits only registered tools and servers can block calls to anything else, so an unregistered component is stopped, not just noted for later review. And for sensitive tool calls, escalation for human approval creates a record of who authorized the action.

The limits matter. Runtime records cover only what ran. They cannot reveal components that were deployed but never invoked, so they complement the declared inventory and do not replace it. They also do not provide model or dataset lineage, and they do not trace agentic workflows end to end. Their scope is the individual interaction and tool call. For an examiner, framing the evidence this way is more credible than presenting it as a complete inventory source.