When the agent sends something it should not have

At some point an agent will send something it should not have. The wrong recipient, the wrong amount, a summary of one customer's thread to another, or forty messages when it should have sent one. What separates a bad hour from a bad quarter is entirely how the first hour goes, and that is worth deciding before it happens rather than during.

31 July 2026 · 5 min read

The first ten minutes: stop it#

Revoke the key. Not pause the workflow, not push a prompt change: revoke. A key belongs to one agent, so revoking stops that agent and leaves everything else running, which is precisely why the one key per agent rule matters before an incident rather than after.

Do this before you understand what happened. Every minute of investigation with the agent live is another minute of sending, and the cost of stopping a healthy agent for twenty minutes is close to zero.

Then check whether it is still sending. Confirm the revocation took effect by looking at the identity's outbound activity, not by assuming.

The next thirty: the blast radius#

Three questions, in order, all answerable from the audit trail because every message is recorded against an identity with the key that sent it.

1. What went out? Everything from that identity in the window, not just the message someone reported. The reported one is rarely the only one.
2. To whom? Pay particular attention to recipients the agent had never contacted before, which is both the exfiltration shape and the mistyped-recipient shape.
3. What was in it? Specifically, whose data reached whom. This decides whether you are handling an embarrassment or a personal data breach.

That third answer starts a clock. Under GDPR, a personal data breach carries a 72 hour notification obligation, and "we were still investigating" is not a defence for missing it. The shape of that obligation is in the compliance floor.

The hour: contain the consequences#

Suppress where needed. Anyone who should not be contacted again goes on the suppression list immediately, which enforces it at the infrastructure layer rather than in a prompt, per bounces, complaints, and suppression.

Tell the recipients, quickly and plainly. A short correction from a person, in the same thread, beats a polished apology tomorrow. If something was sent to the wrong person, ask them to delete it, and say what it contained rather than describing it vaguely.

Tell your own people. Support, sales, and whoever owns the account should hear it from you before they hear it from a customer.

Do not let the agent apologise. The correction goes out from a human. An agent apologising for an agent failure lands badly and, if the underlying cause is still live, can compound it.

Working out what actually happened#

Five causes cover almost everything, and they have different fixes.

The diagnostic that separates them fastest: read the inbound message that preceded the send. Four of the five are visible in it.

The postmortem, and the one question that matters#

Write it down within a day, while it is still uncomfortable. Timeline, cause, blast radius, what you told whom, and the fix.

Then ask the question that produces most of the value: was there a control that would have caught this, and why was it not there? The answers are usually one of a small set. It was a prompt instruction rather than an enforced limit. It was an alert nobody routed to a person. It was an approval gate removed for speed. It was a capability the agent did not need this week and had anyway.

Fix that, add the incident to the golden thread suite so the same shape fails a test in future, and only then restore the agent.

Restoring service#

In this order, and not faster:

1. The specific fix is in place, in tooling rather than in prose where possible.
2. The golden suite covers the case.
3. A new key is issued and the agent redeployed.
4. Whitelist mode or an approval gate reinstated for the affected category, temporarily.
5. Someone reads every thread for the next two days.
6. The gate comes off when the evidence supports it, per approval a human will still read.

Rolling a category back to human handling while you fix things is a normal decision, not a defeat, and treating it that way is what keeps the whole project safe to attempt.

Preparing while nothing is wrong#

Half a day, once:

• A named owner per agent who can revoke a key without asking permission.
• The revocation path tested, so you know it works and how fast it takes effect.
• Alerts that fire to a person: first send to a new domain, volume moving sharply, bounce or complaint movement.
• A short template for the correction message, so nobody is drafting under pressure.
• Agreement in advance on who decides whether something is a notifiable breach.

The teams that handle this well are not the ones with better agents. They are the ones who decided these five things on a quiet afternoon.

Questions#

What is the first step when an AI agent sends something wrong?

Revoke its key. Stopping the agent comes before understanding what happened, because investigation with the agent live means it is still sending.

How do I find out what it sent?

The per-identity audit trail records every message with its thread and the key that sent it, so scoping the window is a filter rather than an investigation. Pay attention to first sends to unfamiliar domains.

When is this a data breach?

When personal data reached someone who should not have it. Under GDPR that starts a 72 hour notification clock, so the decision about whether it qualifies should have a named owner in advance.

Should the agent send the apology?

No. Corrections go from a person, in the same thread, quickly and plainly. An agent apologising for an agent failure lands badly.

What are the common causes?

Wrong recipient, context bleed between threads, a loop, prompt injection, and an ungrounded answer. Reading the inbound message that preceded the send distinguishes four of the five quickly.

When can the agent go back online?

Once the fix is enforced in tooling, the case is covered by a test, a new key is issued, and a temporary gate is back on the affected category with someone reading threads for a couple of days.