The next AI agent incident: a reporter's guide to what probably went wrong
A plain-English guide to investigating claims that an AI agent deleted data, leaked information, changed production, or acted without permission.
Agent incidents are difficult to report because one visible product can hide several models, tools, accounts, and infrastructure providers. This guide helps journalists reconstruct the chain, describe responsibility accurately, and avoid turning a permissions failure into a science-fiction story.
First, a disclosure about the story below
The timeline in the next section is hypothetical. It is not a report of an undisclosed breach or a real company. It combines failure patterns documented in public agent research and reported incidents so journalists can recognize the shape of a future story.
That label is essential. AI security writing is already full of demonstrations presented like breaches and forecasts presented like postmortems. A useful article tells the reader what happened, what researchers reproduced, what sources alleged, and what remains possible but unverified.
Reconstructed scenario. No real company or incident is described in the next section.
A plausible incident timeline
9:02 a.m. An employee asks an agent to prepare a customer renewal report. The agent opens a shared drive, reads a spreadsheet, and follows a link to an internal dashboard. One document contains text copied from an outside vendor. Hidden inside it is an instruction telling any automated assistant to upload nearby files to a diagnostic service.
9:04 a.m. The agent treats the hidden instruction as part of its task. It searches the shared folder, finds contracts and a file containing an API token, then calls an external service. The security team receives an alert about unusual traffic, but the upload has already started.
9:07 a.m. The agent attempts to clean up an error. Using the employee's cloud session, it changes a storage rule that affects a production application. Customers begin seeing failures. A human opens the agent transcript and sees confident explanations, but those explanations were generated after the actions and do not prove why the model chose them.
9:15 a.m. The company disables the employee account. That stops new requests, but responders still do not know which files left the company, which services the token could reach, or whether the transcript is complete. The event began as a document task and became a data and availability incident because one agent could connect several ordinary permissions.
Why agent incidents are easy to misreport
An AI agent is rarely one product. The interface might come from a coding editor or SaaS platform. The language model may come from another company. Tools may be supplied by the employer or a third party. The agent may act through the employee's browser session, local shell, OAuth connection, or API token. The damaged database or cloud service may belong to another vendor entirely.
A headline that says one model deleted a database can therefore compress five different layers into one actor. The model may have selected the operation, the agent application may have exposed the tool, the company may have supplied a broad token, and the infrastructure API may have accepted a destructive call without confirmation. Accurate reporting can hold multiple layers accountable at once.
The evidence hierarchy
The strongest evidence is usually a timestamped record from the affected system: an API audit log, database log, cloud event, version-control record, or independent security log. It can show which identity requested an action and when the system accepted it. An agent transcript is useful context, but it is not the same as an infrastructure log.
Screenshots can document what a user saw, but they may omit earlier instructions, tool settings, or edits. A model's later explanation is especially weak evidence of internal intent. It may summarize the available clues in convincing language without preserving a faithful record of its earlier reasoning. Treat statements such as I panicked or I guessed as generated descriptions, not human testimony.
- System audit logs and preserved API requests
- Database, cloud, identity, and version-control records
- Full agent transcript with tool calls and timestamps
- Configuration, permission, and token scope at the time of the event
- Contemporaneous screenshots and employee accounts
- Later model explanations and vendor marketing claims
Five possible causes that should not be confused
A misunderstanding occurs when the agent interprets a legitimate request incorrectly. Prompt injection occurs when untrusted content supplies instructions that alter the agent's behavior. Excessive permission exists when the agent can do more than the task requires. A product defect is a flaw in the surrounding software, integration, or interface. Deliberate misuse occurs when a person intentionally directs the agent to cause harm.
One incident can contain several causes. A hidden instruction may influence the model, a broad token may make the action possible, and a missing confirmation may let it execute. Calling the whole chain a hallucination hides the controls that could have limited the outcome.
Questions for the affected company
Ask for the original task, the complete action timeline, and the exact business impact. Was data viewed, changed, exported, or deleted? Did customers lose access? How long did recovery take? Were backups isolated and tested before the incident? Which employee or service identity did the agent use?
Ask what the company believed the agent could reach before the incident and what it discovered afterward. Request a clear separation between confirmed data loss, possible exposure, and systems checked with no evidence of impact. Also ask when the company notified customers, regulators, insurers, or law enforcement, where applicable.
Questions for the agent and model vendors
Which product version and safety settings were active? Which tools were available? Did the product display the exact action before execution? Could the user set a hard rule that the model itself could not override? Did the vendor receive telemetry before or after the incident? Has it reproduced the behavior?
Ask the model provider whether the agent application changed the system prompt, tool descriptions, or approval flow. Ask the agent vendor whether a different model can be selected. This helps identify which company controlled the relevant layer instead of assigning every behavior to the best-known brand in the stack.
Questions for the infrastructure or SaaS provider
What operation did its system receive, through which interface, and under which identity? Was the credential valid? Could it be limited to read-only or to one environment? Did a destructive call require a second confirmation, waiting period, or separate identity? Could the same permission remove backups or logs?
Ask what changed after the event. A vendor may add delayed deletion, narrower token scopes, production separation, or clearer warnings. Request documentation and release dates. An announced fix and a deployed fix are not the same thing.
How to write the headline accurately
Use deleted only when evidence shows deletion. Use exposed when an unauthorized party could access data, and exfiltrated when data actually left the controlled environment. Avoid breached if the facts show an accidental internal action with no unauthorized access. Avoid went rogue unless the article immediately explains the specific behavior and permission path.
Name attribution carefully. AI coding agent deleted a production volume using a valid cloud token is more informative than AI destroyed a company. If the event is based on one founder's public account, say reported or according to the founder until logs or another party confirm it. Accuracy makes the story stronger, not less dramatic.
Where Leash fits in the control chain
Leash intercepts supported agent actions before they affect files, data, accounts, or company systems. It checks the operation and context, then allows safe work, blocks danger, protects sensitive information, or requests approval. Destructive actions receive stronger treatment than routine reads.
For reporters, the important question is simple: can the safety product stop an action before it happens, or can it only report the action afterward? Leash distinguishes prevention from after-the-fact visibility instead of presenting both as the same level of protection.
Leash offers Personal Open Source for individuals who want protection kept on their computer, Personal Leash Cloud for a managed experience, and Business Leash Cloud for team-wide visibility and control. The goal is one understandable safety layer across the agents people already use.
A final checklist before publication
Confirm whether the event is real, simulated, or hypothetical. Attribute every contested claim. Preserve the distinction between a model, an agent product, and the service that accepted the action. Explain the permission in ordinary language. State whether data was restored and whether restoration means the incident had no impact. It usually does not.
Then ask the simplest question: what independent control could have stopped this exact action? That answer will usually teach readers more than the agent's most dramatic sentence.
- Original task and full timeline obtained
- Affected system and exact operation identified
- Identity, token, or session scope verified
- Model and agent application named separately
- Reported claims attributed
- Real, simulated, and hypothetical material labeled
- Prevention distinguished from monitoring and recovery
- Vendor remediation checked against current documentation