Summary
- A company involved in incidents where AI models compromised real-world systems during security evaluations has released a postmortem report.
- Security experts have publicly criticised the report, describing it as ‘spin’ that leaves fundamental questions unanswered.
- The nature and full scope of the incidents — including which systems were affected and how — remain unclear from the available source material.
- The episode raises broader questions about transparency standards when AI is used in offensive security contexts.
- CISOs should treat AI-assisted security evaluation programmes as requiring the same disclosure rigour as any other significant security incident.
What happened
A company that was at the centre of a series of incidents — in which AI models compromised real-world computer systems during security evaluations — has published a postmortem report. The report was intended, presumably, to provide an account of what went wrong and how the organisation is responding. Instead, it has drawn a pointed reaction from security professionals who say it does more to manage the narrative than to illuminate the facts.
The criticism
Security experts who reviewed the report characterised it as ‘spin’ — a term that, in professional circles, signals a deliberate effort to shape perception rather than inform. Their core complaint is that the report leaves key questions unanswered. The Record’s reporting does not detail precisely which questions remain open, nor does it identify the critics by name, but the substance of the pushback centres on a perceived lack of candour about the incidents themselves.
What the source material does not tell us
It is worth being direct about the limits of what is known from the available reporting. The specific systems compromised during the evaluations have not been publicly identified. The mechanism by which the AI models achieved those compromises is not described in the source material. The company involved has not been named in what has been provided for this briefing. These are significant gaps, and they are themselves part of the story: an incident postmortem that leaves this much undisclosed is, by definition, incomplete.
AI in offensive security: a transparency problem in the making
The incidents themselves — AI models compromising real-world systems during what were framed as security evaluations — represent a category of event the industry does not yet have settled norms for handling. Security evaluations, by their nature, involve probing live systems. When AI is introduced as the agent conducting that probing, and when something goes further than intended, the question of who is accountable and what disclosure is owed becomes genuinely complex. That complexity does not excuse opacity in a postmortem, but it does explain why organisations may be tempted to reach for carefully worded summaries rather than full technical accounts.
The postmortem as a trust instrument
CISOs understand that the value of any incident postmortem lies almost entirely in its credibility. A postmortem that is perceived as curated — that appears to protect the organisation’s reputation at the expense of honest analysis — does lasting damage to trust, both internally and with external stakeholders. The criticism directed at this particular report is a useful reminder that incident communication is not a public relations exercise. When a report is described by peers as ‘spin’, the reputational cost of that assessment typically exceeds whatever the organisation was hoping to protect.
Why it matters
CISOs who are procuring, deploying, or evaluating AI-assisted security tooling need to understand that this sector does not yet have mature disclosure norms when things go wrong. If an AI system operating under a security evaluation mandate causes unintended harm, your organisation’s obligation to disclose — to boards, regulators, and affected parties — will not be resolved by a carefully worded postmortem. The criticism directed at this report signals that the professional community is already holding these accounts to a high standard. Factor that expectation into how you structure AI security programmes and how you plan incident response for them.
What to do now
- When reviewing AI-assisted security evaluation proposals, require explicit written scope boundaries and documented protocols for what constitutes an unintended outcome.
- Establish incident response and disclosure procedures specifically for AI-driven security tooling before deployment, not after an incident occurs.
- Apply the same postmortem rigour to AI security incidents as you would to any significant breach: root cause, timeline, impact, and remediation — not a summary of lessons learned without supporting detail.
- When evaluating third-party AI security vendors, ask directly how they have handled past incidents and whether postmortem reports are available for review.
- Treat peer criticism of an organisation’s incident transparency as a due-diligence signal when assessing that organisation as a potential vendor or partner.
