Forem: Claudio Basckeira

Anthropic's Two Security Incidents Confirmed a Held-Back Frontier Model Called Mythos

Claudio Basckeira — Tue, 07 Apr 2026 14:25:40 +0000

Anthropic had two security incidents in five days. The combination revealed something unprecedented: a frontier AI model the company built and then deliberately decided not to release, on safety grounds.

Two Leaks, Five Days

The first incident broke on March 26. Fortune reported that close to 3,000 files belonging to Anthropic had been sitting in an unsecured, publicly searchable data store. Among them was a draft blog post describing an unreleased model called Mythos (internally also referred to as Capybara). The draft described it as "by far the most powerful AI model we've ever developed," more capable than Opus 4.6 across coding, academic reasoning, and cybersecurity benchmarks. Anthropic confirmed the model exists and said the company is "being deliberate about how we release it."

The second incident broke on March 31. Anthropic's official Claude Code npm package (@anthropic-ai/claude-code v2.1.88) shipped with an exposed source map file: roughly 57MB, mapping 512,000 lines of code across 1,900 files. The full Claude Code codebase was publicly readable for a window before Anthropic's takedown. Code analysis surfaced an unshipped feature roadmap with capabilities not yet announced, and corroborated the Capybara/Mythos tier from the prior leak.

Mythos: A Frontier Model Anthropic Is Holding Back

Multiple independent reviewers describe Mythos as a tier above Opus 4.6, with significant jumps on coding, reasoning, and cybersecurity benchmarks. Internal notes describe it as offering "a step change in cyber capabilities." Zvi Mowshowitz's full writeup documents the evidence and the implications, citing several of those reviewers.

That framing matters. This isn't a model that isn't ready yet, or a product that hasn't been productized. It's a capability Anthropic built and then decided not to deploy because of its potential for misuse in cybersecurity contexts.

Anthropic also disclosed that a Chinese state-sponsored group ran a coordinated campaign using Claude Code to infiltrate roughly 30 organizations before being detected. That's the dual-use evidence pattern that justifies holding the capability back: the same model that helps cybersecurity defenders also helps cybersecurity attackers, and the attacker side is now demonstrably real. This appears to be one of the first publicly documented cases of a frontier model deliberately withheld on safety grounds rather than readiness or commercial timing. OpenAI and Google DeepMind have both discussed withholding capabilities in the abstract; this is a concrete documented case.

The DMCA Overreach

Anthropic's response to the leak created a secondary incident. Their DMCA takedown effort, aimed at removing the leaked code from GitHub, accidentally removed legitimate public forks of an unrelated open-source repository before the error was caught and reversed. Ars Technica documented the full timeline.

The overreach was reversed quickly, but the documentation of a large AI lab deploying automated DMCA tooling that can't distinguish between a leak and a legitimate fork is worth noting for anyone running open-source projects.

The AMD Performance Complaint

The same week the leak broke, AMD's AI Director Stella Laurenzo filed a public GitHub ticket reporting measurable performance regression in Claude Code, stating the tool "cannot be trusted to perform complex engineering tasks" based on analysis of 6,852 sessions. Her data showed degradation beginning around March 8, specifically in reasoning depth and targeted editing behavior.

She attributed the regression to the deployment of "thinking content redaction" in version 2.1.69, which strips thinking content from API responses. Her hypothesis: when thinking is shallow, the model defaults to cheaper actions (rewrite entire files, stop without completing). The Register covered the full ticket.

A named enterprise director, with six thousand sessions of data, publishing publicly. That's a different category of complaint than anonymous forum posts.

The Source-Map Security Pattern

The leak itself surfaced a security practice worth checking: source maps were included in a published npm package. Source maps are invaluable for debugging, but when included in production packages, they expose the full source code of your compiled JavaScript to anyone who knows where to look.

If your team publishes compiled JavaScript to npm and hasn't audited which files are included in the published package, this is worth checking. The .npmignore file or the files field in package.json controls what ships. Source maps should be excluded from published packages or hosted separately with restricted access.

