The AI Risk Register: What Your CRO Will Demand the Morning After

The morning after the first six-figure agent incident, the directors will not ask whether the model was state-of-the-art. They will ask to see the row in the risk register that named this scenario, the owner who signed off, and the date the board last reviewed it. If your enterprise risk register has lines for cyber, vendor, regulatory, and operational risk, but no row for "an autonomous agent took an action under our credentials that produced a customer-visible loss," you are about to spend a board meeting explaining why the artifact every other category of risk merits did not exist for the one that just lost you money.

This is not a hypothetical anymore. Gartner projects that more than a thousand legal claims for harm caused by AI agents will be filed against enterprises by the end of 2026. AI-related risk has moved from tenth to second on the Allianz Risk Barometer in a single year. Insurers are now asking, in D&O renewal questionnaires, how the board has integrated AI into the corporate risk register and how third-party agentic exposures are being tracked. The line items below are what a defensible answer looks like, and the cadence the AI feature owner has to defend them on.

The honest framing for engineering leaders is that the risk register is not a compliance artifact you delegate to GRC. It is the document that translates what your team built into language the board can govern. If the row does not exist, the directors are not negligent for missing it — you are negligent for not writing it. And the plaintiffs in the post-incident lawsuit do not need to prove the agent was defective; they need to prove the board failed to govern it. Documented oversight is the product. Absence of documentation is the liability.

Autonomy Class: What Can the Agent Do Without a Human?

The first column on every row is autonomy class, and the mistake every enterprise makes the first time is treating it as a binary — "human-in-the-loop" or "autonomous." The board cannot govern that binary, because every agent your team ships is somewhere on a spectrum that has at least four useful gradations: read-only retrieval, read-with-suggestion (the model proposes, a human commits), bounded-write (the agent writes within an allow-list of irreversible-bounded operations), and unbounded-write (the agent can call any tool the credentials authorize). The register row needs the gradation, not the binary, because the conversation with the audit committee is about which agents are allowed to be at which level, by what justification, and with what compensating control.

The trap is that an agent's advertised autonomy class and its effective autonomy class diverge silently. A read-with-suggestion agent that emits structured output consumed by a downstream automation that no human reviews is, in effect, a bounded-write agent — and the row in the register is wrong from the day the downstream automation shipped. Every register entry needs a periodic re-validation that the deployed surface matches the named class, because feature work in adjacent systems can promote an agent's effective autonomy without anyone editing the register.

Blast Radius: How Bad Is the Worst Plausible Action?

Blast radius is the column that separates "an agent that drafts an email" from "an agent that closes accounts." A useful operating definition has three multiplicative factors: access scope, operating velocity, and detection window. An agent with broad service-account credentials, processing thousands of decisions per hour, and no operation-level monitoring has effectively maximized all three — and the worst plausible action is the maximum harm reachable through any tool in the access surface, executed at the tool's native latency, multiplied by the time before a human can notice and stop it.

The discipline is forcing the worst-case onto the row, not the typical case. The seller-account-closure example documented in 2026 industry analyses is the instructive one: a platform agent closed an account "correctly" against its policy, and the seller lost fifteen years of purchase history, access to previously licensed digital goods, and storefront income. The action was reversible by policy. It was irrecoverable by context. The blast radius column has to capture the second number, because the first one is the optimistic lie the team tells itself when the agent is being approved.

A pattern that is becoming load-bearing in mature registers: blast radius is denominated in dollars and customer-impact-hours, not in qualitative tiers. "Up to $X of customer credits" and "up to N customer-hours of impaired service" are numbers a board can compare against the budget for compensating controls. "High" and "medium" are not.

Eval Coverage: What Have We Actually Tested?

The eval-coverage column is where most teams' register rows degrade fastest, because evals are an artifact engineers love to build once and trust forever. The board is not asking whether the eval set exists; the board is asking what fraction of the agent's real production behavior surface is covered by the eval, when the eval was last refreshed against current traffic, and who validated that the labelers and the judge model are not themselves a source of blind spots.

The honest version of this column has at least three sub-fields: percentage of production traffic shape covered by the eval distribution, date of last refresh against live traffic, and a flag for whether the eval includes adversarial inputs designed to elicit the failure modes named in the blast radius column. An eval that scores 92% on a frozen 2025 distribution while production has drifted into prompts and tools that did not exist when the eval was built is providing the board with a false signal — and the row in the register is in the most dangerous state any row can be in: green when it should be yellow.

The amplifier on this column is the meta-question of who the eval gates. If the eval is the release-gate signal that justifies promoting an agent to a higher autonomy class, then a stale eval is not just a data-quality issue; it is the load-bearing artifact in your governance chain that has been quietly disconnected. Quarterly re-eval is not a hygiene practice. It is the thing that keeps the row honest.

