Evidence over alarm
← Back to the incident library
Model deployment incidentCASE STUDY / Financial-services provider

An AI loop halted transactions

Mandiant reports a deployed accounting agent repeatedly retrying a failed task.

Source: Google Cloud / Mandiant
ACTIVITYUndisclosed
PUBLICLY DISCLOSEDSeptember 2026
THE AI’S ROLERepeated execution

Month-level disclosure; activity undated.

THE 10-SECOND TAKEAWAY

Build a stop condition before you automate retries.

HOW IT WORKED

Follow the chain.

An explanation, not a technical reproduction.
Data
→
Tool
→
Failure
SIMPLIFIED VIEW · 1 / 3
STEP 01

Break

An unreadable value broke a tool.

Google Cloud / Mandiant
Move through the story at your own pace.
1 / 3
THINK OF IT THIS WAY

Editorial analogy: a checkout clerk keeps retrying a jammed till. Each attempt costs money, and holding the till open stops other shoppers from paying. The story illustrates a failure loop, not an additional event.

An analogy for the mechanism; not an additional claim about the incident.
KEEP THE EVIDENCE IN VIEW

What we know.
What we don’t.

Reported outcomes

Database locking halted transactions; AI-service charges rose. Google Cloud / Mandiant

Important limits

No hostile actor identified; dates and model undisclosed.

WHY IT MATTERS

The lesson beyond
this one case.

Editorial lesson: a system can disrupt work while trying to complete an ordinary task. Give automated work a clear stopping point, a budget and a way to release shared resources when it fails.

Where were the people?

Staff deployed the agent. Google Cloud / Mandiant

What happened in response? +

Remediation undisclosed. Google Cloud / Mandiant

FROM THE INCIDENT TO THE DEFENSE

What could help
an organization?

Editorial defense connections, not evidence that any product would have prevented this outcome.

Agents

Give repeated work a stopping point

Set a small failure allowance and require a fresh decision before continuing. Enforce the limit outside the model so repeating a plan cannot extend its own permission.

What this does—and does not—establish

Stopping may leave legitimate work unfinished; people need a safe way to inspect and resume it.

Cloud

Limit spending and shared-resource use

Apply account-level budgets, request limits and short database transaction timeouts. Separate experimental work from the resources needed for essential services.

What this does—and does not—establish

A spending alert alone does not stop work. Protective limits must be tested and must not disable unrelated essential services.

Security operations

Notice repeated failure early

Monitor repeated errors, request rates and blocked work together. Rehearse pausing automation, releasing resources safely and escalating to an accountable operator.

What this does—and does not—establish

A high request rate can be legitimate. Investigators need both context and authority to intervene.

Editorial connections to relevant controls, not evidence that a particular technology would have prevented this case. Each guide links to the security guidance behind its recommendations.

Explore the full AI security framework
TRACE IT TO THE SOURCE

Read the evidence.

Explore more original accounts in the source report library ↗.

These are source-reported findings. An independent assessment, when available, is labeled explicitly.

01
AI risk and resilience: A Mandiant special report 2026Google Cloud / Mandiant · September 2026 · investigation

Read this case’s update history →

Reviewed Oct 4, 2026 · Editorial methodology · Structured data