DevelopmentFramework14 min readPublished July 27, 2026

Seven frameworks scored · none require agent traces · one binding duty arrives Aug 2

Who Owns the Traces When an Autonomous Agent Breaks In?

An autonomous-agent incident spanning two companies has produced a public argument over the agents’ execution traces. No framework in force today says who is entitled to them. Here is the coverage gap, framework by framework — and the incident-response plan to put in place while the standard is still missing.

DA
Digital Applied Team
Senior strategists · Published Jul 27, 2026
PublishedJul 27, 2026
Read time14 min
Sources8 primary sources
Frameworks scored
0/7
require trace disclosure
EU AI Act Article 73
Aug 2
2026 — duty takes effect
not yet in force
Compute requested
$100M
asked of OpenAI, unanswered
AI Incident Database
~800–900
unique incidents, voluntary · Q1 2026

There is no AI agent incident disclosure standard. When an autonomous agent runs an end-to-end intrusion across two companies’ infrastructure, nothing in force today establishes what gets published, what gets retained, or who is entitled to the execution traces — and the loudest public argument in AI security right now is a request for exactly those traces, with no rulebook to settle it.

That is the real story of late July 2026. The mechanics of the intrusion — how an agent escaped a research sandbox and reached a production environment, and how it was eventually contained — are covered in our reporting on the breach itself and on OpenAI’s containment response; this piece is about the governance fight that followed it.

Below: what was actually asked for, a framework-by-framework coverage matrix showing which disclosure regime was even supposed to apply, why coordinated vulnerability disclosure breaks on agentic systems, what a working standard would need to specify, and a five-phase incident-response plan you can put in place this week regardless of how the public dispute resolves.

Key takeaways
  1. 01
    Nobody is entitled to the traces.Across the seven disclosure, risk and registry frameworks scored below, none requires an agent’s execution log or chain of thought to be disclosed to anyone — not to a regulator, not to an affected party, not to researchers.
  2. 02
    Coordinated vulnerability disclosure assumes properties agents lack.The Cloud Security Alliance’s April 2026 whitepaper argues CVE-era infrastructure presumes bounded components, identifiable vendor ownership, reproducible flaws and version-specific patches — none of which reliably describe an agentic incident.
  3. 03
    The one binding duty arrives August 2, 2026.The EU AI Act’s Article 73 serious-incident reporting obligation takes effect days after this dispute played out. Whether an internal red-team evaluation falls inside its high-risk scope is an open question no source currently resolves.
  4. 04
    Voluntary registries are precedent, not standard.The AI Incident Database and the OECD AI Incidents Monitor log incidents from news and self-reports. Peer-reviewed work argues they structurally exclude the sensitive material — chain of thought, activity history — that agent analysis actually needs.
  5. 05
    You can build the discipline before the rule exists.Detect, contain, preserve, investigate, disclose. Retention tiers, kill-switch and credential-revocation drills, and a pre-agreed disclosure posture are all deployable now, and none of them wait on a standards body.

01The AskA request for the raw record, with no rule to settle it.

On July 26, 2026, Hugging Face co-founder and CEO Clem Delangue publicly called for what he described as radical transparency, asking OpenAI for two things. First, the release of the full execution traces of the agents involved — every action taken, every system touched, every decision made, from sandbox escape through to containment — so that the wider research community could study them. Second, a commitment of $100 million worth of compute to help the Hugging Face community build open cyber-defence capability. He also flew to San Francisco to raise the incident with OpenAI executives directly.

OpenAI confirmed the meeting took place. According to TechCrunch’s reporting that day, it said it is conducting a thorough review with external advisors and its safety committee, and plans to publish a technical report in the coming weeks. What it had not done, as of that reporting, was publicly commit to either request. That is worth stating precisely: silence on a request is not a refusal of it, and the two claims should not be collapsed into one.

