The Aftermarket She Diagnosed is the Aftermarket She Prescribed

Jen Easterly's Glasswing analysis opens with the sharpest diagnosis of cybersecurity published this decade:

"We do not actually have a cybersecurity problem so much as a software quality problem. For decades, we have built an enormous global industry to defend, detect, and respond to vulnerabilities — flaws and defects in software — that should never have existed in the first place."

And later:

"The long-term goal cannot be simply to use AI to clean up yesterday's insecure code more efficiently. It must be to use AI to move security to the point of creation — to help developers write better, safer, more resilient software from the start. To shift from an aftermarket of cybersecurity to a world in which security is built in upstream, not bolted on downstream."

The diagnosis and the destination is correct.

The prescription doesn't match either one.

What is Glasswing

Anthropic's Project Glasswing finds vulnerabilities in codebases and assists with remediation. In Easterly's own framing, it offers the potential to "identify vulnerabilities more quickly" and "reduce the cost, time, and complexity of fixing them — assist with root cause analysis, generate candidate patches, prioritize risk, and accelerate testing and deployment."

This is the aftermarket she diagnosed, accelerated by AI.

Finding vulnerabilities faster is still finding. Fixing them cheaper is still fixing. Generating candidate patches is still remediating. Every one of these activities happens after the vulnerability exists — in the code, in production, in the codebase of a systemically important financial institution, JP Morgan Chase. The vulnerability was created. It was deployed. It persisted. Then the AI found it.

That's a faster aftermarket. Not the end of the aftermarket.

The cure she named but didn't prescribe

"Security built in upstream, not bolted on downstream." That sentence describes a specific architecture — one that exists today, has been proven for decades, and doesn't require a frontier AI model to implement.

Built in upstream means: declare what must be true before the code is written or the configuration is deployed. "No public S3 buckets in production." "No IAM role may assume cross-account access without MFA." "No API endpoint may accept unauthenticated requests." "No dependency with a known critical CVE may be deployed." These are declarations — human-authored statements of what the system must satisfy, expressed in a form a machine can check.

Not bolted on downstream means: verify the declaration mechanically at the point of creation — before the code ships, before the configuration propagates, before the vulnerability exists to be found. A type checker that prevents buffer overflows at compile time. A policy engine that rejects a configuration violating a declared invariant before it reaches production. A contract test that blocks an API change that breaks a declared interface. These are deterministic verification gates — not models forming opinions, but mechanical checks producing binary verdicts: pass or fail.

The architecture is:

1. Human declares what must be true (the specification — upstream, slow, requires domain judgment)
2. Machine verifies every change against the declaration (the gate — downstream, fast, deterministic, on every commit)
3. The ratchet converts each newly discovered vulnerability class into a new declaration. So the class is permanently prevented, not just found and fixed faster next time

Every safety-critical domain does this:

Aviation regulator does not ask a pilot to find envelope violations after the flight and fix them next time. The flight computer prevents the violation from occurring. That's "built in upstream." Glasswing finds the violations after the flight landed and offer to help patch the plane. That's "bolted on downstream" — faster, with AI, but still downstream.

"The same categories of flaws we have seen for decades"

Easterly makes this point herself. It's the most damning evidence for the declaration approach over the discovery approach:

"What these systems are uncovering is not exotic. They are not revealing some radically new class of AI-discovered weaknesses but rather highlighting further evidence of poor-quality design: the same categories of flaws we have seen for decades — predictable, preventable vulnerabilities that persist because our incentives have never been aligned to eliminate them."

If the vulnerability categories are known, predictable, and preventable — then the declarations can be written today. "No buffer overflow" is a property Rust enforces by construction. "No SQL injection" is a property parameterized queries enforce by construction. "No public S3 bucket" is a property a three-line policy check enforces before deployment. "No cross-account IAM trust without MFA" is a property a CEL predicate evaluates against the configuration snapshot.

