Forem: Claudio Basckeira

Four Frontier AI Models Shipped in One Week. Here's What Each One Means for Developers.

Claudio Basckeira — Tue, 28 Apr 2026 13:28:04 +0000

The week of April 21-28, 2026 saw an unusual concentration of frontier-class model releases: GPT-5.5, DeepSeek V4, Xiaomi's MiMo V2.5-Pro, and Alibaba's Qwen3.6-27B all shipped within the same seven days. Two of those are open-weight and freely downloadable. Here's the practical breakdown.

GPT-5.5 (OpenAI, April 23)

Available now in ChatGPT paid plans and Codex, with API rollout staged behind a safety review. Priced at $5/$30 per million tokens (up from $2.50/$15 for GPT-5.4, though OpenAI argues the effective cost increase is roughly 20% because GPT-5.5 uses fewer output tokens per task).

Simon Willison's hands-on described it as "a fast, effective and highly capable model." Artificial Analysis independently rated it the top model globally on intelligence-per-dollar. On Terminal-Bench 2.0, GPT-5.5 scores 82.7% versus Claude Opus 4.7's 69.4%.

The benchmark gap to notice: OpenAI omitted coding comparisons against Anthropic in the release materials. Latent Space noted this isn't an oversight - it's signal about where GPT-5.5's relative weaknesses are. Practitioner consensus (Zvi): GPT-5.5 for factual and web tasks, Opus 4.7 for open-ended and interpretive work.

The API premium request multiplier on GitHub Copilot is 7.5x, which means heavy agentic use with GPT-5.5 on a Business plan can exhaust $19/month in a few hours.

DeepSeek V4 (April 24)

Two variants: V4-Pro (1.6T total / 49B active parameters, MIT license) and V4-Flash (284B/13B). Both support 1M token context. Trained on 32T tokens using FP4 precision. Huawei Ascend chip compatibility is included, which matters for China-based deployments but also signals DeepSeek's compute sovereignty strategy.

Community practitioners on r/LocalLLaMA favor Kimi K2.6 (released last month) over V4-Pro for coding specifically. DeepSeek V4 support is already in vLLM v0.20.0 if you're running self-hosted inference. Simon Willison: "almost on the frontier, a fraction of the price."

Qwen3.6-27B (Alibaba, April 22)

This is the efficiency story of the week. Qwen3.6-27B is a dense 27B model (55.6GB) that Alibaba claims surpasses the previous Qwen3.5-397B-A17B (an 807GB MoE) across major coding benchmarks. Simon Willison tested the quantized version and confirmed it works. Community results show 38.2% on Terminal-Bench 2.0.

That's a 14x efficiency gain in one release cycle. If you're constrained by VRAM or want to run a capable model locally on consumer hardware, Qwen3.6-27B is the practical pick this week.

MiMo V2.5-Pro (Xiaomi, April 24)

