A seven-step playbook for when an AI agent gets it wrong, mapped to NIST SP 800-61 Rev. 3, the AI RMF and the 36-hour bank notification rule.
Sooner or later an AI employee will make a call that a reviewer would not have made. It might approve a refund above the limit, miss a field on a document, or repeat one bad assumption across four hundred cases before anyone looks. The question for a bank or other regulated firm is what happens in the next hour. This guide gives a seven-step response, maps it to the incident guidance that exists today, and explains the one bank rule with a hard clock, checked against the eCFR in October 2026.
It extends control 10 (incident response) from our 12 controls for governing AI agents. That post says a playbook should exist. This one shows what goes in it.
No, and mixing them up is the most common planning mistake. A wrong decision on a case is a quality or control problem. It goes through your exception and remediation process, and nobody needs to call the regulator. A security incident involves harm to systems or data. The bank notification rule applies to a narrower category still.
Event | Example | How to handle it |
|---|---|---|
Wrong decision on a case | Agent approves a $4,800 refund where policy caps agent approvals at $2,500 | Correct the case, check similar cases, fix the procedure |
Control failure | A gate that should have stopped the refund did not fire | Log as a control deficiency, find the cause, retest the control |
Security incident | A stolen agent credential, data exposed to the wrong party, a document that manipulates the agent's instructions | Run your security incident process; assess scope with the security team |
Notification incident (banks only) | A computer-security incident that materially disrupts or degrades banking operations | Notify the primary federal regulator within 36 hours of determining it occurred |
One event can move down the table. A wrong approval looks like a case error until you learn the agent was acting on a manipulated document, at which point it is a security incident.
Two NIST documents apply, and neither is an "AI agent incident rule." Read them as the closest published guidance, not as a requirement.
NIST SP 800-61 Rev. 3 (April 2025) replaced Rev. 2 from 2012. Its title is Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile. It drops the old four-phase lifecycle and ties incident response to the Cybersecurity Framework 2.0 functions. The Respond function covers incident management (RS.MA), analysis (RS.AN), reporting and communication (RS.CO) and mitigation (RS.MI). Recover has its own incident recovery plan category (RC.RP). Lessons learned feed back through the Improvement category (ID.IM), so the fix-the-procedure step has a home. It is written for cybersecurity incidents in general and does not single out AI agents.
The NIST AI RMF 1.0 (NIST AI 100-1) has a MANAGE function with three subcategories that matter here:
MANAGE 4.3 is the useful one for this topic because it covers errors as well as incidents. For the full mapping, see our NIST AI RMF guide for AI agents. SOC 2 readers will find the equivalent evidence expectations in SOC 2 and AI agents.
Only when a bank determines that a "notification incident" has occurred. The rule is not a deadline for every agent error. It comes from the computer-security incident notification rule that three agencies adopted in parallel: 12 CFR part 53 (OCC), 12 CFR 225.300 through 225.303 (Federal Reserve) and 12 CFR 304.21 through 304.24 (FDIC). The wording in the OCC's section 53.3 is the same in substance as the Fed's section 225.302 and the FDIC's section 304.23.
Two definitions in section 53.2 (mirrored in the other two) carry the weight:
If both tests are met, the bank must notify its regulator as soon as possible and no later than 36 hours after it determines that a notification incident has occurred. The clock starts at the bank's determination, not at the first sign of trouble, and the notice can go by email, telephone or similar methods. The OCC covers national banks, federal savings associations and federal branches and agencies of foreign banks. The Fed covers bank holding companies, savings and loan holding companies, state member banks and certain foreign banking organization operations. The FDIC covers insured state nonmember banks and state savings associations.
A single wrong refund is not "actual harm" to an information system. An agent that corrupts a ledger, exposes customer data or goes down for a major business line might be, and that determination belongs to the bank's incident team with counsel. Separate obligations can also apply, such as suspicious activity reporting or state breach laws, and this post does not cover them. A vendor that performs services subject to the Bank Service Company Act is a bank service provider and has its own duty under section 53.4 to notify affected bank customers as soon as possible after a material disruption of covered services lasting four or more hours.
Most of the work happens before the incident, in how each AI employee is built. Each one has its own identity with least-privilege access, so the first question in any incident, what could this agent reach, has a bounded and written answer. It is not a shared service account.
When we need to contain, the levers are the ones the AOP and approval gates already define. A process owner can tighten the gates so more cases go to a person, and the agent already sends cases it cannot resolve to Needs Attention rather than guessing. In a biopharma procurement deployment, the agent sent 64% of requests to manual review in week one, and the team treated that as the safety mechanism working.
For blast radius, the decision audit trail records the input, sources consulted, action, result, approval state and any human correction for each case, so a reviewer can reconstruct one case without asking an engineer. The AOP's change history shows who changed the procedure, what prompted it and which version is live, which gives you the start of the window. In the biopharma deployment, the agent also wrote its reasoning inside SAP Ariba, where reviewers already worked.
The fix goes through the agent operating procedure. Every change, whoever makes it, runs on a new branch against evals including a golden set, and merges only after review. Only the AOP changes, never model weights, so a change is auditable and reversible by editing the AOP. After merge, the PEV loop validate step checks each case's output before it closes, which is where a new check for this failure lives.
What we do not put inside an agent's identity is the decision to notify a regulator. That stays with the bank's incident team. Regulated buyers most often pair this model with BYOC or on-prem deployment, so logs stay inside infrastructure they already audit. The full model is on our trust and security page.