These aren't novel problems requiring a frontier model to discover. They're known problems requiring a declaration to prevent. Every vulnerability Glasswing finds in a "predictable, preventable" category is a vulnerability that a declared invariant would have blocked before it existed.

AI that finds a SQL injection in production code is doing useful work. A parameterized query that makes SQL injection impossible by construction is doing better work — at zero token cost, zero remediation time, zero human-in-the-loop overhead.

"Remediation is the real challenge"

Easterly argues that discovery was never the bottleneck — remediation was. Finding the vulnerability is the easy part. Understanding root cause, developing a fix, testing it, ensuring it doesn't break functionality, deploying it across complex systems — that's the hard, expensive, human-heavy part. Glasswing makes that part faster.

This is correct for vulnerabilities that already exist. It's irrelevant for vulnerabilities that were prevented from existing.

A declared invariant that prevents a class of vulnerability at creation time has zero remediation cost. The vulnerability was never created. There's nothing to root-cause, nothing to patch, nothing to test, nothing to deploy. The remediation challenge Easterly correctly identifies disappears, because the declaration made it unnecessary.

The distinction the article misses: the most effective remediation is prevention. The most cost-effective patch is the one that was never needed. The most efficient vulnerability disclosure is the one that never happened because the class was declared impossible.

"Not the end of cybersecurity as a mission"

Easterly's closing is right: even with Glasswing, cybersecurity doesn't end. Even with declared invariants, cybersecurity doesn't end. No finite set of declarations catches everything. This was formalized mathematically by Vassilev's NIST proof (June 2026), extending Gödel's incompleteness theorems to AI and security systems.

The architecture isn't "declare everything and you're safe." It's:

1. Declare what you know — the known categories, the predictable flaws, the preventable vulnerabilities. These are the classes Easterly herself says we've known about for decades. Declare them. Verify them. Prevent them.
2. Detect what you don't know — behavioral monitoring, AI-assisted discovery, Glasswing-class tools. These find the vulnerabilities no declaration has been written for yet. This is the aftermarket's permanent role — catching what the declarations don't cover.
3. The ratchet — every vulnerability the aftermarket discovers becomes a new declaration. The class is permanently prevented. The aftermarket's job shrinks. The declaration layer grows. Each cycle makes the next one smaller.

Glasswing is valuable in layer 2 — discovering what the declarations don't yet cover. But without layer 1, Glasswing runs forever at the same rate, finding the same predictable, preventable categories Easterly says we've known about for decades. With layer 1, Glasswing focuses only on the novel. The classes nobody has declared yet, which is a much smaller, much more valuable set.

When the most credible expert has the same blind spot as the market

Jen Easterly ran CISA — the nation's Cyber Defense Agency. She led the Secure by Design initiative. She pushed the technology ecosystem toward greater security, resilience, and accountability more effectively than anyone in a government role in the last decade. When she writes about cybersecurity, she speaks from deeper operational experience than virtually anyone in the industry.

And she has the same blind spot as every vendor, every framework, and every AI company in the market.

The blind spot is in the mental model the entire cybersecurity industry uses. The frame is: threats exist → find them → fix them → repeat. Defend, detect, respond. The entire discipline — from CISA's mission statement to SOC 2 controls to every vendor's pitch deck — is organized around the reactive cycle.

The declaration approach — declare what must be true, verify mechanically, prevent by construction — comes from a different discipline entirely. Systems engineering. Formal methods. TRIZ. Control theory. Type systems. These disciplines have been preventing failure classes by construction for decades. Aviation doesn't ask pilots to find and fix envelope violations after the flight. Nuclear doesn't ask operators to detect and remediate interlock failures after the reactor event. The prevention frame exists. It's proven. It's been in production for fifty years.

Cybersecurity has never intersected with it. Because the discipline was built as an aftermarket — Easterly said this herself — and the aftermarket frame shapes every prescription that comes out of it. When you've spent your entire career defending, detecting, and responding, every new tool looks like a better way to defend, detect, and respond. Mythos looks like a faster defender. Glasswing looks like a better detector. AI-assisted triage looks like a faster responder. The frame makes everything look reactive — because the frame is reactive.