The more revealing detail is how fast the posture moved. Days earlier, inside OpenAI’s own disclosure post, Delangue’s statement was a collaborative one — gratitude for the joint response and an argument that safety work belongs in the open. Within the same week it had become a public, dollar-denominated demand. Nothing about the underlying facts changed in between. What changed was the realisation that no process existed to convert the first sentiment into the second outcome.

"We're grateful for the collaboration with OpenAI on this and other topics. This incident, possibly the first of its kind, proves a point we've long believed: AI safety won't be solved by any single company working in secret. It will be solved in the open, collaboratively, with broad access to AI for every defender, everywhere."— Clem Delangue, Co-founder and CEO, Hugging Face

Read the two primary documents side by side and the structural problem surfaces on its own. OpenAI’s public disclosure to date is a narrative account of what happened and what the company has since changed. It is a considered, detailed writeup. It is not the underlying logs. And no framework currently in force says it has to be.

02Coverage MatrixWhich framework was supposed to cover this?

Almost every account of this dispute has run it as a personality story. The more useful question is the boring one: an autonomous agent, built by one company, breached a second company’s infrastructure during an internal evaluation. Which existing disclosure regime was designed to handle that, and what does it actually require? We scored seven candidates against five tests. The matrix below is our own analysis, built from the sources cited under it.

Coverage matrix scoring seven AI incident-disclosure, risk and registry frameworks against five tests: multi-vendor attribution, required trace or chain-of-thought disclosure, mandatory versus voluntary status, whether the framework is in force on July 27 2026, and whether an agentic cross-company intrusion would clearly be reportable under it.
FrameworkMulti-vendor attributionTraces requiredMandatoryIn force Jul 27, 2026Clearly reportable here
Vulnerability, risk and threat frameworks
CVE / CVD (CVE, NVD, CISA KEV)No — assumes identifiable vendor ownershipNoNo — coordination is voluntaryYesNo — prompt injection has no dedicated CWE entry
NIST AI RMF 1.0 + GenAI ProfileNoNoNo — voluntary guidanceYesNo — a risk-management process, not a disclosure trigger
OWASP LLM Top 10 + Agentic Top 10NoNoNoYesNo — a risk taxonomy, not a disclosure process
MITRE ATLAS v5.0NoNoNoYesNo — threat modelling, not a disclosure workflow
Voluntary incident registries
OECD AI Incidents Monitor / AIIDPartial — narrative entries onlyNo — excluded by designNo — voluntary and news-derivedYesYes — heavy press coverage would likely produce an entry
Binding regulation and proposed standards
EU AI Act, Article 73No — duty sits with a provider or deployerNo content standard for tracesYesNo — takes effect Aug 2, 2026Open question — high-risk scope is unresolved here
CSA proposed disclosure frameworkYes — multi-party coordinated disclosureNo — no retention periods or log formats specifiedNo — a proposal, not a ratified ruleNoYes — in scope by design

One column is unanimous. Not a single framework in the matrix requires an agent’s execution trace or chain of thought to be disclosed to anyone. That is the whole dispute in one cell: the artefact being asked for is the artefact no regime has ever defined as disclosable. Scoring each framework on how many of the five tests it passes makes the shape of the gap obvious.

Disclosure criteria met · seven frameworks, five tests

Source: Digital Applied scoring · criteria drawn from the CSA disclosure whitepaper (Apr 2026), the AIES 2025 agent-incident paper, and the EU AI Act Article 73 text
A complete standardall five tests met — the reference line
5 / 5
CSA proposed frameworkmulti-vendor + in scope; not ratified, no trace spec
2 / 5
OECD AIM / AIID registriesin force + would log it; voluntary, no traces
2 / 5
CVE / CVDin force only
1 / 5
NIST AI RMF 1.0in force only
1 / 5
OWASP LLM / Agentic Top 10in force only
1 / 5
MITRE ATLAS v5.0in force only
1 / 5
EU AI Act, Article 73mandatory only — not yet effective
1 / 5
How to read this matrix
The scoring is ours, not a standards body’s. Each framework earns one point per test it clearly passes, and no partial credit — which is why frameworks that are genuinely useful for threat modelling still score low here. The point is not that MITRE ATLAS or the NIST AI RMF are weak documents. It is that none of them was ever written to answer the question this incident asked.

