Building a First-72-Hour Runbook for Counterparty Agent Incidents

The organizations most exposed to this gap are the ones least equipped to close it. Enterprises have security operations centers, in-house counsel, and dedicated risk functions. Small businesses aren’t yet transacting agent-to-agent at material scale. Mid-market organizations sit in the middle, approving agent activity now while relying on a small number of leaders wearing multiple hats. When an incident hits at 2 a.m. on a Saturday, those leaders need a runbook, not a meeting.

Historically, transaction risk was human-mediated and slow: a questionable invoice sat in someone’s queue, a commitment required a signature, and an erroneous payment usually caught someone’s eye before it cleared. Agent-to-agent transactions are machine-mediated and fast, meaning an erroneous or unauthorized commitment can propagate through accounts payable, accounts receivable, treasury, and reporting systems in minutes rather than days.

Detection is the step most mid-market organizations underestimate. Agent-to-agent transactions can fail silently, meaning the transaction completes technically, but the intent, authority, or downstream commitment is wrong. Traditional monitoring tools weren’t built to catch this class of failure, and the first signal often comes from the counterparty rather than the internal system.

A useful runbook defines detection triggers across three categories:

Transactional Anomalies 

Transactional anomalies cover value, frequency, counterparty identity, and timing. An agent that has been approving invoices in a narrow dollar band suddenly approves one three standard deviations above normal. A treasury agent initiates a transfer to a counterparty it has never interacted with before. A procurement agent commits to a purchase outside of business hours in a jurisdiction where the counterparty’s agent shouldn’t be active. Each of these is a signal, but only if someone has defined the baseline in advance.

Behavioral Anomalies

Behavioral anomalies cover an agent acting outside its defined authority. This is where the Agent Authority Model becomes operational. If the authority envelope was never documented, there’s no baseline to detect a violation against, meaning agents can drift outside their intended scope for weeks before anyone notices. A useful behavioral trigger flags any action that falls outside the documented authority envelope even if the transaction itself looks routine on the surface.

Counterparty-Signaled Anomalies

Counterparty-signaled anomalies are the ones that arrive as a message, an email, or a phone call from the other side of the transaction. These are often the earliest and most reliable signals in the first documented incidents, and they’re also the ones organizations are least prepared to receive. Who takes the call? Who has the authority to acknowledge the issue without prematurely admitting fault? Who initiates the internal response before the counterparty’s own containment starts disrupting legitimate transactions? These questions belong in the runbook, not in an ad-hoc Slack thread at 2 a.m.

Detection is where the runbook begins, but detection alone doesn’t stop the bleeding. Once an anomaly is confirmed, the next question is how to contain it without shutting down the parts of the business that are still working correctly.

The first instinct in an agent incident is often to pull the plug. Shut down the agent, disable the integration, and freeze the account. That instinct is understandable, but it’s frequently the wrong move. Legitimate agent activity keeps the business running, and a full shutdown can cause more downstream damage than the incident itself, especially when the incident is narrower than it initially appears.

A well-designed runbook defines containment in three layers, so the response can be proportional to the incident.

Agent-Layer Containment

Agent-layer containment revokes or narrows the specific agent’s authority without disabling the platform. If a procurement agent is committing purchases outside its documented category or vendor scope, the response is to revoke that specific authority rather than shut down procurement automation entirely. This is where the Trust Layer matters. Without a clean way to identify which agent did what, under whose authority, and how to revoke that authority quickly, containment devolves into blanket shutdowns.

Integration-Layer Containment

Integration-layer containment isolates the specific connection between systems without disabling either system. If the agent’s integration into the ERP is producing corrupted invoices, the fix is to quarantine that integration and let the ERP continue operating normally for all other inputs. This requires the ERP, CRM, and financial platforms to be designed with granular integration controls, which is where the state of the underlying business systems either enables or undermines the runbook. Organizations that have done the work of ERP and CRM consolidation into a clean, governed data foundation have far more containment optionality than those still operating across three to seven disconnected systems.

Transaction-Layer Containment

Transaction-layer containment is the newest and least well-understood discipline. It freezes in-flight commitments, blocks downstream reconciliation, and prevents the erroneous state from cascading into AP, AR, treasury, and reporting without shutting down legitimate agent activity. Transaction quarantine is not the same as system isolation. It’s a targeted freeze on a defined set of transactions, and it requires the finance and technology functions to have agreed in advance on what quarantine looks like operationally. When treated as a distinct discipline rather than a byproduct of system isolation, it becomes the single most valuable containment tool in the runbook.