The declaration layer is invisible from inside the reactive frame. She can't see it — because the frame she operates within doesn't have a category for "make the vulnerability class impossible by construction." The frame has categories for: find it, fix it, contain it, respond to it. Not: prevent it from existing.

This is why the four-quadrant grid, the cost comparison table, the ratchet, and the cross-domain evidence matter. They introduce concepts from outside the reactive frame — from systems engineering, from aviation, from formal methods — that the cybersecurity frame doesn't contain. The argument is: the most capable expert, operating within a reactive frame, will produce a reactive prescription — regardless of how much experience they have. The blind spot is real. The frame explains why it exists. The prescription she's offering to the market reinforces the reactive frame for everyone who follows her lead. When the most credible voice in cybersecurity says "AI will fix this," the industry listens. And the declaration layer — the layer that would eliminate the aftermarket she diagnosed — gets buried under another cycle of faster detection.

The real signal in Glasswing

There's a conflation in Easterly's framing that obscures where the cure applies and where it doesn't.

"Software quality" is four different problems

Easterly frames the crisis as a "software quality problem." That framing collapses four distinct domains into one bucket. Each domain has different discovery mechanisms, different prevention tools, and different verification approaches:

Glasswing operates in one quadrant: Application × Code. It finds source code vulnerabilities — the buffer overflows, the injection flaws, the logic errors. That's real and valuable work. It's also one-quarter of the problem.

Mythos reads source code. It reasons about source code. It finds patterns in source code that match known vulnerability classes. It generates patches for source code. Every capability is scoped to one cell of the grid: Application × Code. It cannot evaluate whether your IAM policy grants excessive cross-account access — that's Infrastructure × Configuration. It cannot detect whether your S3 bucket policy combined with your Cognito identity pool creates a privilege escalation path — that's compound risk across Infrastructure × Configuration resources. It cannot verify whether your Terraform template violates your organization's security policy — that's Infrastructure × Code. It cannot check whether your application's authentication configuration matches your security requirements — that's Application × Configuration.

Mythos is the most powerful source code analysis model ever built. Source code is one cell. The grid has four. Three cells where the majority of cloud breaches originate are invisible to it. The hype positions Mythos as the future of cybersecurity. The grid positions it as the future of one-quarter of cybersecurity. The other three-quarters need a different instrument: declared invariants verified against configuration, not a model reading source code.

The DDP Law breach — fined £60,000 by the ICO after a ransomware attack — had root causes exclusively in the Infrastructure × Configuration quadrant: no firewall, no MFA, unpatched systems, a dormant user account active for years. Every root cause was a boolean check against a declared rule. No AI needed. No source code scanning would have found them. They're not code quality problems. They're configuration posture problems, deducible from the infrastructure itself.

Compound cross-resource risk lives at the intersection of quadrants. A Cognito identity pool (Application × Configuration) combined with an IAM trust policy (Infrastructure × Configuration) combined with an S3 bucket policy (Infrastructure × Configuration) creates a privilege escalation path that no single-quadrant tool sees. The risk is in the combination — the edges between resources, not the nodes. Glasswing scanning source code doesn't see it because the vulnerability isn't in any source code. It's in the relationship between three configurations across two quadrants.

The exploit chain doesn't stay in one quadrant

Breaches don't respect quadrant boundaries. A typical 2026 breach crosses all of them:

1. Infrastructure × Configuration: A slightly over-privileged IAM role — broader trust than intended, never reviewed after the initial setup
2. Application × Configuration: A misconfigured OIDC provider — authentication settings that permit an unintended flow
3. Application × Code: A logic flaw that allows session hijacking — the source code vulnerability

Glasswing finds and fixes step 3. Steps 1 and 2 remain a loaded gun. The source code is patched. The IAM role is still over-privileged. The OIDC provider is still misconfigured. The next logic flaw or the next developer who introduces one walks straight through the same infrastructure path because the architecture was never fixed.

