Implementation Guide | Financial Services

    NYDFS Part 500 72-Hour Notification: How to Contain a Compromised OpenAI Agents SDK Agent

    As of November 2026, 23 NYCRR 500.17 requires a covered entity to notify the superintendent electronically as promptly as possible, and no later than 72 hours after determining that a cybersecurity incident has occurred. For a compromised agent, begin containment before that determination: revoke or restrict the tools and credentials the agent holds, keep a record of what it was permitted to do and what it did, and document who made the determination and when. This guide is not legal advice.

    Evidence to hold for scoping and examiner questions

    • The agent's configuration at the time: tools enabled, handoff targets, and checks applied to inputs and outputs.
    • The credentials and permission scopes delegated to the agent, and who issued them.
    • Each tool call in the affected window: parameters, target system, result, and the time.
    • The policy decision applied to each call, such as allowed, redacted, blocked or escalated, and any human approver.
    • The inputs that preceded suspect behavior, including retrieved content and tool metadata.
    • The containment actions taken, with timestamps, and the record of the incident determination.

    What the 72 hours measure

    Section 500.17 of 23 NYCRR Part 500 requires a covered entity to notify the superintendent electronically, in the form on the Department's website, as promptly as possible and in no event later than 72 hours after determining that a cybersecurity incident has occurred. The duty applies to incidents at the covered entity, at its affiliates, or at a third-party service provider. Earlier versions of the rule used the phrase "cybersecurity event". Current text uses "cybersecurity incident", and incident plans should use that term.

    The clock runs from the determination, not from first detection. That makes the determination a control point in its own right. Your agent runbook should name who is authorized to make it, what information they need, and where the time and rationale are recorded.

    The Department's submissions guidance describes criteria for a notifiable incident, including a reasonable likelihood of materially harming any material part of the normal operations of the covered entity, and ransomware deployment within a material part of the covered entity's information systems. A hijacked tool call or misused delegated credential has to be tested against those criteria like any other event. Counsel should make the final interpretation.

    The Department's October 2024 industry letter on AI-related cybersecurity risks states that it imposes no new requirements beyond Part 500. Agent controls are therefore best presented to an examiner as applications of existing duties, not as a separate AI rulebook.

    An agent-specific incident timeline

    Conventional runbooks assume the compromised asset is a host, an account or an application. An agent is all three at once: it reasons over untrusted input, holds credentials and calls tools that act on systems. The sequence below keeps the familiar order but changes what each step involves.

    • Detect: Treat an unexpected tool call, an unusual use of delegated credentials, or output that follows instructions found in retrieved content as a trigger. Start the incident record and the evidence hold.
    • Contain: Remove or restrict the agent's tools, revoke or rotate the credentials it held, and cut handoff paths to other agents. Do this without waiting for a determination.
    • Scope: Establish which tools the agent could call, which it did call, with what parameters, on which systems, and whether other agents or third parties were reachable.
    • Determine: Test the facts against the notifiability criteria and the affiliate and third-party provisions. Record the time and the decision-maker.
    • Notify: Submit through the Department's electronic form within 72 hours of the determination, and be ready to provide promptly any information the superintendent requests.
    • Preserve: Keep the permission record and the action record for the agent, in a form you can produce to an examiner.

    Containing an agent that can act

    The OpenAI Agents SDK organizes an application around agents, tools, handoffs, guardrails, sessions and tracing. For containment, each of these is a surface to consider: what the agent can invoke, whom it can pass work to, what checks run on its inputs and outputs, and what state and records exist afterward.

    OWASP describes the underlying risk as Excessive Agency: damaging actions taken in response to unexpected, ambiguous or manipulated model output, regardless of the cause. Causes include direct or indirect prompt injection, an earlier invocation of a malicious or compromised extension, and, in multi-agent systems, a malicious or compromised peer agent. OWASP's example is a crafted incoming email that leads an agent to scan an inbox and forward sensitive information to an attacker. Related OWASP agentic guidance adds hidden prompts in tool metadata, file exfiltration through legitimate tool parameters, and extraction of stored credentials.

    Those patterns point to three containment actions. First, remove tool functions the agent does not need for its intended operation. Second, limit the permissions the agent can exercise, narrowing scopes instead of disabling everything. Third, rotate or revoke the credentials it held, including any delegated to downstream systems. Because handoffs are a documented route for a compromised peer agent to propagate an attack, restrict them as part of the same step.

    The design question is who holds each lever. A lever that lives only in the agent's own code or prompt depends on the model behaving correctly, which is the assumption a prompt injection breaks. Security teams should be able to disable a specific tool call or revoke specific credentials without taking down every agent, and without a code release.

    Where runtime policy enforcement fits

    The OWASP Agent Control Standard argues that agents must be inspectable, traceable and instrumentable, with safety policies enforced as declarative controls at runtime. This is a standard, not a statement about any SDK, but it frames the architectural point. A control that sits in the execution path, outside the model's reasoning, still applies when the model has been manipulated. A review performed after the fact can explain what happened, but it cannot stop the next tool call.

    Trussed is one example of this layer. It enforces policy in the execution path across agent tool calls, with outcomes of allow, redact, block, rate limit or escalate for human approval, applied to individual interactions and tool calls. During containment, that gives a security team a way to tighten policy on a specific tool or action while other agents continue to run. Afterward, enforcement generates audit-ready evidence, mapped to NYDFS among other frameworks, showing what the agent was permitted to do and what happened to each call. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. Its scope is individual interactions and tool calls, and it does not provide end-to-end tracing of agentic workflows, so reconstructing a full multi-agent sequence still depends on your other records.

    Trussed's depth is in insurance, a regulated financial sector, and in regulated enterprises generally. The value for a NYDFS examiner conversation is evidence: a durable record of permissions and decisions, produced by enforcement instead of assembled under deadline.

    Decisions to settle before an incident

    Four decisions are cheaper to make in advance. Define who determines that a cybersecurity incident has occurred, and require that the time and basis be written down. Decide which containment levers the security team can pull independently of the agent's owners. Extend the plan to agents run by affiliates or third-party service providers, since the notice duty covers incidents there and your contracts need to support your ability to determine and notify. Finally, include third-party agent frameworks and model services in the procedures Part 500 requires for evaluating externally developed applications, subject to counsel's reading.

    Test the plan with a tabletop built around an indirect prompt injection that causes a legitimate tool to be misused. If the team cannot say within the exercise which tools the agent could call and which it did, the evidence gap is the first thing to fix.

    The 72-hour clock for an agent incident

    Detect and contain

    Restrict tools and credentials without waiting for a formal determination.

    Scope

    Establish what the agent could do and what it did.

    Determine

    Record when, and by whom, the incident was determined to have occurred.

    Notify and preserve

    File electronically within 72 hours and keep evidence for follow-up requests.

    Test your agent containment against the 72-hour clock

    See how policy enforced in the execution path restricts agent tool calls and produces audit-ready evidence mapped to NYDFS.

    See How Evidence Is Produced
    Next step

    How does your AI governance program compare?

    See where your program has gaps in less than 2 minutes.