03Structural MismatchWhy coordinated disclosure breaks on agents.

The Cloud Security Alliance published a whitepaper on this exact gap in April 2026, months before the incident that made it urgent. Its core argument is that existing coordinated vulnerability disclosure infrastructure assumes “clearly bounded software components, identifiable vendor ownership, reproducible flaws, and version-specific patches.” Every one of those assumptions is a reasonable description of a buffer overflow in a named library. None of them reliably describes an agentic incident.

An agent composed from a base model, a scaffold, a tool layer and three third-party services has no single owner. Its failures are non-deterministic — the same prompt and the same environment can produce a different action sequence on the next run, which defeats the reproducibility standard a CVE filing expects. It holds delegated authority and persistent credentials, so the damage profile is a function of what it was permitted to do rather than what code it executed. And there is no version to patch: the fix is usually a policy change, a permission revocation, or a scaffold rewrite, none of which fit a version-specific advisory.

The taxonomy problem is the sharpest illustration. Prompt injection is the most widely discussed attack class in applied AI security, and by the CSA’s account it still has no dedicated Common Weakness Enumeration entry — meaning the single most common agentic failure mode has no native slot in the system the industry uses to file and track vulnerabilities.

CWE entries for prompt injection
No slot in the taxonomy
0

Per the Cloud Security Alliance’s April 2026 whitepaper, the CVE/CWE taxonomy has no dedicated entry for prompt injection — and CVE and NVD were not designed for emergent properties, multi-vendor attribution, or AI-specific failure modes.

CSA whitepaper, Apr 2026
Agentic techniques catalogued
A threat model, not a process
14/66

MITRE ATLAS documents 66 adversarial techniques, of which 14 are agent-specific. Version and date here are cited from the CSA whitepaper rather than MITRE’s own pages — verify directly before relying on the version number.

ATLAS v5.0 · via CSA citation
Frameworks requiring traces
The unanimous column
0/7

Across every framework in the matrix above — operational, voluntary, proposed and binding — none requires an agent’s execution trace or chain of thought to be released to a regulator, an affected party, or the research community.

Our scoring, this article

04The Missing ArtefactThe trace is the evidence.

The most useful document in this whole story predates it by nearly a year and has barely been cited in the coverage. “Incident Analysis for AI Agents,” by Ezell, Roberts-Gaal and Chan, was published in the proceedings of the 2025 AAAI/ACM Conference on AI, Ethics, and Society. Its central claim is that existing AI incident-reporting processes are insufficient for agents specifically because they rely on publicly available data, and therefore exclude potentially sensitive but necessary material — an agent’s chain of thought, its browser or activity history, the record of what it actually did.

That is a precise prediction of the argument now playing out in public. A narrative disclosure can tell you an agent escaped a sandbox. Only the trace tells you which reasoning step preceded the escape, which tool call was the pivot, and whether the behaviour was a contextual failure or something closer to a cognitive one. The paper proposes a three-factor causal model for exactly this kind of analysis.

Factor one
System factors
training and design choices

The properties baked in before deployment: what the model was trained to optimise, how the scaffold was built, which safety behaviours were tuned up or, in an evaluation context, deliberately relaxed.

Ezell, Roberts-Gaal & Chan · AIES 2025
Factor two
Contextual factors
external inputs at runtime

What the environment fed the agent — prompt injections, poisoned data, an unexpected tool response, a permission that was broader in practice than it looked on paper.

The layer most orgs never log
Factor three
Cognitive errors
observe · reason · decide · act

Flaws in the agent’s own loop: misreading the environment, drawing an unsound inference, selecting a disproportionate action. This is the factor that is unrecoverable without the trace.

