Seven Sections of 'React Faster.' Zero Sections of 'Prevent.'

Anthropic published "Preparing your security program for AI-accelerated offense" — seven sections of security recommendations from the team that builds Mythos, the model powering Project Glasswing. The document is thorough, well-organized, and maps to existing frameworks (SOC 2, ISO 27001, CISA CPGs).

It also prescribes one strategy, seven times: react faster with AI.

The timeline test

Map each section to where it operates on the timeline of a vulnerability's life:

Not one section operates at the point of creation — where the developer writes the code or configures the infrastructure. "Find bugs before you ship them" sounds upstream, but it isn't — it finds bugs after the developer wrote them, in the CI pipeline. The bug was created. The scan found it. That's earlier detection. Not prevention.

Prevention looks like: a declared invariant that makes the bug class impossible to create. A type system that eliminates buffer overflows by construction. A parameterized query that makes SQL injection impossible by construction. A policy check that rejects a configuration violating a declared rule before it reaches any pipeline. These mechanisms operate before the vulnerability exists — because they make the vulnerability impossible.

The word "prevention" appears once in the entire document. The word "declaration" appears zero times. The word "invariant" appears zero times. The word "specification" appears zero times.

"Prepare to handle a much higher volume of vulnerability reports"

Section 2 is the most revealing. Anthropic — the company building Mythos is telling you that AI will create more work.

More findings to triage. More patches to apply. More vendor reports to process. "Plan for an order-of-magnitude increase in finding volume." Their prescription: automate the triage with AI. Use AI to handle the flood that AI created.

This is the aftermarket feeding itself. A more powerful scanner produces more findings. More findings require more triage. More triage requires more AI. More AI requires more budget. The cost scales with the capability of the scanner — which Anthropic controls and improves every quarter.

The declaration approach produces the opposite dynamic. Each declared invariant reduces the finding volume. Because the vulnerability class is prevented from existing. There's nothing to find, triage or patch. The number of reports goes down over time. The triage queue shrinks. Each ratchet cycle makes the next cycle's workload smaller.

Anthropic's recommendation: prepare for 10x more findings. The declaration approach: reduce findings toward zero for every declared class. One strategy scales your costs with AI capability. The other shrinks your costs with each declaration.

AI prescribed for deterministic tasks

Throughout the document, every "AI can help" sidebar prescribes a frontier model for the task. Count them:

• Triage alerts → AI
• Deduplicate findings → AI
• Check dependency redundancy → AI
• Scan for vulnerabilities → AI
• Generate patches → AI
• Prune stale code → AI
• Red-team your perimeter → AI
• Hunt for misconfigurations → AI
• Investigate every alert → AI
• Draft postmortems → AI
• Drive the detection flywheel → AI

Now ask: which of these tasks have deterministic alternatives?

Each of these has a deterministic answer. Using an LLM to answer them creates Verification Debt — someone must check the AI's check, because the AI can be wrong. A boolean check on a security group JSON cannot be wrong. A date comparison cannot be wrong. A database lookup against the CVE registry cannot be wrong. Same answer every time. No verification needed. No debt accumulated.

The document prescribes the most expensive instrument for questions that have the cheapest answers. Because the document exists to demonstrate that a frontier model should be used for everything.

"Scan your own code with the same kind of model an attacker would use"

Section 3 prescribes the arms race: "You should scan your own code and systems with the same kind of model an attacker would use, before they do."

This is the most expensive possible security strategy. You scan. They scan. You scan faster. They scan faster. You upgrade to the latest model. They upgrade to the latest model. The cost scales with the speed of both sides. Neither side can stop because stopping means the other side gets ahead.

The declaration approach exits the arms race entirely. Declare what must be true. Verify mechanically. For every declared class, there's nothing for either side to find. You don't need to scan faster than the attacker for vulnerability classes that can't exist by construction.

The arms race has no equilibrium — each side's investment forces the other to invest more. The declaration approach has an equilibrium: each class declared is a class neither side ever spends resources on again. The ratchet makes the equilibrium compound.

The one section that almost gets it right

Section 5 — "Design for breach" — is the strongest because it's the only section that doesn't depend on finding vulnerabilities faster. Zero trust, hardware-bound credentials, short-lived tokens, service isolation by identity. These are architectural controls. They limit blast radius regardless of the vulnerability or how it was exploited.