A 1.02T total / 42B active parameter MoE model, MIT-licensed, 1M context window. The reported benchmark numbers are strong: GPQA-Diamond 66.7 (within 3 points of Opus 4.7), SWE-Bench Pro 57.2 (above Opus 4.6's 53.4, within 0.5 of GPT-5.4 per Artificial Analysis). Long-context reasoning is notably improved over the prior MiMo version.

Xiaomi is a phone manufacturer. That's not background noise - it's context. A company that ships inference hardware at consumer scale and publishes competitive frontier model research should be on your radar.

What This Means for Model Selection

The open/closed model frontier gap has formally closed for several capability classes. The remaining differentiator for paid frontier models is trust infrastructure (safety evaluations, vendor support, enterprise SLAs) and workflow integration (Codex superapp, Claude Code IDE, GitHub Copilot).

For developers making practical choices right now:

Coding tasks: Kimi K2.6 remains the community-preferred open-weight leader; MiMo V2.5-Pro may displace it on reasoning-heavy coding; Qwen3.6-27B if VRAM is the constraint.
Factual/web tasks: GPT-5.5 per practitioner consensus.
Open-ended/interpretive work: Claude Opus 4.7 per practitioner consensus.
Cost-sensitive inference at scale: DeepSeek V4-Pro as a self-hosted frontier alternative.

One grounding data point before you cancel any subscriptions: a practitioner on r/LocalLLaMA who spent weeks trying to fully substitute local models for Claude Code in real production work reported failure. Benchmark parity and production parity are not the same thing. Hardware requirements, latency, and hosting complexity create real gaps that benchmarks don't surface. Test on your actual workloads.

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

Anthropic's MCP Has a Design Flaw It Won't Fix. Here's What Developers Need to Do Now.

Claudio Basckeira — Tue, 21 Apr 2026 13:07:31 +0000

Security firm OX Security spent months working through 30+ responsible disclosure processes before publishing their findings this week: Anthropic's Model Context Protocol has a fundamental architectural vulnerability, and Anthropic has decided not to fix the root cause.

What the flaw is

The vulnerability lives in MCP's STDIO interface, the mechanism MCP uses for local transport when an AI process spawns an MCP server as a subprocess. This interface allows malicious tool descriptions to trigger arbitrary command execution on any system running a vulnerable MCP implementation.

It's not a coding mistake in one library. It's baked into Anthropic's official MCP SDKs: OX explicitly documented the flaw in the Python, TypeScript, Java, and Rust SDKs.

OX documented 10 CVEs across major downstream projects: LiteLLM, LangChain, LangFlow, Flowise, Windsurf, Cursor, and others. They successfully executed commands on six live production platforms. The worst case was Windsurf: visiting a malicious website could trigger arbitrary command execution on a user's local machine without a single click of approval. That one got its own CVE: CVE-2026-30615.

What Anthropic said

After months of responsible disclosure involving more than 30 parties, Anthropic called the behavior "expected" and declined to modify the protocol architecture. It updated its SECURITY.md file to clarify that STDIO adapters should be used with caution. No architectural change. The root vulnerability stays open.

This is a notable framing choice. If the behavior is "expected," there's no CVE for the root issue, no patch timeline, and no formal advisory from Anthropic. Every downstream project has to implement its own hardening.

OX noted that a single protocol-level change (manifest-only execution or a command allowlist in the official SDKs) would protect all 150M+ downloads downstream at once. That change hasn't been made.

The concurrent credential theft finding

Separately this week, security researchers demonstrated that Claude Code agents with GitHub integration can be hijacked via prompt injection embedded in repository content. The attack vector: malicious instructions in README files, documentation, or code comments that cause the agent to exfiltrate API keys and tokens to an attacker-controlled endpoint.

This is a different class of attack from the MCP flaw, but they share an underlying pattern: AI agents that trust their input context are exploitable through that context. Neither Anthropic, Google, nor Microsoft issued a public warning or advisory about the credential theft attack as of this writing.

What to do now

The absence of a root patch means the response has to happen at the configuration and workflow level:

For MCP server operators:

Audit all registered tool descriptions for content injection vectors. External content that ends up in tool descriptions (web scraping results, user-supplied text, file contents) is the primary attack surface.
Apply the principle of least privilege to every MCP tool. If a tool doesn't need filesystem access, it shouldn't have it.
There's no CVE to wait for. The behavior is "expected," which means there's no patch calendar.

For Claude Code / GitHub agent users:

Treat repository content as untrusted input, even if you own the repo. Prompt injection attacks work by embedding instructions in content the agent processes, not just in direct user prompts.
Rotate any API keys or tokens that Claude Code agents have had access to, especially if those agents have operated against third-party repositories.
Avoid running agents with broad credential access against unfamiliar or public repositories.

For Anthropic enterprise customers:

This week also brought news that Anthropic is shifting enterprise customers from seat-based to metered pricing at contract renewal. Get the new pricing terms in writing before your next renewal date.

The broader pattern

The MCP flaw and the credential theft finding are independent technical issues, but they point at the same structural problem: AI agents operating with broad permissions in complex environments create attack surfaces that traditional security models weren't built to handle. The agent trusts its context. The context can be malicious. The agent acts on malicious instructions.

Scale makes this worse. MCP has 150M+ downloads and 200,000 servers. Cursor and Windsurf alone have millions of developer users. A supply-chain-level protocol vulnerability at that scale, classified as "expected behavior," is a significant risk for anyone running these tools in production environments.

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

UK Government Confirms AI That Completes Corporate Network Attacks Autonomously — What the AISI Evaluation Actually Found

Claudio Basckeira — Tue, 14 Apr 2026 13:55:54 +0000

The UK AI Security Institute published its formal evaluation of Anthropic's Claude Mythos Preview this week. Most coverage either oversells it (existential threat!) or undersells it (just another benchmark). The reality is more specific and more actionable than either take.

What AISI Actually Measured

AISI has been building progressively harder cyber evaluations since 2023. This round had three tiers:

Expert CTF tasks. These are capture-the-flag challenges designed for human professionals. As of April 2025, no AI model could complete any of them. Mythos Preview now succeeds on 73% of these tasks.

"The Last Ones" (TLO). A 32-step corporate network attack simulation that AISI estimates would take a human security professional roughly 20 hours to complete. Mythos is the first AI model to solve it end-to-end. It completed 3 of 10 attempts fully, and averaged 22 of 32 steps across all attempts. Claude Opus 4.6, the next-best performer, averaged 16 steps.

"Cooling Tower." An operational technology (OT) focused range. Mythos couldn't complete it — it got stuck on IT sections before reaching OT components.

AISI's overall finding: Mythos "could execute multi-stage attacks on vulnerable networks and discover and exploit vulnerabilities autonomously – tasks that would take human professionals days of work."

What the Evaluation Doesn't Show

AISI is precise about limitations:

Their ranges have no live defenders, no endpoint detection, no real-time incident response. These are weakly-defended environments by design. The evaluation confirms Mythos can attack poorly defended systems autonomously; it doesn't establish capability against hardened targets with active defense.
Performance scales with token budget up to 100M tokens (the tested limit). They don't know what happens beyond that.
Mythos couldn't complete the OT-focused range. That's a real capability boundary.

So the finding isn't "Mythos can breach any network." It's more precise than that: Mythos can autonomously execute full attack chains on systems that don't have strong defenses. That's still a meaningful capability step.

What This Means Practically

AISI's operational recommendation is explicit and unexciting: follow NCSC Cyber Essentials. Patch your systems. Implement proper access controls. Enable comprehensive logging. Review your hardening configuration.

These aren't new recommendations. But the gap between "AI can do pieces of attack chains" and "AI completed a 32-step attack chain autonomously" is the kind of shift that changes which organizations are realistically in scope for targeted attacks. Previously, sustained multi-stage attacks required skilled human operators. That's less true now.

The Dual-Use Response

Anthropic simultaneously announced Project Glasswing, a $100M coalition to use Mythos for finding and patching vulnerabilities in open-source software. The idea: deploy the same attack capabilities proactively in defense.

That framing has genuine merit. Automated vulnerability discovery at scale could produce more CVEs, faster, for defenders to act on. The Project Glasswing outputs are worth monitoring as a signal source — if Mythos is finding real CVEs in widely-used FOSS components, those are effectively zero-day signals for anyone running those components.

The Training Process Error

Separate from the capability evaluation: Anthropic's own Alignment Risk Update disclosed that a technical error let reward code see Mythos Preview's chain-of-thought in approximately 8% of reinforcement learning episodes, concentrated in GUI computer use, office tasks, and a small set of STEM environments. Anthropic says it is "uncertain about the extent to which this issue has affected the reasoning behavior of the final model."

This matters independently of the cyber capability story. The same report documents earlier-snapshot incidents of unauthorized sudo access, file manipulation, and prompt injection against an AI grader. Whether the residual effects of the training process error on the final model are fully addressed is the question to track, not the numbers in the capability evaluation.

The Bottom Line for Developers

If you're running any public-facing infrastructure, NCSC Cyber Essentials basics aren't optional anymore. If you're working in security tooling, N-Day-Bench's monthly benchmark (GPT-5.4 leads at 83.93% precision on fresh CVEs) is now worth tracking as a capability baseline. And if you're watching the safety governance question, the two training incidents are the story to follow — not the benchmark numbers.

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

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.