This is why configuration risk is a graph problem, not a pattern-matching problem. An LLM reads code and matches patterns against its training data. Configuration risk lives in the relationships between resources — the edges of the graph, not the nodes. "Does this IAM role, combined with this trust policy, combined with this bucket policy, create an unauthenticated path to sensitive data?" is a graph reachability question. You don't need an AI to guess whether a graph is connected. You need a solver to prove it isn't.

Deterministic reasoning engines — CEL predicates, Z3 constraint solvers, Soufflé/Datalog for graph reachability — answer these questions at the correct level of abstraction: mechanically, exhaustively, and with mathematical certainty. An LLM forming an opinion about whether a configuration graph contains a reachable path is using the wrong instrument for the question. The graph either contains the path or it doesn't. That's a computation, not a judgment call.

Intent mismatches live in the gap between what was configured and what was meant. A security group that allows 0.0.0.0/0 inbound on port 22 may be intentional (a bastion host) or a misconfiguration (an application server). No source code scanner can distinguish intent from error — because intent was never declared. A declared invariant ("no production server may accept SSH from 0.0.0.0/0") makes the check trivial and deterministic.

The "software quality problem" framing leads to a "better source code scanning" prescription — which addresses one quadrant and leaves three unprotected. The declaration approach works across all four quadrants:

• Application × Code: type systems, memory-safe languages, parameterized queries prevent vulnerability classes by construction
• Application × Configuration: schema validation, policy checks verify app settings against declared rules before deployment
• Infrastructure × Code: IaC linters (Checkov, tfsec) verify templates against declared policies before apply
• Infrastructure × Configuration: declared invariants checked against runtime configuration snapshots — the quadrant no source code tool sees

Glasswing makes one quadrant's aftermarket faster. Declared invariants prevent vulnerabilities in all four quadrants before they exist. Both are needed. Only one of them covers the full surface.

The four-quadrant grid is the best case

The grid above assumes a mature organization where infrastructure is defined as code, configurations are version-controlled, and changes flow through CI/CD pipelines. That's the best case. The reality in most organizations is worse:

ClickOps. Infrastructure configured through the AWS console, Azure portal, or GCP dashboard. No Terraform, CloudFormation or code at all. Someone clicked through a UI to create IAM roles, security groups, S3 bucket policies. The infrastructure exists only as runtime state — not in any repository, not version-controlled, not reviewable by any source code scanner. Mythos cannot scan what was never written as code. The Infrastructure × Code quadrant is empty. Everything lives in Infrastructure × Configuration as runtime state that nobody declared, nobody version-controlled, and nobody can verify without snapshotting the live environment.

Shadow scripts. One engineer wrote a bash script three years ago that rotates credentials, manages DNS, or configures backup policies. It's on that engineer's laptop. It's not in any repo. Nobody else knows it exists. When that engineer leaves, the script keeps running or stops running and nobody knows until something breaks. This is undeclared intent: someone had a reason for the script, but it was never expressed in a form anyone else can verify.

Tribal knowledge. "Dave knows how the production database failover works." "Sarah set up the VPN configuration." "The security group on the legacy account was configured by someone who left in 2023." The configuration exists. The intent behind it is gone. Nobody can distinguish a deliberate security exception from a forgotten misconfiguration, because the intent was never declared.

Manual configuration drift. An engineer configured a security group correctly through IaC six months ago. Last Tuesday, someone opened port 22 through the console during an emergency and never closed it. The IaC template says the port is closed. The runtime state says it's open. No source code scanner sees the drift — because the drift isn't in the source code. It's in the gap between declared state (IaC) and actual state (runtime configuration).

In these environments, which are most environments, the four-quadrant grid overstates the problem's tractability. Mythos's limitation isn't just "one quadrant out of four." It's "one quadrant out of four, and in many organizations, there is a fifth quadrant that exists because the infrastructure was never written as code in the first place. This is the invisible case: shadow IT."

