NYDFS Part 500 Audit Trail Requirements for Copilot Studio Agent Tool Calls

What Part 500 explicitly requires

Part 500 is the DFS Cybersecurity Regulation, in force as of November 2026 and amended by the Second Amendment authorized on October 16, 2023. The provision most directly on point is 500.6(a). It requires each covered entity to securely maintain systems that, to the extent applicable and based on its risk assessment, include audit trails designed to detect and respond to cybersecurity events that have a reasonable likelihood of materially harming any material part of the entity's normal operations.

Two qualifiers matter. The duty applies "to the extent applicable" and "based on its risk assessment." DFS describes Part 500 as risk-based and principles-based, and says it does not mandate unreasonable technical controls. The regulation therefore does not hand you a field-level logging specification. It asks you to justify the depth of your audit trail against your own risk assessment, and to document that rationale.

Access privileges and monitoring sit alongside the audit trail. DFS's AI guidance describes the access privilege obligation: periodically, and at minimum annually, review access so each Authorized User has access only to the nonpublic information needed for their job functions, remove access that is no longer necessary, and terminate access promptly after departures. Part 500's monitoring provisions point toward centralized logging and security event alerting. Entities with limited exemptions under 500.19(a) should confirm which sections apply to them using DFS's requirement checklist.

How the AI guidance applies to agents, and where interpretation begins

DFS's guidance on cybersecurity risks arising from AI states that it imposes no new requirements. It explains how covered entities should use the existing Part 500 framework to assess and address AI risk. It also includes a section on third-party service provider and vendor management, which is relevant because an agent platform and any enforcement layer are third-party services.

Nothing in Part 500 or the guidance mentions agent tool calls. Everything below about tool-call records is interpretation, not regulatory text. The reasoning is straightforward. If the purpose of the audit trail is to detect and respond to material events, the trail has to support reconstruction of what an agent did. An agent that reads a customer record through a connector, or writes to an external system, is taking an action that an authorized user might otherwise take. The same access privilege logic applies, so the record should show under which identity the call ran.

This separation is useful in an examination. State plainly what Part 500 requires, state what you have inferred for agents, and show that the inference follows from your risk assessment.

Where platform-native telemetry leaves evidence gaps

Platform-native activity records generally establish that an action occurred. They are valuable for investigation, but they often do not show what policy permitted or blocked a call, under what identity and context it ran, or whether the evidence is complete, durable and retained for the required period. Those are the questions a Part 500 examination tends to turn on.

For Copilot Studio, test each of the following against the telemetry your tenant actually produces, rather than assuming coverage. Does every tool and connector call appear, including calls that were refused? Are parameters captured in a usable form? Is the policy decision recorded, or only the action? Can the retention period be set to match your obligation, and held independently of the platform? Can you demonstrate that no events were dropped?

If the answer to any of these is no, the gap is evidentiary rather than operational. The agent may behave correctly, yet you cannot prove it. Closing the gap requires a record created at the point of decision, stored where you control it, and exported to your centralized logging and alerting.

Runtime policy enforcement as a source of audit evidence

A record of the policy decision can only be written by something that makes the decision. That points to enforcement in the execution path, where each tool call is evaluated before it proceeds. Policy is enforced at runtime, not reviewed after the fact, and the decision and its context become the evidence.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions that include allow, redact, block, rate limit and escalate for human approval. Its scope is individual interactions and tool calls. It does not provide end-to-end tracing of agentic workflows or transaction-level governance, and this guide does not assume either. Enforcement generates continuous audit-ready evidence mapped to NYDFS, among other frameworks. It can be deployed self-managed in the customer's cloud, with configurable retention and data residency.

On operating experience, Trussed has run continuously in production in a regulated enterprise for more than 18 months and generates more than 30 GB of audit evidence per day. Its deepest experience is in insurance, a regulated financial sector. The value for a CISO is narrow and specific: when an examiner asks what an agent was allowed to do and what it did, the answer comes from records produced at the moment of each call.