Sooner or later an agent does something it shouldn't: it sends the wrong message, changes the wrong record, spends past its ceiling, or acts on instructions it should never have obeyed. When that happens, the technical fix is usually the easy half. The hard half is disclosure — deciding who needs to be told, what they need to be told, and how fast. Teams that decide those questions during the incident decide them badly. This guide works through the decision in advance: what counts as an incident, who the audiences are, what a good disclosure contains, and the mistakes that turn a manageable failure into a lasting one.
First contain, then disclose — in that order, but not far apart¶
The first moves are operational: stop the agent or the action, revoke what needs revoking, and preserve the records before anything rotates away. Disclosure follows containment, because a notice sent while the agent is still misbehaving is a promise you cannot keep. But "follows" means hours or days, not weeks. Every day spent polishing a statement while affected people sit uninformed is a decision — and it will be read as one later. A workable rhythm: contain immediately, notify the people directly affected as soon as you know enough to be accurate about them specifically, and broaden the disclosure as the facts firm up. A short, honest early notice beats a complete late one, provided the early notice is clearly labelled as preliminary and is actually followed by the update.
Work out who the audiences are¶
Different audiences are owed different things, and conflating them produces notices that serve none of them:
- Affected users or customers. Anyone whose data, money, account, or decisions the agent touched. They are owed a direct, specific account: what happened to them, not a general statement about an incident.
- Your customers, if you operate the agent for them. Where a business runs agents on behalf of client organisations, those clients are owed notice under the contract and as a practical matter — their own disclosure duties may depend on yours.
- Regulators, where the law requires it. Some incidents carry statutory reporting: a personal data breach can start a 72-hour clock for notifying the supervisory authority under the GDPR, and providers of high-risk AI systems face serious-incident reporting duties under the EU AI Act. Know which regimes your agents operate under before an incident names them for you.
- Your own leadership and board. Internal disclosure matters too: the people answerable for the system should learn about a serious incident from the incident process, not from a customer's screenshot.
- The public, when the incident is already public or broad. If the affected group is large or the incident is visible, a public statement sets the record straight in your own words.
Judge severity by effect, not by embarrassment¶
Disclosure effort should scale with what the incident did, not with how it looks. Ask: did the agent expose or alter data it shouldn't have? Did it move money or make commitments? Did people act on wrong output? Did it affect one person or everyone in a segment? An agent that double-sent a marketing email warrants a lighter notice than one that altered records or leaked information across accounts. Write your severity tiers in advance, with the audience and the clock attached to each tier, so the person on duty at 3 a.m. is executing a decision rather than inventing one.
What a good disclosure contains¶
Whatever the audience, a disclosure that respects its readers covers the same five elements:
- What happened, in plain language: the agent, the action, the scope. "Our support agent sent refund confirmations for orders that had not been refunded" — not "we experienced an automation anomaly."
- When it happened and when you found out. The gap between the two is part of the story; hiding it reads as concealment when it surfaces.
- What was affected — the data, accounts, money, or decisions involved, as precisely as you know it.
- What you have done: the agent stopped, the change reversed, the exposure closed, the records preserved.
- What the recipient should do, if anything — and a channel for questions that a person actually answers.
Close with what happens next: the follow-up you will send and when, and the changes you are making so the failure mode is closed. Keep speculation about root cause out of the first notice. "We are still establishing the cause" is honest; a confident wrong cause, corrected later, costs more trust than the delay ever would.
What not to do¶
- Do not quietly fix it and say nothing where people were affected. Discovery later — and it is usually later-discovered — converts an incident into a cover-up in the retelling.
- Do not over-claim safety. "No customer data was accessed" before the logs have been checked is a statement you may have to retract. Say what you have verified, and label the rest as still under review.
- Do not blame the model or the vendor as the disclosure. The agent acted under your authority, with your permissions. Account for your system; pursue the vendor separately.
- Do not let legal review sand off every fact. Counsel should check a notice for accuracy and obligation; a notice reduced to "we take this seriously" tells affected people nothing and protects no one.
- Do not disclose other people's data in the disclosure. Tell each affected party about their own exposure, not the whole incident list.
Keep the record that backs the words¶
Every sentence of a disclosure should trace to evidence. The audit trail — what the agent did, what approved it, what it touched — is what lets you say "these 214 messages" instead of "some messages", and it is what you will hand to a regulator, a client, or your own post-incident review. Preserve it before anything else; logs that rotate away in the first day take the facts with them. Afterwards, write the incident record while memories are fresh: timeline, decisions, who was notified and when, and the specific control that failed or was missing. That record is not paperwork for its own sake. It is the difference between an organisation that had an incident and one that is merely hoping the same incident does not introduce itself again.
An agent incident is a test of whether the governance around the agent was real. Teams that disclose promptly, specifically, and from evidence usually find the incident costs them less than the secrecy would have. Decide your audiences, your tiers, and your clocks now — the middle of an incident is the worst possible time to meet these questions for the first time.