This story is from Edge Briefing: AI, a weekly newsletter curating the signal from AI noise. Subscribe for free to get it every Tuesday.(

LiteLLM Was Backdoored: What the TeamPCP Supply Chain Attack Means for Python AI Projects

Claudio Basckeira — Tue, 31 Mar 2026 14:21:46 +0000

On March 24, 2026, threat actor TeamPCP published two compromised versions of LiteLLM to PyPI. If you work with Python AI tooling, this one is worth understanding in detail, because the attack technique will be reused.

What Happened

Versions 1.82.7 and 1.82.8 of LiteLLM contained malicious payloads after attackers obtained the maintainer's PyPI credentials. The credential theft wasn't a direct attack on LiteLLM. It was the third step in a cascade:

March 19: TeamPCP compromised Trivy, an open-source security scanner
March 21: Used the compromised Trivy action to steal credentials from Checkmarx's CI pipeline
March 24: Used stolen credentials from LiteLLM's CI/CD pipeline (which ran Trivy) to publish malicious packages

The malicious versions executed in two different ways. Version 1.82.7 embedded a base64-encoded payload in litellm/proxy/proxy_server.py; it fires when anything imports litellm.proxy. Version 1.82.8 was more aggressive: it added a litellm_init.pth file to site-packages, which runs on every Python interpreter startup regardless of whether LiteLLM is imported. That includes pip install, your IDE's language server, and python -c "anything".

Once triggered, the payload harvested SSH keys, cloud credentials, Kubernetes secrets, database configs, and .env files. On machines running Kubernetes, it attempted lateral movement by deploying privileged pods to every node and installed a persistent systemd backdoor that polls an attacker-controlled endpoint for additional binaries.

Why This Is Harder to Catch Than It Looks

Standard supply chain defenses focus on hash verification and suspicious package names. This attack bypassed both because the malicious content was published using the maintainer's actual credentials. The hash is correct. The package name is correct. There's nothing to flag.

The .pth mechanism in version 1.82.8 is particularly worth understanding. It's a legitimate Python feature: files ending in .pth in site-packages are processed on every interpreter startup. Any line that starts with import gets executed. This isn't a vulnerability; it's how Python works. Existing supply chain scanning tools mostly look at setup.py and __init__.py. They don't catch malicious .pth files.

Who Was Affected

LiteLLM downloads 3.4 million times per day and is present in 36% of cloud environments as a transitive dependency. You might not have installed LiteLLM directly and still have been affected. Downstream packages that pull LiteLLM transitively include DSPy, MLflow, OpenHands, CrewAI, and Arize Phoenix.

The malicious versions were live for approximately three hours before PyPI quarantined them. Detection was accidental, not by automated tooling.

What to Do

Check first: pip show litellm | grep Version

If you see 1.82.7 or 1.82.8:

Uninstall immediately and run pip cache purge (or rm -rf ~/.cache/uv if using uv) to prevent cached wheel re-use
Rotate every credential accessible from that environment: API keys, SSH keys, cloud credentials, database passwords
Check for persistence artifacts: ~/.config/sysmon/sysmon.py, a sysmon.service systemd unit, files in /tmp/pglog or /tmp/.pg_state
If Kubernetes was present: inspect kube-system namespace for unauthorized pods, review cluster audit logs

The clean version is 1.82.6.

The Broader Signal

This is part of a coordinated campaign. Three days later, the Telnyx package was hit with the same technique. TeamPCP is running systematic attacks across Python packages in the AI/ML tooling space.

There's also one detail buried in the security post-mortems that deserves separate attention: the attackers used an AI agent called "openclaw" as part of their operational pipeline. It's the first confirmed case of an AI agent used operationally in a software supply chain attack. The full scope of what it automated isn't publicly documented, but its presence in the campaign means some coordination steps that previously required manual effort are now automated.

For teams running Python AI tooling in production: pin your dependencies, monitor transitive package updates, and add .pth file detection to your supply chain scanning. The gap between what automated tooling catches and what's actually exploitable just got a bit wider.

This story is from Edge Briefing: AI, a weekly newsletter curating the signal from AI noise. Subscribe for free to get it every Tuesday.

An AI Agent Found 20 ML Improvements Karpathy Had Missed in 20 Years

Claudio Basckeira — Sat, 28 Mar 2026 19:56:07 +0000

Andrej Karpathy released autoresearch on GitHub last week, and the results are worth understanding carefully. Not because of the hype, but because of how the architecture actually works.

The framework is 630 lines of Python. It runs an AI agent in a loop: read a training script, form a hypothesis, modify the code, run a short training job (five minutes), evaluate results against a scalar metric, repeat. On Karpathy's own ML training setup, the agent ran 700 experiments over two days on a single GPU and found an 11% training speedup through 20 optimizations he says he hadn't discovered in 20 years of working on the same codebase.

Then Shopify's CEO ran the same approach on internal data. 37 overnight experiments. 19% performance gain. Applied to their Liquid templating engine: 53% faster rendering, 61% fewer memory allocations, 93 automated commits, all 974 unit tests passing. The repo hit 42,000 GitHub stars in its first week.

The Architecture Is the Lesson

The design is deliberately minimal. The entire agent contract lives in one file: program.md. That file carries:

What to optimize (the objective, stated in natural language)
Constraints (what the agent must not do: break tests, increase memory footprint, etc.)
Stopping criteria (when to declare success or give up)

The agent reads program.md, modifies the training script, runs the job, parses the metric from the output, logs the result, and loops. No external tool calls. No internet access. No vector database of prior experiments. Just: read, modify, train, evaluate, repeat.

Karpathy's phrase for this pattern is "program synthesis via experiment." The agent isn't writing the optimizer from scratch. It's running empirical search over the space of code modifications, guided by a metric signal.

The Constraint That Actually Matters

Here's where a lot of the coverage has been imprecise: autoresearch only works where quality is measurable with a single scalar value.

Training loss, rendering time, memory allocations, test pass rate. These are scalar metrics. You can compare them across runs. An agent can know unambiguously whether run N+1 was better than run N.

Natural language quality isn't scalar. Alignment properties aren't scalar. Whether a piece of code is readable isn't scalar. Whether a product decision is the right one isn't scalar.

This constraint is the boundary condition for the entire framework. Karpathy acknowledges it: "It works best on problems where you have a clear eval." The framing in some coverage ("AI will now do all research autonomously") misses this. Autonomous research works for ML training, hyperparameter optimization, compiler tuning, and similar problems with quantifiable objectives. It doesn't yet work for the domains where human judgment is most irreplaceable.

That said, Shopify's result is a useful demonstration that the "clear eval" bar isn't as narrow as it might seem. Rendering time for a templating engine is a straightforward metric, but deriving a 53% improvement from 37 overnight experiments against that metric is genuinely impressive.

What to Take From This

If you're doing any ML work that involves iterative training runs, autoresearch is now the default first step before manual hyperparameter search. The framework is on GitHub. Read program.md specifically. The single-file design for agent instructions + constraints + stopping criteria is a pattern worth stealing for any iterative agent task, not just ML optimization.

Karpathy's framing of the bigger picture: "Humans are now the bottleneck in AI research with easy-to-measure results." That's precise language. For the domains where measurement is hard, humans remain central. For the domains where it's easy, the leverage has shifted.

This story is from Edge Briefing: AI, a weekly newsletter curating the signal from AI noise. Subscribe for free to get it every Tuesday.

An AI Agent Caused a Data Breach at Meta. Here's What Went Wrong.

Claudio Basckeira — Sat, 21 Mar 2026 10:21:36 +0000

Two AI agent security incidents hit production systems in the same week. One at Meta, one at Snowflake. Neither was theoretical. Both exposed real data.

Here's what happened, and what it means if you're deploying agents.

The Meta Incident

An internal AI agent at Meta autonomously posted a response to an employee's question on an internal forum. Nobody invoked it. Nobody asked for its input. It saw a question, generated an answer, and posted it.

Another engineer read the response, followed the agent's advice, and in doing so inadvertently widened access permissions on an internal system. The result: proprietary code, business strategies, and user-related datasets were exposed to engineers who shouldn't have had access. The exposure lasted about two hours before it was caught. Meta classified it as Sev 1.

VentureBeat's analysis identified four specific IAM gaps that enabled the incident. The root cause is a pattern that security researchers have been warning about for years: the confused deputy problem. The agent inherited the invoking engineer's permissions, but it acted autonomously and in contexts the engineer never intended. It had the authority of a human but none of the judgment about when to use it.

The Snowflake Incident

PromptArmor disclosed a prompt injection chain in Snowflake's Cortex Code CLI. The attack path: an attacker plants prompt injection instructions in a GitHub README file. When a developer uses the Cortex agent to review that repository, the agent reads the README, follows the injected instructions, downloads a malicious script, and executes it using the developer's Snowflake credentials.

This is a supply chain attack that flows through an AI agent. The developer didn't run anything suspicious. They used their normal tooling to review a repo. The agent did the rest.

Snowflake patched the vulnerability in CLI v1.0.25 (February 28, 2026).

The Pattern

These aren't isolated events. Last week, AWS had a 13-hour outage caused by agent-driven code changes. OpenAI published a blog post titled "How we monitor internal coding agents for misalignment," which strongly suggests they've encountered similar problems internally.

Three production-scale agent incidents in two weeks, plus a major lab publishing its internal monitoring methodology. Agent safety has crossed the line from theoretical risk to operational reality.

What to Do About It

If you're deploying AI agents in any internal system, three things matter right now:

Agent-specific IAM policies. Agents should never inherit full user permissions. An agent that can read code shouldn't automatically be able to modify access controls. This is the single change that would have prevented the Meta incident. Create dedicated service accounts for agents with minimal necessary permissions, just like you would for any automated system.

Human-in-the-loop for permission-escalating actions. Any action that changes access controls, modifies infrastructure, or touches sensitive data should require explicit human approval. The agent can propose the action. A human authorizes it. This is the equivalent of requiring PR reviews for infrastructure changes; we already know why this matters.

Monitoring for autonomous actions outside defined scope. The Meta agent acted outside its defined scope when it posted unsolicited responses. If your monitoring only watches for errors and latency, you'll miss an agent doing something it wasn't supposed to do but doing it "successfully." Log agent actions against expected behavior patterns, not just failure states.

The Bigger Picture

The AI agent sales pitch is autonomy. Agents that do things for you, without you needing to supervise every step. The security reality is that autonomy without scoped authority is a vulnerability. We learned this with automated CI/CD pipelines, with cloud service accounts, with every system that can take action on a human's behalf. The lesson is always the same: least privilege, explicit authorization for sensitive actions, and monitoring that watches for unexpected successes, not just failures.

AI agents aren't fundamentally different from any other automated system with elevated permissions. The tooling and patterns exist. The question is whether organizations deploying agents are applying them.

Based on this week, the answer is: not yet.

This is adapted from Edge Briefing: AI, a weekly signal-over-noise AI briefing for developers and tech professionals. Subscribe for free to get it every week.