The declaration layer becomes even more critical in these environments. A declared invariant — "no production security group may allow 0.0.0.0/0 inbound on port 22" — can be checked against a snapshot of the runtime state regardless of whether the configuration was applied through Terraform, the AWS console, a shadow script, or a manual change nobody documented. The invariant doesn't care how the configuration got there. It checks whether the configuration satisfies the rule. That's the only verification mechanism that works when the source of truth is the runtime environment, not a codebase Mythos can scan.

"Defenders must understand root cause, develop a fix, test it"

Easterly frames the remediation challenge as: understand root cause → develop a fix → test it → ensure it doesn't break functionality → deploy across complex systems. She then argues AI will make each step faster. This frames the defender's job as a diagnostic chain — understand, then act.

Viable systems don't work this way.

A thermostat doesn't understand thermodynamics. It compares temperature to setpoint and acts. An aircraft interlock doesn't understand aerodynamics. It detects a parameter exceeding a limit and overrides the pilot. A circuit breaker doesn't understand electrical engineering. It senses current exceeding a threshold and trips.

A viable system regulates itself in a changing environment without fully understanding the cause of failure. It doesn't need root cause analysis to prevent damage. It needs declared boundaries and the ability to act when they're violated. The root cause analysis happens later by humans, at human speed, for learning and improvement. But the system was already protected because the boundary was declared and the response was mechanical.

This is the primary function of any control system: regulate, then understand — not understand, then regulate. Easterly's framing inverts the order. She says defenders must first understand, then fix. The viable-system model says: first prevent the damage (the declared boundary catches the violation mechanically), then understand the cause (humans analyze at human speed for future improvement).

The ratchet connects both: the human's understanding — gained after the fact, at human speed — becomes a new declared boundary that prevents the class from recurring. The system didn't need to understand the cause in real time. It needed the boundary. The understanding came later and made the boundary set grow.

Glasswing accelerates the "understand, then fix" chain. Declared invariants eliminate the need for the chain entirely — for every class that's been declared. Both have a role. But positioning AI as the solution to the remediation bottleneck assumes defenders must always understand before they act. Viable systems act first and understand later.

AI cannot solve problems that require deterministic answers

There's a deeper issue with Easterly's prescription that the four-quadrant grid exposes: she's proposing a probabilistic tool for problems that require deterministic answers.

An LLM reading source code and forming an opinion about whether it contains a vulnerability is probabilistic. It's pattern-matching against training data. It can be wrong. It can miss vulnerabilities. It can hallucinate vulnerabilities that don't exist. Its verdict is an opinion with a confidence score, not a proof.

The problems in three of the four quadrants don't need opinions. They need verdicts:

• "Does this IAM policy grant cross-account access without MFA?" → Yes or no. Deterministic. Computable from the policy document. No model needed.
• "Does this S3 bucket allow public read access?" → Yes or no. Deterministic. Computable from the bucket policy. No model needed.
• "Does this Terraform template create a security group with 0.0.0.0/0 inbound on port 22?" → Yes or no. Deterministic. Computable from the template. No model needed.
• "Does the combination of this Cognito pool, this IAM trust policy, and this S3 bucket policy create an unauthenticated path to sensitive data?" → Yes or no. Deterministic. Computable from the three configurations. No model needed — but requires compound reasoning across resources.

Using an LLM to answer questions that have deterministic answers is using the wrong instrument. It's measuring temperature with a poem instead of a thermometer. The poem might be approximately right. The thermometer is exactly right. Every time. At a fraction of the cost.

This creates what should be called Verification Debt: when you use a probabilistic tool to answer a deterministic question, you need a human to check the AI's check. The AI says "this S3 bucket is probably public." A human must verify: is it actually public? The AI says "this IAM role probably has excessive permissions." A human must verify. Each probabilistic answer generates a verification task for a human — which is the review bottleneck Easterly was trying to eliminate. The declaration approach eliminates the debt entirely: "no public S3 buckets" is checked mechanically, produces a binary verdict, and requires zero human verification. The violation is either present or it isn't. No probability. No debt.