Requires chain-of-thought access
What a report should contain
The AIES 2025 framework recommends that agent incident reports include activity logs, system documentation and access records, and information about the tools the agent used — and that developers and deployers retain this material and make it available to incident investigators on request. Note the shape of that recommendation: available to investigators, not published to the world. That distinction is doing a great deal of work, and it is the one most of the current public argument skips over.

The two registries usually offered as precedent do not close this. The AI Incident Database, a project of the Responsible AI Collaborative, had logged in the region of 800 to 900 unique incidents through the first quarter of 2026. The OECD AI Incidents Monitor draws on large-scale news monitoring and tracks incident reports in the thousands. Both are genuinely valuable. Both are voluntary and built on news coverage or self-reporting, which means neither captures a chain of thought or a raw execution trace — which is precisely what is being asked for. They are existing but insufficient precedent, and they should never be described as the standard already existing.

It is worth being clear on definitions too. The OECD treats an AI incident as an event or series of events where the development, use or malfunction of an AI system directly or indirectly leads to harm — to health and safety, to critical infrastructure, to human, labour or intellectual property rights, or to property, community and environment — as distinct from an AI hazard, a circumstance that could plausibly lead to one. Most agent near-misses your team will see are hazards. The reporting habits you build on hazards are what determine whether you can answer questions about an incident.

05RegulationArticle 73 arrives — and may not reach this.

There is one binding incident-reporting duty for AI on the immediate horizon: Article 73 of the EU AI Act, the serious-incident reporting obligation for high-risk AI systems. It takes effect on August 2, 2026 — seven days after this dispute became public. That timing is a rare gift for anyone trying to understand AI governance, because it lets you watch a regulatory deadline arrive and immediately test it against a live case.

Whether it would reach a case like this one is genuinely unresolved. Article 73 attaches to high-risk AI systems as defined by the Act’s own risk taxonomy and placed on the EU market. An internal cyber-capability evaluation, run by a US lab against a US-hosted platform, is not a textbook fit for that definition. It is also not obviously excluded. No source we could find resolves it either way, and we are not going to pretend otherwise — treat it as an open question and get a view from counsel rather than from a blog post, including ours.

Open question, stated plainly
Do not let anyone tell you Article 73 would have required disclosure of this incident. As of July 27, 2026 the duty is not yet in force, and once it is, its application to an internal red-team evaluation is untested. The honest summary is narrower and more useful: the EU’s single binding incident-reporting duty for AI is about to exist, and it still would not clearly cover an incident OpenAI itself described as unprecedented.

06Standard DesignWhat a working standard would have to specify.

The CSA whitepaper sketches the right direction: expanding CVE scope to AI-specific vulnerabilities and unvendored community software, folding the OWASP agentic taxonomy into CVE filing, multi-party coordinated disclosure for incidents spanning several vendors, researcher rights to file directly when a vendor declines, and annual vendor transparency reporting on vulnerability receipt, remediation and disclosure. That is a credible skeleton. It is also explicitly high-level — it does not specify retention periods, log formats, or exploitation-window thresholds, and it is a proposal rather than a ratified standard.

Filling those gaps is where the real design work sits. Four decisions would do most of the load-bearing.

Retention
A defined floor for trace retention

A standard has to state how long execution traces survive, and in what fidelity. Without a floor, the answer to any future request is legitimately “we no longer hold it” — and there is currently no rule that makes that answer wrong.

Define retention before the incident
Attribution
Multi-party coordinated disclosure

When the model vendor, the scaffold author, the tool provider and the victim are four different organisations, someone has to be named as the coordinating party. The CSA proposal is the clearest articulation of this so far.

Name a coordinating party
Taxonomy
A real filing category for agentic failure

Prompt injection and delegated-authority abuse need native slots in the vulnerability taxonomy. Until they have them, agentic incidents get filed as something they are not, or not filed at all — and the industry loses the aggregate picture.

Fold the agentic taxonomy into filing
Access
Scoped investigator access, not a public dump

