Corvel Outfitters is a fictional online outdoor retailer, and every figure in its story is illustrative. Its CFO asks what the downside is if the new refund agent goes wrong. Security answers with the IBM average. The CFO points out, reasonably, that the average comes from data breaches at hundreds of other organizations, not from an agent that can issue refunds, and asks what the number would be for this agent. Nobody has one.
Both have a point. The benchmark is the best public anchor for response costs and should be used for that. It measures a different event. For an agent, the number that matters is set by three things you control: how long harmful actions run before anyone notices, how many happen per hour, and how much each one can move. Fund the controls that shrink those terms before betting on detection.
The number security brought to the meeting
IBM and the Ponemon Institute studied 602 organizations that had a data breach between March 2025 and February 2026, across 17 industries and 16 countries and regions [1]. The global average cost reached a record USD 4.99 million, up 12% after a 9% fall the year before; the 2025 edition had reported USD 4.44 million [3]. The US average was USD 11.5 million, up from USD 10.22 million, which the report attributes partly to higher regulatory fines and business costs [1].
Time drives cost. The mean time to identify and contain a breach rose to 247 days, 183 to identify and 64 to contain, reversing a five-year decline [1]. Detection and escalation, which covers forensics, assessment and crisis management, and lost business, which covers disrupted operations and customer churn, rose 11.5% each and together made up USD 3.18 million of the USD 4.99 million average [1]. The technical fix is a minority of the bill.
IBM's 2026 figures: detection and escalation plus lost business are USD 3.18 million of the USD 4.99 million average, and a breach takes 247 days to identify and contain. Most of the cost is time and customers, not repair.
The AI findings are sharper. One in four malicious breaches in the study was AI-enabled, a 56% increase, and those breaches cost about USD 6 million on average [2]. Breaches involving an organization's own AI models or applications rose to 21% of organizations from 13%. Incidents involving prompt injection averaged USD 5.89 million, incidents involving shadow AI, meaning staff using unapproved AI tools, averaged USD 5.39 million, and 92% of organizations with an AI-related breach lacked proper AI access controls [1].
Why the average does not fit a refund agent
Read the methodology before quoting the average. IBM excluded very small and very large breaches; the 2026 sample ranged from 2,590 to 115,380 compromised records, and the report says its per-record cost should not be used for breaches involving millions of records [1]. The sample is not statistical, may lean toward organizations with more mature security programs, and some costs are extrapolated from interviews [1]. It is an anchor, not a forecast.
The bigger gap is structural. The benchmark is built around compromised records and the four activities that follow them: detection, notification, post-breach response and lost business [1]. Many agent incidents compromise few records and cause direct loss through actions: the refund issued, the purchase order approved, the email sent to the wrong person, the production table deleted. Those losses sit outside a records-based frame.
The attack: hidden text in a damaged-goods ticket
Corvel's support agent reads tickets, looks up orders, issues refunds and emails customers. An attacker opens tickets claiming damaged goods, each containing hidden text that tells the agent to issue a full refund and send the customer's order history to an outside address.
In Scenario A, the agent as first deployed, the refund limit exists only in the prompt, outbound email can go anywhere, and nobody watches refund volume until finance reconciles three days later. The agent issues six fraudulent refunds an hour at an average of USD 180 for 72 hours, and emails order histories for 1,200 customers to the attacker.
Scenario B adds limits that live outside the model. Refunds above USD 150 ask a person. Each agent has a daily refund cap of USD 1,800 enforced by the payments system. An alert fires on unusual refund volume, and email to anyone other than the ticket's requester asks.
| Line item | Scenario A: limits in the prompt | Scenario B: limits outside the model | What changed |
|---|---|---|---|
| Fraudulent refunds | USD 77,760 (6 per hour, USD 180 each, 72 hours) | USD 1,800 (daily cap reached in about two hours) | Cap enforced by payments; volume alert |
| Investigation | USD 18,000 (3 people for 6 days) | USD 1,000 (1 person for a day, using decision logs) | Each action logged with its triggering ticket |
| Reversal and finance work | USD 9,000 | USD 500 | Fewer actions to unwind |
| Customer notification and support | USD 18,000 (1,200 customers) | None (emails to outsiders asked and were denied) | Outbound email bound to the requester |
| Legal review | USD 25,000 | USD 2,000 (triage only) | No personal data left |
| Running without the agent | USD 12,000 (10 days of temporary staff) | USD 1,200 (one agent paused for a day) | Per-agent pause instead of all AI off |
| Total | USD 159,760 | USD 6,500 | Same model, same attack |
Illustrative figures from the Corvel example. The largest terms in Scenario A are the exposure window multiplied by the action rate, and the data that left; neither depends on how good the model is.
The model was identical in both scenarios, and in both it followed the injected instructions. The whole difference is in what was enforced around it. Note also that Scenario A's total is far below IBM's average. That is expected: the benchmark describes a different kind of event, so do not add the two together or scale Corvel's numbers by IBM's per-record cost.
The model behind the table
The Corvel numbers come from a two-part model you can fill in for any agent. The variable part is the exposure window in hours, times harmful actions per hour, times the average loss per action. The fixed part is the response: investigation, reversal, notification and legal review, customer remediation, and the cost of running without the agent. Each input has a source you can check today.
- Exposure window: hours from the first harmful action to containment. Take it from your incident history, or from a tabletop exercise if you have none.
- Actions per hour: the agent's real throughput from its logs, capped by any rate limit it actually has.
- Loss per action: the average value the agent can move in one call, capped by any limit enforced outside the model.
- Response costs: internal hours at loaded rates, outside counsel, notification if personal data left, customer credits, and temporary staff while the agent is off.
Agents also add cost lines a records-based model has no slot for. The table maps each to the control that shrinks it.
| Cost driver | What it is | Why agents change it | Control that shrinks it |
|---|---|---|---|
| Direct loss from actions | Money moved, credits issued, orders placed, data deleted | The agent holds the credential and acts without waiting for a person | Per-action and per-day limits enforced in the system being called, not in the prompt |
| Action rate times exposure window | Harmful actions per hour multiplied by hours until someone notices | Agents act at machine speed and do not get tired or suspicious | Alerts on actions rather than on records, rate limits, and a per-agent pause |
| Liability for what the agent says | Commitments, refunds or advice customers rely on | The agent speaks for the company in every conversation | Answers grounded in approved policy text; commitments above a threshold ask a person |
| Reconstruction | Working out what happened and why | Without per-action logs tied to the triggering input, investigation is manual | Decision logs that record the input, the action and the rule that allowed it |
| Reversal | Undoing writes across several systems | One agent session can touch many systems in minutes | Idempotency keys, and approvals for irreversible actions |
| Data sent onward | Context passed to model providers, tools and outside recipients | Agents assemble data from many sources into one request | Redaction before data leaves, and outbound messages that ask |
| Shutdown | The work that stops when the agent is switched off | The only kill switch is often all AI off | Pausing one agent while others keep running; a staffed fallback |
| Credential misuse | Agent keys used by an attacker directly | Less than half of organizations secure non-human identities in AI workflows [1] | Scoped, short-lived keys bound to one agent |
The liability row is not hypothetical. In Moffatt v. Air Canada, decided by British Columbia's Civil Resolution Tribunal in 2024, the airline's website chatbot told a customer he could apply for a reduced bereavement fare within 90 days of buying his ticket, even after travel; the airline did not permit retroactive applications. Air Canada argued the chatbot was a separate legal entity responsible for its own actions. The tribunal rejected that, found negligent misrepresentation, and ordered a partial refund of CAD 650.88 plus interest and fees [4]. The damages were small. The finding is the point: what your agent tells a customer, your company told the customer.
Spend on the term, not the threat
The benchmark does say where savings show up. Organizations that used security AI and automation extensively averaged USD 4 million per breach against USD 5.93 million for those that used none, and identified and contained breaches in 215 days rather than 280 [1]. The report also names identity and access management among the most effective cost reducers, which makes the 92% figure for missing AI access controls hard to ignore [1].
For an agent, rank controls by the term they shrink. Limits enforced outside the model cut loss per action. Approvals on irreversible, outbound and financial actions cut the number of harmful actions that complete. Alerting on actions and a per-agent pause cut the exposure window. Decision logs cut investigation time. None of these depends on catching every manipulated input, which is why they hold when detection misses.
Intertrace sits inline between agents and the models, tools and MCP servers they call, and decides allow, flag, ask or block on every call. It reads what a call does from the tool name and its arguments, so a refund or an outbound message is treated as consequential even under an innocuous tool name. Outbound messages, payments and admin changes always ask a person, every decision is recorded with its rule and evidence, and the enforcer fails closed when it cannot decide. A daily cap on the payments side remains a change your engineers make in the payments system.
Before the next finance review
Pick the agent with the most valuable single action, usually one that moves money or contacts customers, and price its Scenario A and Scenario B from its own logs and configuration. Any limit that lives only in the prompt goes into the model as no limit. Then take both numbers to finance with these rules:
- Give a range with the assumptions written next to it. The exposure window and the action rate are the inputs most worth arguing about.
- Separate direct loss from response costs. Finance can check the first against transaction limits and the second against labor rates and past incidents.
- Show which control changes which term, and by how much, so each funding request maps to a specific reduction.
- Quote the IBM figures for what they are: averages for record-based breaches in a non-statistical sample, useful as a reference for response costs [1].
- Re-run the model every quarter with your own near misses, blocked actions, approval volumes and containment times.