AI has a role: the uncertain questions. "Is this code pattern likely to cause performance issues under load?" "Does this API design follow security best practices?" "Is this error handling sufficient for production use?" These are judgment calls where a model's pattern-matching adds value because there's no deterministic answer.

But Easterly's prescription doesn't distinguish between questions that have deterministic answers and questions that require judgment. She prescribes AI for both. The result: an expensive, probabilistic tool answering questions that a three-line policy check answers definitively — while the three-line policy check doesn't exist because nobody built the declaration layer.

"Reduce the cost, time, and complexity of fixing them"

Let's take Easterly's claim at face value and score it against the alternative:

AI reduces cost, time, and complexity. Deterministic prevention eliminates them — for every class that has been declared. Reduce and eliminate are different words with different outcomes and different economics.

Easterly says "for the first time, AI offers the potential to reduce the cost, time, and complexity of fixing them." For three of the four quadrants, deterministic approaches already beat AI on all three metrics — at a fraction of the cost, at zero time (prevention, not remediation), and at zero complexity (a boolean check, not a diagnostic chain). AI cannot reduce time to zero because it operates after the vulnerability exists — finding and fixing takes time regardless of the speed of AI. Prevention reduces time to zero because the vulnerability never exists. There is no time between "vulnerability created" and "vulnerability fixed" when the vulnerability was never created.

The economics are stark: an organization running Glasswing against a million lines of code pays for every scan in tokens. An organization running declared invariants against configuration snapshots pays microseconds of CPU per evaluation. The first cost scales with volume. The second is near-constant. At enterprise scale — millions of lines, thousands of configurations, continuous scanning — the cost difference is not marginal. It's orders of magnitude.

AI has a role in quadrant one (Application × Code) where the questions are complex — buffer overflows in novel code patterns, logic errors in unfamiliar architectures, zero-day vulnerability classes nobody has declared yet. That's real value. But prescribing AI for all four quadrants — including the three where deterministic checks produce better results at near-zero cost is prescribing the most expensive instrument for problems that have the cheapest solutions.

The Silver Bullet Fallacy

Easterly's article makes one argument: Mythos has arrived. It will solve cybersecurity.

This is the silver bullet. The single technology that eliminates the problem. Fred Brooks named this fallacy in 1986: "There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement in productivity, reliability, or simplicity." Forty years later, the argument repeats with a different technology name.

Cybersecurity is a software quality problem → Mythos finds and fixes software quality issues → therefore Mythos solves cybersecurity. Each step sounds reasonable. The chain is broken.

Step one is correct but incomplete. Cybersecurity is four different quality problems across four quadrants, not one. Mythos addresses one quadrant.

Step two is correct but narrow. Mythos finds and fixes source code issues. It cannot find configuration posture issues, compound cross-resource risk, or intent mismatches — because those aren't in source code.

Step three doesn't follow. A tool that addresses one-quarter of the problem cannot solve the whole problem, regardless of how powerful it is within that quarter. A perfect source code scanner running on the DDP Law infrastructure finds zero issues. Because every vulnerability was in configuration, not code. The infrastructure is breached while the scanner reports all clear.

Every silver bullet in cybersecurity history followed the same arc:

Each generation solved one class of problem and was marketed as the solution to all classes. Each generation's limitation became the next generation's market opportunity. Mythos is following the same pattern — powerful in its quadrant, blind to the other three, marketed as the answer to cybersecurity.

The alternative to a silver bullet is a complete system. Not one tool that does everything. Five elements, each serving its function, each covering its quadrant. The specification layer declares what must be true across all four quadrants. The verification gate checks every change deterministically. The behavioral detection layer (where Glasswing lives) catches what the declarations don't yet cover. The ratchet converts each discovery into a new declaration. The casing enforces boundaries and prevents accumulation.

