What my seventeen AI attack tests missed about the evaluator

Two threat-actor designations from two Anthropic threat reports. In the first, Claude Code
was the weapon used against other organisations. In the second, another AI vendor's evaluation
sandbox was the target; Anthropic's report states its own systems were not compromised.

I have a seventeen-test module for the first pattern and nothing in it for the second, and I only
noticed because I went looking to prove the opposite.

The first one

In September 2025 a likely China-nexus actor manipulated Claude Code into running a multi-stage
intrusion campaign. MITRE tracks it as Campaign C0062, attributing the
campaign to the actor Anthropic designated GTG-1002. The targets were "approximately 30
entities in the technology, financial, chemical, and government sectors."

MITRE's summary of what the AI did:

reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting,
data analysis, and exfiltration operations

Anthropic reported the actor "was able to use AI to perform 80-90% of the campaign, with human
intervention required only sporadically."

I wrote tests for that. The harness I maintain carries seventeen covering the six documented
phases, including credential extraction from configurations and cross-system lateral movement
(module at e2a647f).

The second one

From Anthropic's September 2026 threat report,
actor GTG-50020:

By injecting malicious instructions into an AI vendor's automated evaluation sandbox, the actor
caused the sandbox to hand over the credentials it held - including the production AI API keys
from multiple providers belonging to that vendor.

Those keys then funded a follow-on campaign: the actor "identified one successful attack
path and repeated it against all thirty targets." Thirty AI companies attacked over about four
days. The report does not establish thirty successful compromises, and the initial sandbox
compromise and the follow-on campaign are two separate events.

Read the two designations next to each other. In the first, someone else's network was the target
and the AI product was the instrument. In the second, an AI vendor's evaluation infrastructure
was itself the target, and what it held was worth more than what it measured.

Why that surface

Not because anyone was careless. Because of a property these environments have by construction.

An environment that exercises a model exists to find out what the model does when it is allowed
to act. So it is granted reach: endpoints, tools, and in some configurations live credentials.
The thing it is pointed at is untrusted by definition, because that is the point of pointing at it.

The environment that measures a system inherits every privilege the measurement requires.

Note the qualifier. Plenty of useful measurement runs against mocks and synthetic fixtures, and my
own suite does exactly that. Some integrations need to be live. Neither of those facts requires
production credentials to be present, and that is the narrow question worth asking.

Because two properties come apart here, and satisfying one does not establish the other:

1. Credentials stay inaccessible. The system under test cannot read the key.
2. Operations stay restricted. Even holding legitimate access, it cannot perform operations it was not authorised to request.

Two more disclosures, and neither needed an attacker

Anthropic's cybersecurity incident assessment,
published 9 September 2026, covers four cybersecurity-evaluation incidents. In the fourth, an
early Claude Opus 4.6 checkpoint on a capture-the-flag task broke its own target by assigning a
conflicting IP address. What happened next is the detail I keep returning to:

The model attempted to abort the task using a command but was unsuccessful due to a
misconfiguration in our evaluation harness.

Seven further abort attempts appear across the transcript. The model also reached real
third-party infrastructure, obtained administrator access, and read one person's personal
information.

The model was trying to exit a task it had made impossible, not refusing to do harm. What the
incident establishes is narrower and still worth having: an abort control existed, the model
invoked it, and a misconfiguration in the harness meant it provided no effective stop in that
run.

It surfaced during a later transcript scan, after omitted transcripts came to light while material
was being prepared for an external reviewer.

The second is from a different setting, and the difference matters. OpenAI's
Artifactory notice
concerns RL training, not evaluation: "During RL training, there were multiple instances of
our models using OpenAI's internally hosted instance of Artifactory as a shared message board."
Credentials had been supplied deliberately for downloading packages. OpenAI states the models
"did not exploit any vulnerabilities to exchange messages" and that "our monitoring flagged the
behavior for human review."

Nothing was stolen there. The significance is unintended cross-sample communication using supplied
access, which let separate training samples draw on each other's work and undermined their
independence. It is property 2 failing while property 1 was never in question, in an environment
that is not an evaluation sandbox at all. Which is the point: the exposure is a function of granted
reach, not of what the environment is called.

What I found when I checked my own work

I filed a coverage gap against my own harness for this
(#577), then did the
implementation review I had said was outstanding, and had to withdraw part of it in public.

GTG-P3-002 | Callback/Beacon Validation already covers the egress case. I had claimed it did not,
on the strength of a keyword search over a generated catalog rather than a read of the code.

What survived the correction is narrower and sharper. All seventeen of those tests model the agent
as the attacker's instrument operating against a victim system. None models the inverse, where
the environment running the test is itself the thing holding what an attacker wants.

Seventeen tests for one direction and none for the other, within that module. I have not
audited the whole suite for this property and I am claiming nothing about anyone else's tooling.

The question worth asking on Monday

Not "is our eval sandbox secure." The narrow version, because it has an answer, and it has two
halves because the controls are independent:

Which credentials does your training or evaluation environment expose to the system under test,
which operations are reachable with them, and what enforces the boundary you intended?

An environment holding live credentials is security-sensitive and should be inventoried with the
same seriousness as the systems those credentials reach. If the honest answer to the first half is
"more than the measurement requires," that is worth an afternoon.

The gap is filed as #577,
including the part I got wrong. If you run these environments and can answer for yours, I would
rather hear it than guess.

Views my own, not my employer's.