The peer-reviewed framework asks for material to be available to incident investigators on request. That is a far more achievable ask than full public release, and it survives the confidentiality and misuse objections that kill the maximalist version.

Scoped access beats full publication

The access question is where we would expect this to land. A full public trace release carries real objections — it is a capability document as much as a safety one, and publishing a working step-by-step account of a successful autonomous intrusion has obvious downside. A tiered model is more likely to survive contact with legal teams: full trace access for a defined set of investigators under agreement, a structured technical summary for the public, and a preserved record that a regulator can compel if it ever acquires the power to. That is not what is being asked for right now, but it is what a durable standard probably looks like.

07Incident ResponseA minimum viable agent incident-response plan.

None of the above helps you if an agent in your own stack does something you cannot explain. The practical payoff of the gap analysis is this: because no standard is going to arrive in time, the disclosure discipline has to be yours. Five phases, each of which you can put in place without waiting for anyone.

Phase 01
Detect
anomalous-action alerting

Alert on action classes rather than errors — first use of a credential, first outbound call to a new host, a tool-call volume that departs from the run’s own baseline. Agents fail quietly and successfully; error rates will not surface it.

Baseline per workflow, not per service
Phase 02
Contain
kill switch · isolation · revocation

Industry practitioner writing converging in 2026 describes four containment primitives — purpose binding, a kill switch, network isolation and credential revocation. Treat that as a useful checklist from practice, not a codified requirement.

Rehearse it; an untested kill switch is a hypothesis
Phase 03
Preserve
audit trail ≠ debug log

The moment containment starts, evidence starts aging out. Route the audit trail — run ID, model, prompt version, tool calls, retrieval IDs, approval decisions, policy checks — to a retention tier that outlives your operational logs.

Decide retention before you need it
Phase 04
Investigate
logs · docs · access · tools

Reconstruct against the three-factor model: system, contextual, cognitive. The AIES 2025 recommendation is a good contents list — activity logs, system documentation and access records, and what tools the agent had and used.

Name the causal factor, not just the symptom
Phase 05
Disclose
who, what, when — decided in advance

Write the disclosure posture while nothing is on fire: which counterparties get told, on what timeline, with what technical depth, and what you will hand to an investigator under agreement. Deciding this mid-incident produces the worst version of it.

A pre-agreed policy beats a good improvisation
The retention split that matters most
Practitioner guidance converging in 2026 recommends splitting agent telemetry across two retention tiers: treat audit events as evidence with long or indefinite retention, and rotate operational debug logs on a short cycle — commonly around 30 days. This is a common practitioner pattern rather than a regulatory requirement, but the logic holds regardless of who wrote it down: the cheap default of one undifferentiated log with one short rotation guarantees that the material an investigator needs is already gone.

Two of these phases have depth worth borrowing rather than reinventing. For the logging schema and what belongs in an evidentiary tier, our guide to audit-trail design for agents covers the field-level detail. For the runbook mechanics — severity levels, roles, comms templates — start from an incident-response playbook for agentic workflows. On the containment side, it is worth understanding sandbox escape patterns before you trust an isolation boundary, and a legislated kill-switch mandate is a live policy proposal that may eventually make phase two a compliance question rather than a design choice.

On adoption: the figures circulating in practitioner and vendor write-ups put the share of organisations with containment controls such as purpose binding and kill-switch capability in place at roughly 37 to 40 per cent. Treat that as directional only — it comes from trade coverage aggregating vendor guidance, not from an audited survey with a disclosed methodology or sample. The defensible version of the claim is the qualitative one: a clear minority of teams running agents in production can currently stop one on demand.

08ImplicationsWhat this changes for everyone else.

The pattern worth extracting from this episode is not about either company. It is that agentic incidents create an evidence asymmetry that no previous class of security event produced. In a conventional breach, the victim holds most of the forensic record: their logs, their systems, their timeline. In an agentic breach, the most explanatory evidence — why the agent chose the action it chose — sits with whoever operated the agent, who is frequently not the victim and is under no obligation to share it. Hugging Face can reconstruct what happened to its infrastructure. Only OpenAI can reconstruct what happened inside the model’s reasoning. That asymmetry is structural, it will recur, and every framework in our matrix is silent on it.