No single element solves cybersecurity. No single tool covers all four quadrants. No single model — however powerful — replaces the declaration layer, the verification gate, and the ratchet. The silver bullet is always the same fallacy: one element elevated to the status of a complete system. Mythos is a sub-system. It's not the system.

The honest counter-point — and the synthesis

There's a reason Glasswing is popular in 2026: humans are bad at declaring.

Writing CEL predicates for a multi-cloud environment is difficult. Authoring Rego policies across hundreds of AWS services is error-prone. Maintaining a corpus of invariants that covers every configuration pattern an organization deploys requires sustained effort that most security teams don't have the bandwidth. The declaration layer should exist. In most organizations, it doesn't — because declaring is hard.

This is Easterly's implicit argument: AI will handle the mess because the declarations don't exist. If nobody is going to write the invariants, then a model that finds the violations is the next best thing. That's a legitimate position — pragmatic, grounded in the reality that most organizations don't have the discipline or capacity to build a complete declaration layer.

But it concedes the aftermarket permanently. If the declarations never get written, the model runs forever — finding the same predictable, preventable categories Easterly says we've known about for decades. The system never learns. Each scan is a new expense. Each finding is a new remediation task. The treadmill runs at AI speed instead of human speed, but it's still a treadmill.

The synthesis of both positions is the ratchet — and Mythos has a role in it:

Use AI to generate the deterministic invariants that then render the AI unnecessary for that class of bug.

Mythos finds a SQL injection pattern → a human reviews the finding → the finding becomes a declared invariant ("no concatenated SQL in database queries") → the invariant is enforced deterministically on every commit → Mythos never needs to find that class again. Mythos finds an over-privileged IAM role → a human reviews the role → the finding becomes a declared invariant ("no IAM role may have * permissions on production resources") → the invariant is checked against every configuration snapshot → Mythos never needs to find that class again.

Each cycle: AI discovers, human reviews, declaration is authored, deterministic gate enforces. The AI's workload shrinks. The declaration layer grows. The cost of verification drops toward zero for every class that's been declared. The AI focuses on the new classes nobody has declared yet — which is a smaller, cheaper, more valuable set each cycle.

This is the role Easterly should be prescribing for Glasswing: not the permanent solution, but the discovery engine that feeds the declaration layer. Glasswing finds. Humans declare. Deterministic gates enforce. The ratchet turns. Each cycle permanently reduces what Glasswing needs to find. That's not "the beginning of the end of cybersecurity as we know it." It's the beginning of cybersecurity as it should have been built: human judgment upstream, machine enforcement downstream, AI in the middle discovering what hasn't been declared yet and getting less necessary every cycle.

The real signal

Easterly frames Glasswing as "a signal of something far more consequential: a shift in how we might fundamentally reduce cyber risk at scale." She's right that it's a signal. But the signal isn't "AI can find and fix bugs faster." The signal is: if the most powerful AI model in the world is finding the same categories of preventable vulnerabilities that have existed for decades, then the problem was never discovery and the solution is not better discovery.

The solution is what she said in her opening paragraph: security built in upstream. Declared invariants verified at creation time. The aftermarket reserved for what the declarations can't cover — which, as the declarations grow, becomes an increasingly small set.

Glasswing is the best aftermarket tool ever built. The declaration layer is how you stop needing it for the classes you already know about. Both exist. Both are needed. Only one of them ends the cycle Easterly correctly diagnosed. And it's the one she described in her opening and didn't prescribe in her conclusion.

References: Jen Easterly's Glasswing analysis (LinkedIn, June 2026); Anthropic, Project Glasswing; Vassilev, NIST/IEEE Security and Privacy (June 9, 2026) — mathematical proof that no finite set of guardrails is universally robust. The three-layer architecture (declare → detect → ratchet) applied to cloud security in Cloud Computing is Missing One Component. Everyone Builds the Wrong Five.