Containment stops the bleeding, but stopping the bleeding doesn’t answer the question that most often paralyzes mid-market organizations at hour one. Who is actually in charge?

Ambiguous ownership is the dominant first-response failure mode, and it’s the pattern showing up most consistently in practitioner conversations across r/Accounting, r/FPandA, and r/AI_Agents. Controllers don’t want to own it, CIOs argue it’s a finance issue when money moves, and Legal wants both parties to own it. This confusion is itself the signal that the runbook doesn’t exist yet.

The ownership matrix must be defined in advance across four functions, with clear handoffs and decision rights at each phase of the 72 hours.

Finance

Transaction impact, disclosure preparation, and insurer notification sit squarely with the finance function. The controller or CFO needs to be able to answer, in real time, what the financial exposure looks like, which disclosure clocks have started, and which policies apply. This is where a Fractional CFO relationship becomes an operational asset rather than a reporting one, particularly for mid-market organizations without a dedicated risk function.

Technology

Detection, containment, and audit-trail preservation fall to the technology function. The CIO or CTO is responsible for executing the layered containment discussed above, coordinating with vendors, and, critically, preserving the evidence that regulators, insurers, and auditors will require after the fact. In practice, technology often has to slow down containment to preserve evidence, which is a decision that has got to be made under pressure without a clear framework unless the framework was built beforehand.

Legal

Disclosure, external notification, and privilege are legal’s domain. The General Counsel or outside counsel maps which regulatory, contractual, and market disclosure obligations have been triggered, sequences the notifications, and establishes privilege over the incident response so post-incident review and remediation don’t become discoverable. In the mid-market, legal is often the function with the least documented playbook for agent incidents, and the runbook should fill that gap explicitly.

Executive Leadership

External communication, board reporting, and cross-functional decision rights rest with executive leadership. When the finance, technology, and legal owners disagree on containment of aggressiveness or disclosure timing, someone at the executive level has to make the call. That person needs to be named in the runbook, not identified during the incident.

Operationalizing the Matrix

An ownership matrix on paper is not the same as an ownership matrix in practice. The runbook has to include the escalation paths, the shared communication channel that all four functions can join within minutes, the decision log format, and the tabletop cadence that keeps the matrix current as agent activity evolves. Most mid-market organizations don’t have the internal bandwidth to build this from scratch while also running the business, which is where an integrated partner across finance, technology, and legal-adjacent process design becomes practical rather than theoretical.

The moment an incident is confirmed, several clocks start at once. Most mid-market organizations dramatically underestimate how many.

Counterparty notification is a decision, and notifying too early can trigger the counterparty’s own containment and disrupt legitimate transactions on both sides. Notifying too late can breach contractual notification obligations and damage the relationship for years. The runbook has to define the notification threshold, the sequence, and the authorized notifier, so the decision is made against a documented framework rather than under pressure.

Regulatory disclosure obligations are widening. Depending on jurisdiction, industry, and materiality, agent incidents may trigger disclosure to regulators, auditors, boards, and in some cases public markets. Financial services organizations have some of the shortest windows, but even organizations that see themselves as outside the regulated perimeter often find themselves subject to disclosure obligations they hadn’t mapped in advance. The runbook should include a disclosure decision tree that lists the applicable regimes, the triggering thresholds, and the required timing for each.

Insurer notification windows are short, specific, and easy to miss. Cyber, errors and omissions, directors and officers, and crime policies each have their own notification triggers, and missing any of them can void coverage that would otherwise apply. Most mid-market organizations have not mapped agent incidents to their existing policy language, meaning the first policy review often happens after the notification window has already closed. The practical recommendation, and the one that requires the least effort to implement before an incident occurs, is to pull every active policy, identify the notification clauses that could apply to an agent incident, and consolidate them into a single one-page reference in the runbook. This can be done in a single afternoon and has an outsized effect on how the first 24 hours unfold.

Audit-trail preservation is consistently the most under-executed step in the runbook, and it’s the one that most directly determines whether the post-incident story is defensible.

In the first 72 hours, teams focus on stopping the bleeding rather than preserving evidence, so logs get overwritten, agent memory gets rotated, counterparty communications get deleted from inboxes as people move on, and downstream systems get restored from backup, wiping the intermediate state that would have shown exactly what the agent did and when. Each of these actions is defensible in isolation, but together they destroy the evidence regulators, insurers, auditors, and potential litigation counterparties will later require.