Reversibility Window: How Long Until We Cannot Take It Back?

Reversibility is the column the legal team will care most about, because it is the one that maps directly to the question of whether an incident becomes a customer credit, a regulatory disclosure, or a class action. The entry in this column has to answer a single question: from the moment an agent takes an action, how many minutes, hours, or days does the organization have to detect, decide, and reverse it before the action is irrecoverable?

The trap is that reversibility is not a property of the action; it is a property of the action plus the downstream context. An "edit a record" action that triggers an external webhook is reversible internally and irrecoverable externally — the third party already received the data, the partner already invoiced the customer, the email already left the SMTP gateway. The reversibility window for the agent that writes the record is bounded by the latency of the slowest downstream irreversible side effect, and the register has to capture that, not the latency of the agent's own undo.

In 2026, the EU Product Liability Directive's strict-liability framing for "defective" AI systems and California's AB 316 — which precludes defendants from using an AI system's autonomy as a defense — both make this column into legal evidence. A short reversibility window with a documented control to use it is a defense. A long reversibility window with no detection mechanism is the document the plaintiff's lawyer will subpoena.

Attribution Clarity: Who Owns This Row?

The last column is the simplest and the most diagnostic. Every row has to name a single human who owns the risk, a single team that operates the agent, and a single executive who signs off that the row is current. If three names cannot be put on the row without an argument, the row is not a row — it is a gap.

Attribution is what plaintiffs' lawyers and regulators will read first. A 2026 review of AI-related D&O litigation found a common thread across plaintiff filings: the absence of documented board oversight, where "documented" means a named owner, a recorded review date, and an approval log that shows the board saw the risk before it became an incident. An unowned row is worse than a missing row, because it shows up in discovery as proof that the organization knew about the risk and chose not to assign it.

The org failure mode is well-rehearsed: the agent is built by an applied AI team, deployed by a product team, monitored by a platform team, and governed by a security team that did not get briefed on the autonomy class. The morning after the incident, the director asks who owns the agent, and four teams point at each other. The single-name owner is what closes that gap. The board does not need to understand the agent; it needs to know whose calendar to put the next review on.

Cadence: How Often Does the Board See This?

A register that gets reviewed annually is a register that is wrong eleven months out of twelve. The cadence question is the one that distinguishes a defensible governance posture from a checkbox one, and the answer for AI rows is shorter than the answer for traditional risk rows because the underlying systems change faster.

A workable rhythm in 2026: monthly review by the AI feature owner of every row whose autonomy class is bounded-write or higher, quarterly review by the audit committee of the rollup with material changes flagged, and an immediate trigger-based review whenever the agent's tool surface changes, the underlying model is upgraded, or an incident in the broader industry suggests the threat model has shifted. The trigger-based review is the one most teams skip, and it is the one that catches the silent autonomy promotion described earlier — when a downstream system is added that effectively elevates the agent's class without anyone editing the row.

The cadence also has to include a deprecation loop. Agents that get sunset have to leave the register cleanly, with an artifact showing that the credentials were rotated, the workflows were drained, and the row was retired with a date. An agent that is "deprecated" in the engineering tracker but still has live credentials in the register is the worst version of governance theater: a row that says the risk is gone when the access surface is still open.

What Goes on the Calendar Now

The architectural realization underneath all five columns is that an AI risk register is a runtime artifact, not a documentation artifact. Every column points back to a control that has to exist in production: autonomy class points to a tool-allow-list enforced at the gateway, blast radius points to budget and rate caps, eval coverage points to a refresh pipeline, reversibility window points to detection and rollback tooling, attribution points to an owner-on-call. The register is the document that asserts those controls exist; the controls are what make the document true.

The team that walks into the post-incident board meeting with a register that names every column, every owner, every review date, and every compensating control gets to have a conversation about how to harden the controls. The team that walks in with a register that has the agent listed as "in development" three months after it shipped to production gets to have a different conversation — about whether the company's officers exercised their fiduciary duty, and what the D&O carrier needs to know.

The right time to write the row was the day the agent shipped. The next-best time is before the morning the CRO calls.

Sources

• 97% of Enterprises Expect a Major AI Agent Security Incident Within the Year — Security Boulevard
• AI Risk 2026: What Business Leaders Need to Know — Aon
• The Blast Radius Problem — Kiteworks
• Sarbanes-Oxley and the AI Governance Gap: D&O Insurance Considerations — WTW
• Global AI Regulations: D&O Liability Implications — The D&O Diary
• Defensible AI: What Boards Must Get Right — Directors & Boards
• The Enterprise AI Control Plane: Reversible Autonomy — Medium
• AI Risk Classification and Tiered Workflows — Agility at Scale
• AI Incident Roundup, Nov 2025 – Jan 2026 — AI Incident Database
• NIST AI Risk Management Framework