What leaked from the AI agent harness, and what did not

On March 31, 2026, a Claude Code update shipped a debugging artifact that pointed to private client source. In September, a repository study found permission and dependency declarations worth reviewing in hundreds of coding-agent setups. In October, investigators read an alleged attacker's own AI-agent sessions from open server directories. All three involve the software surrounding language models, but they crossed different boundaries and establish very different consequences.

The first exposed publisher-controlled code, the second measured potential execution authority in repository configuration, and the third exposed operator-controlled session records. None establishes theft of Claude model weights. The configuration survey does not document a breach, while the attacker-log incident does not establish that the model autonomously compromised every reported target. Treating them as one growing tally of AI harness hacks would lose precisely the facts that make each useful.

A coding agent depends on more than its model. A publisher builds and distributes a client; a workspace supplies context files, dependency declarations and permissions; an operator runs the client and accumulates logs, memory and tool outputs. The Claude Code product record describes the application, while the three linked Cases document different ways its surrounding software and runtime state can be exposed or misconfigured.

These are different assets with different custodians. A release artifact can reveal program design, a configuration can influence what the program is allowed to run, and a session record can reveal what its operator requested or attempted. Exposing one does not automatically expose the others.

On March 31, Axios reported that an ordinary Claude Code update included a debugging file that referenced a ZIP archive hosted by Anthropic. The archive was described as containing nearly 2,000 source files and roughly 500,000 lines of client code. Security researcher Chaofan Shou was credited with surfacing the issue, and an early Reddit discussion spread the originating X link. Neither the package nor the archive was independently downloaded for this dossier, so the file count remains attributed reporting.

Anthropic acknowledged a human packaging mistake and stated that sensitive customer data and credentials were not exposed. The distinction matters. Proprietary source is valuable to reverse engineers and competitors; seeing it does not prove that production model weights, customer sessions or API keys left their own boundaries. It also does not mean a debugger file by itself granted an attacker the ability to call privileged tools.

The subsequent cleanup produced a second measurable event, with a different denominator. TechCrunch reported that network-wide GitHub removal processing affected roughly 8,100 repositories. In its April 1 partial retraction, Anthropic asked GitHub to reinstate the rest while retaining the notice for one identified mirror and 96 specified forks. Those numbers describe copyright-enforcement reach, not compromised customers or separate security breaches. Removing mirrors does not prove that downloaded copies ceased to exist.

A fitting prevention check is therefore at the publication boundary: inspect the actual package being shipped, including source maps and links or references to private archives. That check addresses unintended distribution. It would not, by itself, solve excessive agent permissions or a later operator's exposed local history. The lasting evidence is retained in the Claude Code source-map Case.

A September 25 corrected study led by Benjamin Kapner inspected 3,171 public GitHub repositories containing coding-agent harness components. Its main denominator was 2,660 assembled setups; another 511 repositories were reusable skill collections. The researchers found 409 setups, or 15.4% of that assembled group, with at least one selected security-relevant declaration. The conditions overlapped: 260 setups had unpinned MCP package declarations, 67 had broad execution grants, and 101 had broad skill tool preapprovals. The separate 24.5% unpinned rate applies only to the 1,063 setups with MCP declarations, not to every repository sampled.

A declaration can matter because a server reference may select executable code when an MCP dependency is resolved, and a grant may let a client run more commands without asking again. But the study inspected configuration rather than recording attacks. It did not measure which packages actually ran, how client-specific trust prompts applied, whether other rules overrode an allow entry, or whether attackers controlled the referenced dependencies. Its sample was selected from discoverable public repositories, not drawn randomly from all deployed agents. Accordingly, 15.4% is a finding rate within that corpus, not a compromise rate across the industry.

The correction is as revealing as the count. The study removed 62 findings after discovering that wildcard find rules had been misread as permitting operations that Claude Code does not preapprove under those patterns. Two checking implementations had agreed because they shared the same mistaken understanding of the client's behavior. Anthropic's permission documentation specifies deny, ask and allow rule precedence and a workspace-trust condition for project-level allow grants in interactive sessions. A scanner that reads a file without modeling the applicable client and policy cannot claim the effective authority of a running agent.

Pinning intended package versions or image digests makes one dependency-selection decision reviewable; narrowing approval patterns limits tasks that can proceed without another prompt. Neither measure proves that transitive code is clean or that a running agent is isolated from sensitive files. The harness-configuration Case preserves the corrected measurement and its limits. The central distinction is between a potentially risky configuration and a demonstrated unauthorized action.

In October, the observable weakness was not a distributed client package or a GitHub configuration survey. CrowdStrike's October 7 investigation connected an ARTEX penetration-testing instance with another server holding open directories of Claude Code histories, ARTEX files, memory and a CLAUDE.md instruction document. CrowdStrike attributed both machines to an unidentified operator associated with late September and early October data-exfiltration activity targeting South Korean finance organizations. Its observations concern the operator's infrastructure, not Anthropic losing the histories of its customers.

The recovered records gave investigators a partial picture of a mixed workflow. CrowdStrike described an ARTEX backend using DeepSeek and additional Claude Code sessions involving other models; it also observed requests for advice about where Korean breach data might be sold. A question asked of an assistant is evidence of an operator's request, not evidence that a recommended marketplace was used. Similarly, the presence of a session file is not proof that every command proposed by a model was executed against a victim. A full attribution would require corresponding tool execution records, target-side telemetry and a verified exfiltration trail.

The reported banking scope needs equal restraint. Reuters' October 9 coverage described at least nine banks as disclosed or reported targets, whereas CrowdStrike did not confirm how many organizations were successfully compromised. Neither source establishes nine completed intrusions or a defensible dollar-loss total. Reuters also reported the developer's decision to halt public ARTEX distribution and maintenance; stopping releases does not recall already installed copies or remediate the banks' systems. The detailed ARTEX Case keeps human requests, model use, observed infrastructure and incident impact in separate evidentiary categories.

Protecting this boundary means restricting access to the directories and archives where histories, tool outputs, tokens and context accumulate, not merely hiding the model endpoint. Access controls and removal of public directory listings would change the prerequisite that enabled outsiders to read the operator's traces. They would not prevent the operator from conducting attacks with other tools, nor would they establish which outputs were already viewed or copied.

The three headline counts sound comparable only if their units are discarded. Roughly 500,000 lines describes reported source-code volume. The 409 of 2,660 setups describes selected configuration declarations within one study. The nine banks in Reuters' account describes reported targets, not necessarily successful victim compromises. The roughly 8,100 GitHub repositories describes takedown processing rather than a security population. None is a denominator for the others, and none supplies a confirmed monetary-loss estimate.

For a useful incident record, three follow-up questions correspond to three independent evidentiary needs. With a public release, ask which exact build artifact was published and what private reference it made accessible. With an agent configuration, ask which executable dependency was resolved and what permissions actually applied in the relevant client and workspace. With exposed operator sessions, ask who could read the files and whether model suggestions can be matched to executed commands and observed consequences. The answer for one cannot be borrowed from another.

The resulting defensive sequence is concrete: review package outputs at release, resolve and inspect effective authority before agent execution, and secure the histories and credentials produced during operation. These controls address distinct exposure prerequisites; none substitutes for the other two. It is possible to understand an AI model's behavior while missing all three, because the underlying boundaries belong to the software and people around that model.