A narrative is not enough
An incident report should make a decision easier to defend: what to contain, who may be affected, what to repair or when to restore the workload. A fluent account without record references cannot establish those facts. For AI incidents, the distinction is particularly important because generated text can describe actions that did not occur.
Agree the report audience and questions at scoping. An executive summary needs impact and decisions; engineering needs identifiers, affected boundaries and validation conditions. Both should use the same evidence base. A report can be useful even when it cannot reconstruct every step, provided its limits are explicit.
An illustrative finding record
Fictional example for report design. This is not a client incident or a completed Atlant investigation. An internal assistant had a tool for updating support records. A user reported that an account setting changed unexpectedly. The review found a matching tool request and destination event; the original retrieved content was unavailable.
| Field | Example entry |
|---|---|
| Observation | A support-record setting changed outside the intended workflow. |
| Evidence | Run R-104 links to tool request T-208 and destination event D-315. These are fictional identifiers. |
| Confirmed effect | The destination event and record history show a completed change under the service identity. |
| Unknown | The original retrieval source was not retained; prompt injection is one hypothesis, not an established cause. |
| Containment record | The owner restricted the affected write capability and checked pending jobs. |
| Recovery criterion | Validate the required approval boundary and confirm authorised operations still work. |
Separate four statements buyers often collapse
- The system could access a record: a permission observation.
- The record was retrieved into a run: an execution observation requiring supporting records.
- The model included information in its output: an output observation.
- An unintended recipient received it: a disclosure conclusion requiring evidence of the recipient and delivery.
Use the strongest conclusion supported by the available records. If the data population or recipients remain uncertain, state the uncertainty and the next evidence request. Do not label all accessible data as confirmed stolen, or use missing records as proof that disclosure did not happen.
Make remediation verifiable
A recommendation such as “improve AI security” gives engineering no acceptance condition. A useful action names the affected boundary, its owner and the evidence that demonstrates completion. If the finding concerns excessive tool authority, validate the intended and prohibited operations under the relevant identity rather than merely observing a different model answer.
The report should also identify changes outside its scope. A containment action can stop a symptom without resolving the source or repairing previous effects. Assign residual risks and dependencies, including provider support, to the customer’s decision process.
Specify deliverables before the investigation
Ask for an evidence register, timeline, finding structure, impact assessment, containment decision log and recovery validation record where relevant. Define how working records and sensitive attachments will be transferred and retained. Legal counsel should determine any specific legal-use or privileged-communication arrangements.
See our AI incident response deliverables, forensic investigation approach and cost and scope guide. You can prepare a response brief without providing sensitive evidence, or return to the AI incident response homepage.