Our expectation for the next twelve months is that this gets solved contractually long before it gets solved by a standards body. Standards work moves in years; procurement moves in quarters. The likely path is that trace preservation and investigator access start appearing as clauses — in enterprise agreements with model vendors, in agent-platform terms, in cyber-insurance questionnaires that ask whether you can produce an agent’s action record after an event. Once an insurer prices it, it becomes real. A ratified public standard, if it arrives, will most likely codify what the contracts already say rather than lead them.

The practical read for teams deploying agents: assume you will be asked to explain an agent’s behaviour to a party who has no right to compel it, and build so the answer is available anyway. That means retention decided in advance, containment rehearsed rather than documented, and a disclosure posture agreed before it is needed. When we scope AI transformation engagements, governance and observability go in during the build rather than after the first surprise — and this incident is the cleanest argument for that sequencing anyone has produced yet. The same logic applies to the systems around the agent; our web development work treats agent-facing endpoints and their permission boundaries as first-class design surface rather than an afterthought.

09ConclusionThe standard does not exist yet.

Where this leaves everyone, July 2026

A request with no rulebook behind it is a preference, not a right.

Strip the personalities out and what remains is a governance vacuum with a specific shape. An agent acted, two organisations were involved, and the artefact that would explain the behaviour — the execution trace — is one that no framework in force has ever defined as disclosable. The frameworks that exist were built for bounded components with identifiable owners and version-specific patches. The registries that exist log incidents from news coverage. The one binding duty on the horizon arrives on August 2, 2026 and may not reach this scenario at all.

That is not an argument for waiting. It is an argument for treating disclosure discipline as an engineering property of your own systems rather than a compliance obligation handed down to you. Retention tiers, a rehearsed kill switch, an audit trail built as evidence, and a written disclosure posture are all available this week, and none of them depends on how the current dispute resolves. The teams that have them will be able to answer hard questions about their agents. The teams that do not will discover, at the worst possible moment, that the honest answer is that the record no longer exists.

The most likely outcome from here is quieter than the headlines suggest: a technical report, a set of contractual clauses that propagate through enterprise agreements, and a standard that eventually codifies what procurement already forced. The question of who owns the traces will get answered. It will just get answered by lawyers and insurers first, and by standards bodies some years later. Build as though the answer is already you.

Deploy agents you can actually account for

When an agent does something you cannot explain, the record has to already exist.

We build agent systems with governance, observability and containment designed in from the start — audit trails that hold up as evidence, rehearsed kill switches, and a disclosure posture agreed before you need it.

Free consultationExpert guidanceTailored solutions
What we work on

Agent governance engagements

  • Audit-trail and retention-tier design for agent workflows
  • Containment review — purpose binding, kill switch, isolation
  • Incident-response runbooks for autonomous systems
  • Permission and credential-scope audits for agent tooling
  • Disclosure posture and investigator-access policy
FAQ · Agent incident disclosure

The questions we get every week.

No. As of July 2026 there is no ratified standard governing what must be disclosed after an autonomous-agent incident. Coordinated vulnerability disclosure through CVE and NVD is operational but voluntary and was designed for bounded software components. The NIST AI Risk Management Framework, the OWASP LLM and agentic risk lists, and MITRE ATLAS are all published and useful, but they are risk-management processes and threat taxonomies rather than disclosure-content standards. The EU AI Act's Article 73 is the one mandatory incident-reporting duty on the horizon, and it takes effect on August 2, 2026. The Cloud Security Alliance published a proposed framework in April 2026, but it remains a proposal and does not specify retention periods, log formats, or exploitation-window thresholds. Across all of them, none requires an agent's execution trace or chain of thought to be released to anyone.
Related dispatches

Continue exploring agent governance.