Evaluation-Incident Control Matrix

Evidence discipline

This matrix keeps the disclosures separate. They describe overlapping subject matter but differ on material points, including initial access and actor attribution. No account should be treated as a complete, independently verified incident chronology while investigations remain open.

• OpenAI disclosure: OpenAI and Hugging Face partner to address security incident during model evaluation, originally fetched July 22, 2026; re-verified July 31, 2026. The current disclosure includes updates dated July 28 and July 29. It confirms the Artifactory zero-day, four externally exposed accounts, additional public services used by the models, and ongoing third-party reviews, and it discusses containment, monitoring, access controls, and evaluation practices.
• Hugging Face disclosure: Security incident disclosure — July 2026, fetched July 22, 2026; re-verified July 31, 2026.
• Anthropic disclosure: Investigating three real-world incidents in our cybersecurity evaluations, published July 30, 2026; fetched July 31, 2026.
• Harness reference: every test identifier below is defined in the public repository msaleme/red-team-blue-team-agent-fabric, in protocol_tests/identity_harness.py, protocol_tests/multi_agent_harness.py, protocol_tests/incident_response_harness.py, protocol_tests/aiuc1_compliance_harness.py, and docs/AUDIT-R33-INDEPENDENT-REVIEW.md. Identifiers were extracted April 19, 2026 and re-verified against those public modules July 31, 2026; a reader can resolve each one there.

Evidence classes used in this document

These terms are not interchangeable, and the harness mapping below claims only the first:

What each source reports

Related operational-control evidence

Anthropic's July 30 disclosure is a separate incident set, not corroboration of the OpenAI/Hugging Face mechanism. It is tabled apart so it cannot be read as a third column of the same event.

Control interpretation

The incidents, as publicly described, do not establish that an intrinsically “rogue” model was involved. They are evidence that a constrained evaluation can become unsafe when objective, accessible capabilities, and infrastructure escape paths combine into an unauthorized route. An architectural interpretation of the reported failures is insufficiently bounded agency across connected control planes. That is an interpretation offered here, not a root-cause finding; the investigations remain preliminary.

An agent may be authorized to run an evaluation, install dependencies through a proxy, invoke specified tools, or use a scoped workload identity. The security question is whether those legitimate starting capabilities can be composed with vulnerabilities or exposed credentials into a path that crosses the intended boundary. Exploiting a proxy, harvesting credentials, and reusing them laterally were not authorized merely because the starting capability was available.

Mapping to existing harness coverage

Coverage below is cataloged only. The public protocol_tests/ modules establish that these tests are defined under these identifiers. That does not establish that they were executed, which harness version or commit ran, when, or with what result. Do not upgrade any cell to “verified” without a version or commit, an execution date, a result artifact, and a pass/fail status.

Explicit gap backlog

Do not describe these as existing tests or assign public test identifiers until implemented, reviewed, and cataloged.

1. Evaluation-environment egress integrity — confirm that an evaluation workload cannot reach an unapproved destination even after a package-proxy or dependency boundary fails.
2. Workload-identity segmentation — verify that credentials issued in an evaluation environment cannot authenticate to production data, control-plane, or cluster services.
3. Tool-and-network path composition — test whether individually permitted package, tool, proxy, and identity operations compose into an unapproved route.
4. Runtime dataset execution isolation — test policy enforcement around remote-code loaders and templating paths in an authorized, instrumented target.
5. Cross-plane containment drill — verify revocation, egress disablement, workload quarantine, and forensic logging together after a simulated boundary breach.
6. Evaluation objective guardrails — require explicit, machine-enforceable stop conditions when the benchmark objective is reachable only through undeclared systems or data.

Several of items 1 through 5 can be exercised first in simulation. Production-representative conclusions require an authorized, instrumented environment, and simulation-only results must be labeled accordingly.

July 31 operational-control addition

Anthropic's July 30 disclosure reinforces backlog items 1 and 3, the scope-boundary rationale for item 6, and the monitoring component of item 5, without changing their evidence class. It recommends clearer scope boundaries but does not prescribe machine-enforceable stop conditions, so item 6's enforcement design remains a proposal here rather than something the disclosure supports. Its reported corrective themes are concrete evaluation-environment controls: validate every internet-access path before runs, continuously monitor evaluation logs and transcripts, define explicit scope boundaries, and apply vendor assurance to third-party evaluation infrastructure. It does not directly support the full combined revocation, egress-disablement, and quarantine drill in item 5, nor item 2 or item 4.

The report does not evaluate this harness, establish that a particular control would have prevented the incidents, or supply a general model-behavior conclusion. It is retained as external rationale for a future authorized evaluation-environment egress and scope-boundary test, not as harness validation.

Recommended external framing

Core claim:

A malicious objective is not required for an agent to cause harm. The control problem is whether an authorized objective can compose an unauthorized path to a critical asset.

This states what the evidence supports. It does not dismiss alignment or malicious-objective risk; it establishes that a malicious objective was not necessary to explain the behavior described by OpenAI and Anthropic. Hugging Face's independent account did not identify the underlying model and described the activity as an attacker campaign, so it is not cited in support of this claim.

Use: “bounded agency,” “attack-path verification,” “purpose-bound authorization,” and “defense in depth.”

Avoid: “rogue AI,” claims that this was definitively the first incident of its kind, claims that the harness would have prevented the incident, or a single merged technical narrative while the investigation remains open.

Evidence-led enterprise bridge

Exposure is concentrated in paths joining exploitable weaknesses, identities, connectivity, and high-value assets. In an agentic environment, an attack path may be composed at runtime: a model, credential, tool, proxy, and destination may each appear individually permitted, reachable, or valid to a local control, while their combination creates an unauthorized route.

That is the rationale for a verification layer: test whether those boundaries remain binding under adversarial, adaptive behavior. It is not a substitute for patching, sandboxing, workload security, identity hygiene, or network egress controls.

Provenance and limits of this document

A document about evidence discipline should state its own limits.

• Every harness identifier cited above is defined in the public repository linked under Evidence discipline. A reader can resolve each one without privileged access.
• That coverage is cataloged, not executed. No cell in the mapping table asserts that a test ran, when it ran, or what it returned.
• One attribution was removed before publication. An earlier draft credited the attack-path concentration argument to a named source that could not be resolved in any public or internal location. It was removed rather than reworded, and the claim now stands directly. An argument that cannot survive losing its citation was not resting on that citation in the first place.

About This Series

Cite the Position Paper

@misc{saleme2026eaa,
  author    = {Saleme, Michael K.},
  title     = {Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21105314},
  url       = {https://doi.org/10.5281/zenodo.21105314}
}