Using a Copilot Studio agent kill switch to support NYDFS cybersecurity incident notification readiness

What a kill switch means for a Copilot Studio agent

Copilot Studio agents can call tools, use connectors and reach data sources. Stopping one therefore involves more than turning off a chat interface. A useful definition has three parts: the agent can no longer take new actions, the credentials and connections it relied on can no longer be used, and the record of what it was permitted to do and did before and after containment is preserved.

The platform actions available to you, such as disabling or unpublishing an agent, revoking connections, and changing environment policies, operate at different layers and at different speeds. Treat each as one lever in a containment design. Which lever you pull depends on what you know at the time: whether the agent is misbehaving, whether its credentials may be compromised, or whether a shared connection is involved.

A kill switch that has never been exercised is an assumption. NIST workshop input on AI agent incidents recommends tested kill-switch interfaces and a measurable time to revoke agent credentials and permissions. That input is non-binding and gives no numeric target, so each organization needs to set and measure its own.

Where the 72-hour clock starts

Under 23 NYCRR 500.17, the covered entity must notify the superintendent electronically, in the form on the DFS website, as promptly as possible and no later than 72 hours after determining that a cybersecurity incident has occurred. The clock runs from that determination, not from when the incident began, and not from when containment finished. The duty applies to incidents at the covered entity, its affiliates, or a third-party service provider.

Three practical consequences follow. First, the playbook must name who makes the determination and how the time is recorded, because that timestamp anchors the deadline. Second, triage scope has to include affiliates and third-party providers that operate or supply agents, connectors or tools. Third, the DFS Portal submission path should be prepared in advance using DFS's printable instructions, so the notice is not assembled for the first time under pressure.

Whether a given agent event is a notifiable cybersecurity incident depends on the regulation's definitions and on your counsel's judgment. The kill switch does not make that decision. It limits further harm and supplies the records on which the decision can be made. DFS also issued guidance on AI-related cybersecurity risk on October 16, 2024, and the full text should be read alongside Part 500 when you design controls.

Evidence needed to support a notification decision

Part 500 text supplied here does not prescribe a list of records for a notification decision, so the evidence set should be defined from your own risk assessment and from established incident-handling guidance. NIST's incident-handling guide says a detailed log should be kept for all evidence. NIST material on AI agent incidents recommends tamper-resistant logs with reliable timestamps sufficient to reconstruct agent tool calls, user interactions and security-control decisions, plus the configuration details needed to reproduce the incident.

In practice, specify these artifacts: the agent's configuration and published version; the identities and keys used; the data stores accessed; each tool call with its parameters and outcome; the policy or authorization decision attached to each call; any human approvals; and provenance for the evidence itself, meaning who or what collected it and when.

The gap to examine is between what the platform records about the agent and what you need to show about decisions. Native audit records may describe activity without showing what the agent was permitted to do at each call, or what a control decided. Evidence generated in the execution path, at the time each call occurs, closes that gap more reliably than reconstruction afterward. Test whether your current records can answer: which tool calls were made, under which identity, with which decision, before and after containment.

Where runtime policy enforcement complements native controls

Native controls are suited to coarse, administrative containment: stop the agent, remove a connection, restrict an environment. They are blunt when the problem is a single capability, such as one tool writing to one system, and they act after someone has decided to act.

Runtime policy enforcement for AI agents works at a different point. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying decisions to individual interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. Policy is enforced at runtime, not reviewed after the fact. This lets a regulated enterprise stop one risky action, or route it to a person, without disabling the whole agent.

The same enforcement produces audit-ready evidence of each decision, mapped to NYDFS and NIST, and can be deployed self-managed in the customer cloud with configurable retention and data residency. Trussed does not replace platform-level disabling, connection revocation or identity controls. It adds a per-call decision layer and a durable record of what the agent was allowed to do and did. Whether that layer is warranted depends on how consequential your agents' tool calls are and how much granularity your containment design requires.