A useful preservation step in the runbook does three things. First, it identifies which artifacts must be preserved before any restoration or remediation begins, including agent action logs, agent memory snapshots, integration payloads, counterparty communications, downstream system states, and the internal decision log from the incident itself. Second, it specifies the retention format and location, so the artifacts aren’t scattered across individual laptops and personal email. Third, it assigns responsibility for the preservation, which is usually technology in execution but legal in oversight, so the artifacts are retained under privilege where appropriate.

The practical test for whether preservation is working is straightforward. If, ninety days after an incident, the organization cannot produce a chronological, attributable, tamper-evident record of what the agent did, under whose authority, what the internal response looked like, and how the incident was resolved, then preservation failed regardless of how well the containment went.

Once transactions are recovered and systems are stable, mid-market organizations tend to move on. The board wants to know the loss number and the remediation timeline, not the underlying failure pattern. The finance team is already three days behind on close. The technology team is fielding the next set of vendor calls. The instinct to declare victory and get back to normal is strong.

Skipping the post-incident review leaves the same failure modes in place for the next incident, and the next incident is usually not a repeat of the last one. It’s a variant. A useful review answers five questions in writing. What was the root cause across people, processes, technology, and finance? Which parts of the runbook worked as designed, and which failed? Which detection triggers should have fired earlier, and why didn’t they? Which ownership handoffs were clean, and which required improvisation? What changes to the Agent Authority Model, Counterparty Agent Protocol, Trust Layer, and runbook itself are required before the next incident?

The output of the review should feed back into the runbook and into the board or audit committee’s ongoing risk oversight. Treated as a governance artifact rather than an IT deliverable, it becomes part of the same operating cadence as the business continuity plan and the annual insurance renewal.

The final point that most mid-market organizations get wrong is treating the runbook as an IT project. The runbook is a governance artifact that should be approved by the board or audit committee, referenced in the risk register, and reviewed on the same cadence as the business continuity plan. When ownership sits with IT alone, the runbook gets built around technical containment and skips the finance, legal, and executive layers that determine whether the response works.

Board-level ownership also creates commercial upsides. Cyber and errors and omissions underwriters are already asking about agent governance in renewal questionnaires. Enterprise counterparties are beginning to require evidence of an incident response capability before authorizing agent-to-agent integration. Auditors are beginning to scope agent controls into standard engagements. A documented, tested runbook becomes a procurement asset, an insurance asset, and an audit asset rather than only a defensive one, and organizations that can credibly demonstrate a first 72-hour response capability clear those reviews faster than those that cannot.

We approach the counterparty agent incident challenge by helping organizations build an integrated first 72-hour runbook that spans finance, technology, and legal-adjacent process design rather than sitting inside any one function.

Our work typically starts with a mapping exercise, walking through the current agent authority model, the counterparty agent protocol governing agent-to-agent transactions, the Trust Layer that supports identity and revocation, and the existing incident playbook if one exists. From there, we identify the specific hour-zero-through-72 handoffs that need to be defined, the detection triggers that need to be instrumented, and the systems that need to be adjusted to support layered containment and transaction quarantine.

Engagements often begin with a two-to-three-week runbook diagnostic that gives leadership a clear picture of the current gaps, the highest-priority instrumentation and process changes, and a realistic sequence for closing the gap without disrupting existing agent activity. That diagnostic gives the board and audit committee the same view the leadership team has, so runbook approval becomes a governance decision with the right context rather than a leap of faith.

Our managed accounting and Fractional CFO capabilities help us build the transaction impact analysis, disclosure preparation, and insurer notification workflows that finance owns during the response. Our application support, monitoring, and integration experience allows us to instrument the detection, containment, and audit-trail preservation steps that technology owns. Our process optimization and strategy work helps us design the ownership matrix, decision rights, and post-incident review that executive leadership and legal own together. The reason we can define, deploy, and operate the runbook in the same engagement is that the runbook itself is an integrated problem, and treating it as three separate procurements has been the primary reason mid-market organizations haven’t been able to close the gap on their own.

The organizations we work with aren’t looking for another checklist. They want the confidence that when the first counterparty agent incident hits, the response will be measured in hours rather than days, the exposure will be contained rather than compounded, and the story they tell the board, the auditor, the insurer, and the counterparty will be the same story. That confidence comes from a runbook that was built before it was needed, tested against the real ownership matrix, and connected to the finance, technology, and legal systems that must execute it together.