And buried in section 3: "Prefer memory-safe languages for new code." This is the declaration approach — the language's type system declares "no buffer overflows" and enforces it by construction. Entire vulnerability categories eliminated. Eliminated, by declaration.

But it gets the same weight as "add SAST to your CI pipeline." The single most effective prevention mechanism available — eliminate entire vulnerability categories by construction is listed as one bullet among many, not elevated as the primary strategy.

The document treats prevention as a bullet point and detection as the architecture. The ratio should be inverted.

What's missing — the same three things

1. A declaration layer. No section recommends: "Write the properties your infrastructure must satisfy and verify them mechanically before deployment." The concept that a human could declare "no production database may be publicly accessible" and a machine could verify it on every configuration change — deterministically, at zero token cost is absent from the document.

2. The ratchet. No section recommends: "When you find a vulnerability class, convert it into a permanent machine-enforced rule that prevents the class from recurring." Section 7 mentions postmortems. But a postmortem that produces a document is not a ratchet. A postmortem that produces a declared invariant — checked mechanically on every subsequent change is a ratchet. The document prescribes postmortems. It doesn't prescribe converting them into declarations.

3. The quadrant distinction. The document treats all security as one domain — source code scanning, configuration checking, dependency analysis, alert triage, incident response — all handled by "a frontier model." But source code vulnerabilities, application configuration errors, infrastructure code flaws, and infrastructure configuration posture violations are four different problems with four different instruments:

• Application × Code: LLM scanning adds genuine value — novel patterns, complex logic flaws
• Application × Configuration: Schema validation and policy checks — deterministic, near-zero cost
• Infrastructure × Code: IaC linters and policy engines — deterministic, near-zero cost
• Infrastructure × Configuration: Declared invariants against runtime snapshots — deterministic, compound risk across resources

An LLM adds value in one quadrant. Deterministic checks add value in all four. The document prescribes LLMs for all four, because the document is written by the team that builds the LLM.

The structural bias

This document is a product placement.

It's structural. Anthropic's security team is recommending approaches that require Anthropic's model. Every "AI can help" sidebar — and there are eleven of them across seven sections — prescribes "a frontier model" for the task. The document exists to demonstrate that frontier models should be used for security work. Problems that have cheaper, deterministic, more reliable solutions are still framed as LLM tasks — because acknowledging that a three-line policy check is better than a frontier model would undermine the thesis the document exists to support.

This doesn't mean the recommendations are wrong. Many are sound. Patching faster is good. Triaging faster is good. Scanning before shipping is good. But the recommendations are incomplete — systematically, predictably, in the direction that favors the product Anthropic sells.

A complete set of recommendations would include:

1. Declare what must be true — invariants verified mechanically, at zero token cost, before deployment
2. Verify deterministically where possible — policy checks, schema validation, type systems for questions with binary answers
3. Scan with AI where necessary — novel code patterns, complex logic flaws, uncertain questions where probabilistic analysis adds value
4. Ratchet — every AI finding that represents a known class becomes a permanent declaration, reducing the AI's future workload

That's the three-layer architecture: declare, detect, ratchet. Anthropic's document covers layer two (detect) extensively. It omits layer one (declare) entirely. It doesn't mention layer three (ratchet) at all.

The result: a security program built on these seven sections will scan faster, triage faster, patch faster, respond faster — and never reduce the volume of work, because nothing prevents the vulnerability classes from recurring. Each quarter, Anthropic improves the model. Each quarter, the scan produces more findings. Each quarter, the triage queue grows. Each quarter, the security team needs more AI budget to handle what AI created.

The declaration layer is how you step off the treadmill. It's the section Anthropic didn't write — because it's the section that makes their product less necessary.

This article responds to Anthropic's "Preparing your security program for AI-accelerated offense" (April 2026). The three-layer architecture (declare → detect → ratchet) applied to cloud security in Cloud Computing Is Missing One Component. Everyone Builds the Wrong Five.. The four-quadrant grid (Application/Infrastructure × Code/Configuration) is detailed in The Aftermarket She Diagnosed is the Aftermarket She Prescribed.