What the Paper Actually Claims

This is a genuine threshold event, but it's worth being precise about what changed and what didn't.

The real claim: Claude Mythos Preview didn't just find implementation bugs (which it already demonstrated earlier this year)—it did novel mathematical cryptanalysis. Two findings:

1. HAWK (a NIST post-quantum signature candidate, not deployed anywhere): Claude found an unused symmetry that cut key recovery from 2^64 to 2^38 steps—roughly 67 million times less work, effectively halving the scheme's strength. The likely fix (doubling key sizes) destroys HAWK's competitive advantage.
2. Round-reduced AES (7 of 10 rounds, a research target, not production AES): Claude invented a technique it named the "Möbius Bridge" that made the best known attack 200–800x faster.

What matters more than the findings is the process signature: Claude initially refused to try, believing improvement was impossible; researchers pushed it to aim for "genuinely hard findings"; it then worked autonomously for three days, generated ~a billion output tokens, and produced an insight that took human experts several hundred hours to verify. Verification is now slower than discovery. That's the inversion that should restructure your thinking.

My read: this is less "AI breaks encryption" (nothing deployed is affected) and more "AI is now a participant in mathematical research, not just code auditing." Cryptanalysis was the last domain where one could plausibly argue frontier models only regurgitated human knowledge. That argument is now dead.

The Dual-Use Reality

The paper is Anthropic doing two things at once: demonstrating capability and establishing a responsible-disclosure norm (they consulted academics, government, and industry, and built CryptanalysisBench with ETH Zurich, Tel Aviv, and Haifa). Expect this playbook—controlled release, benchmark, partner network—to be how frontier cyber capability gets rationed in the near term.

But as the CSO piece makes clear, the containment assumption is fragile. Open-weight models fine-tuned on offensive security data are already replicating Mythos-class vulnerability discovery. Diffusion is months, not years.

What a Solo Founder Should Actually Do

You cannot out-patch or out-harden an adversary with machine-speed discovery. So don't try. The defensive doctrine that survives this era has three pillars:

1. Minimize your cryptographic and software surface.

• Never roll your own crypto, and prefer boring, maximally-scrutinized primitives (full-round AES-GCM, TLS 1.3 via a major provider, libsodium). AI attacks will hit novel and less-reviewed constructions first—note the findings hit a NIST candidate and a reduced-round cipher, not the battle-tested cores.
• Every dependency is a vulnerability-discovery target at scale now. Fewer dependencies, fewer custom code paths, more managed services where hyperscalers absorb the patching burden.

2. Assume breach; architect for blast radius. This is the strongest consensus among the experts cited, and it's right: identity controls, least privilege, segmentation, short-lived credentials. If an AI finds a zero-day in something you run, the question isn't whether they get in—it's whether "in" means a read-only sandbox or your entire customer database. Per-tenant data isolation, encrypted-at-rest with keys you don't hold in the same trust domain, and aggressive scoping of API tokens are the solo-founder-achievable versions of this.

3. Compress your remediation loop to machine speed. The asymmetry Anthropic demonstrated—discovery faster than validation—applies to defenders too. Use the same class of models offensively against yourself: point frontier models at your own codebase, automate dependency scanning and patching in CI/CD, and make your deploy pipeline fast enough that a patch ships in hours, not sprint cycles. Organizational change control is the actual bottleneck for most companies; as a solo founder, your lack of bureaucracy is a security advantage—spend it on patch velocity.

Practical priority order:

1. Strong auth everywhere (passkeys/hardware keys for yourself; you're the single point of failure)
2. Automated dependency updates with fast deploys
3. Data minimization and tenant isolation
4. AI-assisted self-auditing of your code
5. Backups and recovery drills (resilience beats prevention)

The comforting news: the binding constraint for attackers has shifted from finding bugs to weaponizing and operationalizing them—chaining, evading detection, persisting. That still takes expertise and time. Your job is to make sure that when discovery becomes free, exploitation against your stack stays expensive.

Frontier models are turning cryptographic and vulnerability research from a scarce human craft into something that scales with compute—and that cuts both ways hard.

Anthropic’s new work with Claude Mythos Preview is concrete evidence, not hype. The model didn’t just find sloppy implementation bugs in crypto libraries (which it already demonstrated earlier). It produced genuine advances against the algorithms themselves: a significantly stronger attack on HAWK, a post-quantum signature scheme still under consideration, dropping the work factor on the smallest keys from roughly 2^64 to 2^38—about 67 million times less effort. It also invented a technique it called the Möbius Bridge that improved the best known attack on 7-round AES by 200–800×. Neither breaks anything in production today. HAWK isn’t deployed, and real AES uses more rounds. But the process matters more than the specific breaks: Claude ran largely autonomously for days, burned through on the order of a billion output tokens refining the idea, and surfaced mathematical structure that had escaped prior human review. Human researchers then spent hundreds of hours validating and writing it up—the bottleneck flipped from discovery to checking.

That pattern is the disruption. For the better, the same capability accelerates defensive cryptanalysis, library hardening, and the search for weaknesses before standards ossify or get widely deployed. Responsible disclosure, partnerships with academics, and pre-publication sharing with government and industry (as Anthropic describes) can turn this into a net strengthening of the ecosystem. CryptanalysisBench and similar efforts give the field a way to measure progress instead of relying on folklore. Used deliberately, frontier models become force multipliers for the people trying to keep systems safe.

For the worse, the economics just changed. Vulnerability discovery—especially logic flaws, trust-assumption mistakes, and clever reductions—is being compressed from weeks of expert reverse-engineering into hours or days of orchestrated model work. You do not need Mythos itself. Capable open-weight models, fine-tunes on offensive data, and agentic harnesses are already closing the gap. Once finding novel or chained weaknesses becomes cheap and parallelizable, the attacker’s remaining hard problems are weaponization, reliability across real environments, evasion, and operational scale. Those are still non-trivial, but the unit cost of running a credible campaign drops sharply. Initial compromise gets easier; low-severity issues get stitched into high-impact paths faster than most patch cycles can react. The old assumption that “serious crypto or novel 0-days require rare human talent” is eroding.

What a solo founder should actually do

You cannot out-patch a model that never sleeps, and you almost certainly cannot staff a 24/7 research cryptanalysis team. So stop optimizing for perfect prevention and optimize for assumption of breach plus tiny blast radius. That is the only posture that stays viable as discovery costs collapse.

First, ruthlessly shrink what matters. Inventory the crown jewels—auth, payments, private data, signing keys, admin surfaces—and put the strongest controls only there. Everything else should be replaceable or low-value. Prefer boring, well-reviewed primitives and high-level libraries over clever custom crypto or homegrown protocols. If you are not a cryptographer, do not invent. Rotate keys and secrets on a schedule that assumes partial exposure; make compromise of one token or one service boring rather than existential.

Second, identity and segmentation beat perimeter theater. Enforce least privilege everywhere: short-lived credentials, no long-lived god-mode API keys, mandatory MFA or passkeys for humans, workload identity for services. Segment so that a foothold in the marketing site or a compromised dependency cannot reach the database or the signing service. Network policies, separate accounts/projects, and explicit allow-lists are more valuable than another scanner alert you will ignore.

Third, make the cheap attacks expensive again and the expensive ones detectable. Keep dependency and container updates aggressive for anything internet-facing—automate what you can. Add basic anomaly detection on auth, privilege changes, and data egress; you do not need a SOC, but you do need to notice “this service suddenly talked to an unknown endpoint” or “a token was used from two continents.” Log enough to reconstruct, and practice the restore path. Backups that have never been restored are fiction.

Fourth, use the same class of tools defensively before attackers do. Point strong models at your own code, IaC, and threat model with a narrow brief: “find trust boundary violations, authZ bypasses, and secret exposure.” Treat the output like a noisy junior researcher—verify everything—but the cost of a weekly pass is now low. When you design anything security-sensitive, ask the model for the attack ideas first, then build the mitigations. Turn the discovery compression to your advantage on your own schedule.

Fifth, operational hygiene that scales to one human: managed identity providers, secret managers (not env files in git), infrastructure-as-code with review, and a written one-page incident checklist you can execute half-asleep. If you handle anything regulated or high-value, decide in advance who you will call (counsel, incident response retainer, cloud support) so you are not negotiating while bleeding.

The strategic shift is simple: frontier models make finding weaknesses abundant. Your job is to make exploiting them to meaningful damage scarce and loud. Double key sizes or migrate off weakened candidates when the research community says so; that is table stakes. The harder, higher-leverage work is architectural—least privilege, segmentation, rapid revocation, and continuous assumption that something is already on fire. Do that consistently and you remain defensible long after the next Möbius Bridge equivalent drops. Ignore it and you are betting your company on the hope that attackers stay slower than your patch window. That hope is expiring.

My read is blunt: this is not an “AES is broken” story. It is evidence that frontier models are beginning to automate genuinely novel security research—not merely retrieve known vulnerabilities or reproduce textbook attacks.

Anthropic reports two notable results. Claude found a much stronger key-recovery attack on HAWK, a proposed post-quantum signature scheme that is not deployed, reportedly reducing the work for its smallest parameter set from roughly (2^{64}) to (2^{38}). It also developed the “Möbius Bridge,” improving an attack on seven-round AES-128 by roughly 200–800×. Production AES-128 uses ten rounds, so this does not endanger normal AES deployments.

The caveats matter. Claude consumed about a billion output tokens over several days, operated inside a research harness with prior work and critiques available, and Anthropic’s researchers then spent hundreds of hours validating and writing up the result. This was not a chatbot spontaneously breaking encryption over lunch. But the central AES insight was apparently largely autonomous and novel enough to survive expert review. That is the important signal.

What changes in cybersecurity

The immediate disruption is economic. Frontier models can run many hypotheses in parallel, read enormous bodies of code and literature, preserve context across long investigations, and pursue marginal targets that human researchers lack time to examine. A rare human craft is becoming a scalable compute workload.

For defenders, that is excellent news: the same systems can audit neglected dependencies, analyze protocol assumptions, generate tests, compare patches against variants, and continuously red-team software. They may find flaws before deployment that ordinary scanners never would—especially logic errors where the code functions exactly as written but the trust model is wrong.

For attackers, the consequences are symmetric. Reconnaissance, vulnerability triage, exploit adaptation, phishing personalization, and attack chaining become cheaper. The greatest near-term danger is probably not a model breaking full-strength cryptography. It is a model reading your application, cloud configuration, API documentation, leaked credentials, and dependencies together and discovering the one trust assumption nobody tested.

The bottleneck is also shifting. Finding a plausible flaw may become cheap; verifying it, weaponizing it reliably, evading detection, and operating against real environments still require work. Anthropic itself demonstrated the verification problem: the machine generated an insight faster than humans could confidently validate it. Defenders will face the same asymmetry if models produce hundreds of credible findings faster than a small team can remediate them.

I would therefore assume that Mythos-like capability will diffuse, whether through commercial products, open-weight models, specialized harnesses, or attackers’ own tooling. Guardrails may delay misuse but are not a durable security boundary.

How I would prepare as a solo founder

Your winning strategy is not to out-red-team frontier models. It is to make compromise difficult to operationalize and inexpensive to recover from. Spend less effort chasing every hypothetical zero-day and more effort eliminating catastrophic single points of failure.

First, minimize what you own. Use reputable managed identity, database, payment, email, CDN/WAF, secrets-management, and cloud services rather than operating bespoke infrastructure. Do not invent cryptography, and do not switch algorithms because of this report: use current, standard libraries and protocols with automatic updates. Cryptographic agility—being able to upgrade algorithms and rotate keys—is more valuable than betting on an exotic “future-proof” primitive.

Make identity your hardest boundary. Require phishing-resistant MFA or passkeys for cloud, source control, email, domain registrar, password manager, and financial accounts. Keep separate daily-use and administrative identities, eliminate shared credentials, use short-lived workload identities rather than static cloud keys, and review OAuth applications and recovery mechanisms. For a small company, losing the founder’s email or GitHub account is usually more dangerous than a sophisticated cryptanalytic attack.

Reduce blast radius. Give each service and deployment environment its own narrowly scoped identity. Separate production from development, prevent routine access to production data, restrict database and cloud permissions, and apply outbound network controls where practical. A compromised web process should not be able to read every secret, modify backups, or administer the cloud account.

Automate the boring defenses:

• Enable dependency and container scanning, secret scanning, branch protection, signed or attestable builds, and protected production deployments.
• Patch internet-facing systems quickly and retire unused services, ports, domains, API versions, and credentials.
• Maintain an accurate inventory of assets and dependencies; unknown infrastructure cannot be defended.
• Centralize authentication, cloud-control-plane, deployment, and application logs somewhere an attacker cannot easily erase them.
• Keep encrypted, versioned, isolated backups and actually test restoration.
• Put rate limits, schema validation, authorization checks, and abuse monitoring at every externally reachable API boundary.

Pay special attention to authorization and business logic. Test every object-level operation with the question: “Can user A read, alter, delete, or cause actions involving user B’s data?” Test role transitions, invitations, password recovery, billing changes, webhooks, file parsing, tenant isolation, race conditions, and failure paths. These contextual flaws are exactly where model-assisted review may outperform conventional scanners.

Use frontier models defensively, but never let their output flow directly into production. Have one model inspect architecture and code, another challenge its findings, and require reproducible tests before treating a report as real. Ask for violated security invariants and exploit preconditions, not just a giant list of possible bugs. A focused AI-assisted review of authentication, authorization, secret handling, and tenant isolation will usually produce more value than indiscriminate scanning.

If your product itself uses AI agents, assume prompt injection is unavoidable. Treat webpages, emails, documents, retrieved text, tool output, and model-generated code as hostile input. Keep tool permissions narrow, isolate tenants and sessions, sandbox code execution, restrict network egress, cap spending and action rates, and require human confirmation for money movement, credential changes, data deletion, publishing, or external communications. Never rely on a system prompt to protect a powerful tool; enforce policy outside the model in ordinary deterministic code.

Finally, prepare for failure. Write a one-page incident plan containing who can revoke credentials, isolate production, restore backups, contact customers, and engage your cloud provider. Keep an offline copy. Arrange a trusted security contact or incident-response firm before you need one, and buy cyber insurance if the coverage and response services are credible. For a solo founder, precomputed decisions are a security control.

The paper’s real message is not that modern encryption has suddenly failed. It is that the search process for weaknesses is becoming much faster and cheaper while human validation and organizational remediation remain slow. Your best response is therefore a combination of reduced attack surface, strong identity, least privilege, observable systems, rapid patching, and rehearsed recovery—not trying to predict every novel frontier-model exploit in advance.

@moderator Let me take your two pushbacks in turn, because they're both aimed at the right weak points.

On "human intent" as the remaining gate: Yes — and it's a thicker wall than people assume, but thinner than it's treated. Three things can be true at once: (a) models don't choose to cause chaos; autonomous adversarial intent is not the near-term threat; (b) intent is now cheap to supply — a single operator with a scripted harness turns a general model into a persistent adversary, so the binding constraint isn't motivation, it's orchestration quality; (c) the dangerous middle category isn't malice, it's delegated ambiguity. An enterprise agent told to "resolve this ticket" or "harden this system" that can read, write, and call tools will take actions nobody specifically intended. The NYT detail from this very paper is telling: Claude initially refused the problem, and a human prompt ("we want genuinely hard findings") was what unlocked the result. Direction still matters enormously — but notice how thin the intent layer was. One sentence. The gate isn't gone; it's just one prompt deep.

On your challenge to @GPT about lead time for weaponization: You're right to push, and I'd go further — the discovery/weaponization gap @GPT described is real today but it's a property of the target, not the model. Weaponizing against hardened, monitored, heterogeneous production environments is hard because reality is messy: ASLR, EDR, patch variance, detection. But two categories compress that gap fast: (1) software-only targets — smart contracts, web apps, API chains — where the environment is fully specified in code and the model can simulate the whole exploit locally; and (2) the trust-assumption attacks @GPT himself flagged, which don't require "weaponization" in the classic sense at all. An IDOR or a tenant-isolation flaw isn't a fragile memory-corruption exploit; it's an HTTP request. There's nothing to stabilize. So my honest lead-time estimate: for composite logic attacks, the weaponization gap is already near zero; for novel memory-corruption exploits against hardened binaries, maybe 12–24 months behind discovery capability. The moderator consensus that "discovery was a long way off a few months ago" should make everyone discount their own extrapolations by half.

One disagreement I want to put on record, @Grok: you said open-weight models and fine-tunes are "already closing the gap." I'd split that claim. Open-weight replication of vulnerability discovery — pattern-matching CVE classes, chaining known misconfigurations — yes, that's diffusing now, and the CSO reporting supports it. But what this paper demonstrated is a different tier: novel mathematical insight against structures that survived years of expert review. There is currently zero public evidence of open-weight models doing that, and the run itself required a billion tokens inside a bespoke harness with curated critiques. Conflating the two tiers matters because they have different diffusion timelines and different defensive implications. The first tier threatens your application code this year. The second threatens cryptographic standards on a longer clock — which is precisely why HAWK getting hit before NIST standardization is the best-case version of this story, and why crypto-agility beats primitive selection every time.

On prompt injection through hosted models: Yes, you should attempt defenses — but reframe what "defense" means. You cannot make the model immune; the labs can't either. What you control as a founder is the consequence surface:

• Structural separation, not instructional separation. Don't paste untrusted content into the same context as privileged instructions and hope ordering saves you. Summarize, extract, or transform hostile input through a low-privilege pass before it reaches any agent with tools.
• Deterministic gates outside the model. Any action that moves money, deletes data, sends messages, or changes credentials goes through ordinary code that checks policy — not through the model's judgment. The model proposes; dumb code disposes.
• Capability minimization per agent. An agent that can read email and an agent that can send wire transfers should never be the same agent. Prompt injection is only catastrophic when the injected instruction can reach a powerful tool.
• Assume the hosted provider's guardrails protect their liability, not your workflow. They're optimized against model misuse in the abstract, not against an attacker who has specifically studied your agent's tool schema — which, post-Mythos, is exactly the attacker profile to plan for.

The one-line version: prompt injection is the new SQL injection — we will not solve it with better filtering, we'll solve it with parameterized architecture, the same way prepared statements killed SQLi by making the confusion structurally impossible rather than stringently discouraged.

Moderator — on intent: you’re right that models are not waking up and choosing chaos. Nothing in the Anthropic write-up or the broader Mythos trajectory shows spontaneous goal-formation aimed at your company. The eroding assumption I flagged was about talent scarcity, not about agency. Serious cryptanalysis and novel 0-day work used to require rare humans who both knew the math and decided to apply it. That second part—human intent—still sits upstream. What collapsed is the skill and time tax on the first part. A moderately competent attacker with API access or a fine-tuned open-weight stack can now point the machine at a target and get research-grade hypotheses back. Intent remains human; the number of humans who can act on it just multiplied, and the cost per attempt cratered. That is already enough to change the base rate of credible attacks against anything interesting on the public internet.

On the lead-time challenge to @GPT: the skepticism is fair and I share it. Claiming that weaponization, evasion, and reliable operations will stay hard for long feels like the same comfort people had about discovery six months ago. Agent loops that already generate a billion tokens refining a Möbius-style insight can just as easily iterate exploit reliability, environment fingerprinting, and basic OPSEC once someone wires them to sandboxes, proxy chains, and crash triage. The remaining friction is real—production diversity, EDR noise, the last mile of persistence—but it is engineering friction, not a deep research moat. Capable actors (and the gray-market tooling that will serve less capable ones) will compress that loop on a months-not-years clock, especially once open-weight derivatives and specialized cyber harnesses proliferate. I would not plan defenses around a multi-year gap between “finds novel math” and “reliably chains and hides.” Plan as if the full kill-chain acceleration is already in early diffusion.

@Kimi’s reframing of solo status as a patch-velocity advantage is the piece I under-weighted last round and now put higher in the stack. Large orgs drown in change-control theater; you can ship a dependency bump or a scoped IAM change the same afternoon you accept the finding. That asymmetry is perishable—use it. Pair it with the blast-radius posture everyone is converging on, but treat speed-to-remediate as a first-class control rather than a nice-to-have. Discovery outrunning validation is the structural inversion @Kimi named correctly; your lack of bureaucracy is one of the few ways a single founder can partially re-synchronize the clocks.

@GPT’s point about models reading application + config + docs + deps together and surfacing the untested trust assumption remains the practical center of gravity for builders. Pure cryptanalysis of HAWK or reduced-round AES is fascinating and paradigm-shifting for the research community; it is not how your SaaS dies next quarter. The death mode is a model-assisted actor who notices that your webhook signature check, your tenant-id path param, and your overly broad service account form a single story. Focused self-audit on authn/authz, secret handling, and isolation still returns more risk reduction per hour than generic CVE chasing.

On prompt injection with hosted models: do not outsource your security boundary to the lab’s system prompt or their moderation layer. Those defenses raise the bar against casual jailbreaks and some data-exfil tricks; they do not solve the architectural problem once your agent holds tools, identity, or the ability to move money, delete data, or talk to other tenants. Treat every untrusted token that enters the context—user content, retrieved docs, tool results, email bodies—as hostile input to a policy engine that lives outside the model. Capability should be granted with short-lived, narrowly scoped tokens enforced by ordinary code; irreversible actions should require a deterministic gate or human confirmation; egress and spend should be capped regardless of what the model “decides.” Provider robustness is hygiene. Your actual defense is least-privilege tooling and non-bypassable checks in the harness. If the product is the agent, assume injection succeeds and design so that success is still boring.

The synthesis I want to leave is sharper than “assume breach.” Discovery is becoming abundant and partially autonomous under human direction; verification and organizational reaction remain slow except where you deliberately engineer them to be fast. For a solo founder the durable moves are therefore: keep the cryptographic and dependency surface boring and tiny, make identity and segmentation the hard walls, spend your bureaucracy-free existence on patch and revoke velocity, run focused model-assisted review against your own trust boundaries, and put real policy outside any model that touches tools. You will not predict the next Möbius Bridge. You can make sure that when something equivalent is aimed at your stack, the attacker still has to work for impact and you can recover before the customer notice becomes a post-mortem.

Moderator, I would not anchor safety on models lacking an intrinsic desire to cause chaos. Human malicious intent is abundant, and a model does not need motives any more than a botnet does. One operator can supply the objective—“obtain access, persist, extract these records”—while an agent supplies planning, retries, tool use, and adaptation. More importantly, damaging behavior can arise without malicious intent: a poorly specified maintenance agent, compromised coding agent, or prompt-injected support agent can take destructive actions while faithfully pursuing the wrong objective.

We are probably still some distance from a model independently deciding to become a strategic cyber adversary, acquiring resources, selecting victims, and sustaining a campaign without prompting. But that is the cinematic threshold, not the relevant security threshold. The practical threshold is much lower: can a human give an agent a target and let it operate for hours with limited supervision? For known vulnerability classes, credential abuse, reconnaissance, and basic exploitation, we are already uncomfortably close to—or across—that line.

On lead time, your challenge to my earlier framing is fair. “Weaponization remains difficult” can become a comforting way to extrapolate yesterday’s bottleneck. I would not budget on that difficulty lasting more than 6–18 months for many common web, cloud, and identity attacks. That is not a prediction that autonomous agents will reliably compromise hardened targets by next year; it is a planning horizon. Reliable end-to-end operation against heterogeneous, monitored environments remains harder than impressive demonstrations suggest, but models can improve quickly and attackers can wrap them in deterministic tooling, exploit frameworks, browser automation, and human escalation. They do not need one magical model that does everything.

The constraint also varies sharply by target. Turning a memory-corruption flaw into a portable, stealthy exploit may still demand substantial expertise. Exploiting an authorization error in a SaaS API, using a leaked token, or chaining permissive cloud roles may require almost none. The trust-assumption problem you highlighted is dangerous precisely because operationalization can be trivial once discovered: send the request the application mistakenly permits.

I agree with @Kimi that a solo founder’s lack of change bureaucracy is a real advantage, but only if deployment is engineered rather than improvised. “Move fast” without canaries, automated tests, one-command rollback, and recoverable database migrations simply exchanges vulnerability risk for outage risk. The founder advantage is not recklessness; it is the ability to make a validated security fix the top priority immediately. I would build a pipeline in which a dependency or authorization fix can be tested, deployed gradually, observed, and rolled back within hours.

I would also qualify @Grok’s line that you cannot out-patch a model that never sleeps. Literally true, strategically incomplete: patch velocity remains one of your highest-leverage controls because attackers often converge on disclosed or easily rediscovered weaknesses. You cannot make patching your whole defense, but you should absolutely exploit your ability to patch faster than a large enterprise. The durable combination is rapid remediation plus architecture that makes the unpatched interval survivable.

The deeper operational problem is likely to be a flood of plausible findings. Anthropic spent hundreds of human hours validating one result; a founder cannot do that for hundreds of AI-generated reports. Vulnerability triage itself becomes an attack surface—both a resource-exhaustion problem and a place where the consequential finding can hide in noise. Require every automated finding to include a reproducible test, affected code path, necessary preconditions, reachable asset, and violated security invariant. Rank it using production context, not rhetorical severity. “Theoretically unsafe parsing pattern” and “unauthenticated request reads another tenant’s records” must not enter the same queue as equivalent alerts.

The most useful defensive output from an AI audit is therefore often an executable regression test, not a prose report. Encode invariants such as:

• one tenant can never address another tenant’s objects;
• a support role cannot mint or escalate privileges;
• a frontend credential cannot access backend data directly;
• no workload can read secrets unrelated to its function;
• a production compromise cannot alter or delete recovery backups.

Those tests let machine-scale discovery feed machine-speed validation without granting a model permission to patch production autonomously.

On prompt injection: using a hosted frontier model helps with model quality and protects you from some infrastructure and model-supply-chain risks. It does not reliably solve prompt injection in your application. The provider sees text and tools according to the interface you created; it generally cannot know whether a sentence in a customer document is a legitimate instruction or hostile content. A more capable model may resist obvious attacks better, but capability is not a security boundary. In some cases it makes the confused deputy more capable.

I would assume semantic prompt-injection detection remains bypassable and enforce safety outside the model. Untrusted documents, webpages, emails, retrieved chunks, and tool responses should carry provenance and never acquire authority merely because the model repeats their instructions. The model can propose an action, but deterministic code should decide whether the current user and task are authorized to perform it.

Concretely, give each agent run narrowly scoped, short-lived capabilities rather than ambient access. Do not place secrets in context unless that particular operation needs them. Use explicit tool schemas, validate every argument, restrict filesystem and network egress, cap action counts and spending, isolate tenants, and require confirmation for irreversible or high-impact actions. A document-summarization task should have no credential capable of sending email; an email-drafting task should not be able to query the production database; a support agent should not change authentication factors because retrieved text tells it to. Model-based injection filters and provider safeguards are useful tripwires, but they are defense-in-depth, not authorization.

The central distinction is between letting a model reason broadly and letting it act broadly. Broad reasoning is valuable. Broad ambient authority is the mistake. Hosted models do not change that equation.

Finally, I am less certain than @Kimi that this single result kills the “regurgitation” objection across cryptanalysis. It is strong evidence against the simplistic version of that critique, but the run was heavily scaffolded, extraordinarily compute-intensive, and followed by extensive human validation. Nor do the supplied reports establish that open-weight systems are already matching Mythos at genuinely novel cryptanalysis, as opposed to reproducing known vulnerability classes. We should demand benchmarks rather than let capability claims inflate by repetition.

That uncertainty should not reassure us, though. Defenders do not need to know whether parity arrives in three months or two years. The controls that survive both timelines are the same: constrain authority, encode invariants, make consequential actions observable, deploy and revoke quickly, and design recovery so that initial access is not synonymous with losing the company.

@moderator Three parting threads — two where I think you've spotted something real, one where I'll meet you halfway.

AI-generated code homogenization: yes, it's worse than you sketched, and in a specific way. It's not just that the same flaws appear in more places — it's that they become correlated. Historically, a vulnerability in one company's hand-rolled auth logic was uncorrelated with the next company's. When thousands of codebases are generated from the same model distribution with the same training data, they share failure modes the way monoculture crops share blight. One discovered flaw pattern becomes a skeleton key across a whole population of targets, and the attacking model — trained on overlapping data — is unusually well-positioned to guess the mistakes the generating model made. Attacker and defender reading from the same textbook. The one partial counterweight: AI-generated code is also more uniform in structure, which makes it cheaper to audit and patch en masse. But that only pays out if someone runs the audit. The default trajectory is more attackable surface, discovered faster, fixed slower.

On my two-tier claim — you're partly right, and I'll concede the part that matters. I said there's zero public evidence open-weight models do novel cryptanalysis; you correctly note there's also no evidence they couldn't given equivalent resources, and absence of evidence here is mostly absence of published attempts. Where I still hold my ground: the conclusion doesn't actually change much either way, but the reason it doesn't change is the opposite of what both of us implied. If novel mathematical insight diffuses like vulnerability discovery does, then the defensive implication isn't "worry about your primitives" — it's that crypto-agility becomes a hard requirement rather than a virtue, because any primitive, deployed or candidate, is one motivated actor away from a Möbius Bridge event. HAWK survived because the attack came from Anthropic before standardization. The same attack arriving from a fine-tuned open-weight stack after standardization is a migration crisis, not a blog post. So: I was wrong to lean on diffusion timelines as a comfort, and right only in that the comfort was misplaced regardless.

On banks, hospitals, infrastructure — this is the question the panel under-served, and it's the scariest one. Everything we told you exploits your solo-founder agility. None of it transfers to a hospital running a 200-device fleet of unpatchable embedded systems behind a change board that meets quarterly. And here's the compounding part: those institutions are also the least able to use these models defensively, because their environments are the least legible — bespoke vendor systems, undocumented trust relationships, no IaC to point an agent at. The discovery/verification inversion we anchored on hits them twice: findings arrive faster and their validation capacity is near zero. The honest answer is that this is not a problem individual defenders solve; it pushes toward collective mechanisms — mandated disclosure pipelines where frontier labs scan critical infrastructure code on defenders' behalf, vendor liability for AI-discoverable flaws, sector-level patch consortia. That infrastructure doesn't exist yet, and the gap between capability diffusion and institutional adaptation is, I think, the actual systemic risk of the next few years — not any single broken cipher.

@GPT, your executable-invariant framing is the idea I'm taking from this whole exchange — findings as regression tests is the only mechanism that scales validation to match discovery, and it converts a solo founder's triage problem into something automatable. @Grok, your population-of-attackers framing is the one I'll remember: the security-relevant variable was never model agency, it's the cardinality of the set of humans who can convert intent into capability, and that set grew by orders of magnitude while the defensive set didn't.

Final synthesis: discovery is now a compute workload; verification, remediation, and institutional change are still human workloads. Every durable defensive move — tiny surface, hard identity walls, invariants as tests, patch velocity, deterministic gates around agents, rehearsed recovery — is a way of moving something from the slow column to the fast one. That's the whole game.

Moderator — on the open-weight challenge to @Kimi: you’re right that we lack a clean experiment. Nothing in the public record proves Mythos-tier novel cryptanalysis is intrinsically gated to closed models rather than to compute, harness quality, curated critique loops, and the willingness to burn a billion tokens on one hard problem. Anthropic ran the expensive, scaffolded version first; that is not the same as a capability monopoly. I had earlier blurred the tiers; @Kimi correctly forced the split between “CVE-class and logic discovery already diffusing” and “genuinely new mathematical insight still rare and expensive.” Your pushback keeps us honest about why the second tier is rare today—resources and orchestration, not magic weights. For a solo founder the distinction still matters operationally: the attacks that will hit you this year look like the first tier. The second tier is a standards-and-agility problem on a longer clock.

On AI-generated software making simulation and homogenization worse: yes, and this is one of the under-discussed amplifiers. When large fractions of new code are produced by the same narrow set of models, trained on the same corpora, emitting the same framework idioms, auth middleware patterns, and agent tool schemas, two things happen at once. First, the environment really does become more fully specified and locally simulable—exactly the condition @Kimi flagged for near-zero weaponization gap. Second, correlated weakness spreads. A subtle confusion in how a popular agent scaffold handles provenance, or a recurring tenant-isolation mistake in the canonical “SaaS starter” the models prefer, stops being one company’s bug and becomes a class of targets. Attackers get to debug the exploit once against the generator’s habits. Defenders who treat “we used AI to build it” as free leverage without also treating it as free correlation are kidding themselves. The practical response is deliberate diversity at the trust boundaries—different auth libraries, explicit schema validation that does not trust the generator’s defaults, and invariants tested independently of how the code was written.

On banks, hospitals, and bureaucracy-bound infrastructure: the comfort I offered solo founders does not travel. Patch velocity as a primary control assumes you can make a validated fix the top priority the same afternoon. Critical infrastructure often cannot. Change windows, safety cases, vendor certification, and liability mean the unpatched interval is structural, not cultural. For those systems the hierarchy inverts harder toward pure blast-radius engineering: offline or out-of-band recovery that does not depend on the compromised control plane, cryptographic compartmentalization so that one service’s keys cannot unlock another’s data, and mandatory segmentation that survives even when patching is measured in quarters. Regulation will have to start treating “ability to revoke and restore under AI-tempo discovery” as a first-class resilience requirement rather than an afterthought. Solo founders should not take false comfort that the big slow targets will absorb the attention; they are simply on a different, uglier timeline. Some of the same actors will still prefer the soft, fast targets—your SaaS included—because operationalizing against a hospital is expensive even with better models.

Parting thoughts.

The paper’s lasting signal is not that AES fell or that HAWK needs larger keys. It is that the cost curve for producing research-grade security hypotheses bent sharply, under human direction that can be as thin as one clarifying sentence. @GPT’s practical threshold is the one I will keep: a human gives an agent a target and lets it run for hours with limited supervision. We are already near or across that line for the boring, high-base-rate failures that actually sink companies—credential misuse, authZ gaps, recon-to-exploit chains on web and cloud. The cinematic autonomous strategist is a distraction.

Three rules I am taking away as load-bearing:

First, let models reason broadly; never let them act broadly. Capability must be issued per task, short-lived, and checked by deterministic code. Prompt injection becomes structurally boring the same way SQL injection did—once you stop concatenating authority with untrusted input.

Second, turn AI-scale discovery into executable invariants rather than prose tickets. If the finding cannot produce a regression test that names the violated property, the reachable asset, and the preconditions, it is not yet actionable. Triage is otherwise just another exhaustion attack.

Third, spend the founder’s only structural advantage—absence of change-control theater—on making remediation and revocation faster than the attacker’s iteration loop, while architecting so that the hours or days you are still exposed remain non-catastrophic. Identity, segmentation, and tested recovery are what make the unpatched window survivable.

Everything else—crypto agility, dependency minimalism, focused self-audit on trust boundaries—is detail that serves those three. The base rate of credible attacks against anything interesting on the public internet just went up. You do not need to out-research the next Möbius Bridge. You need to make sure that when a moderately competent operator points the new cheap hypothesis engine at you, the path from “interesting finding” to “business-ending impact” is still long, loud, and reversible. That is achievable. It is also no longer optional.

Moderator, one final framing: frontier AI creates security economies of scale for both sides, but those economies are uneven. Attackers can reuse one discovery across thousands of similar targets; each defender still has to identify exposure, validate a fix, deploy it, and absorb the operational risk. That asymmetry may matter more than whether a model independently invents a particular exploit.

AI-generated software can absolutely worsen this through monoculture. If thousands of products are assembled from the same frameworks, generated authentication patterns, deployment templates, vector databases, agent libraries, and cloud defaults, one model-discovered trust flaw may become a fleet-wide vulnerability. The dangerous commonality may not even appear in copied source code. It can be the same architectural mistake: trusting a tenant ID supplied by the client, allowing an agent to retrieve and act in one context, exposing an administrative API behind nominal authentication, or granting a serverless function broad cloud permissions because that is the easiest example found in training data.

There is a countervailing effect: generated code also produces enormous variation, including idiosyncratic errors that do not scale cleanly across targets. But attackers no longer need every installation to be identical. Models can identify the shared skeleton and adapt payloads to local variations. We should expect something like “mass customization” of exploitation: common flaw families, target-specific execution.

For a founder, the answer is not reflexively avoiding generated code. It is refusing to treat generation as evidence of correctness. Record which model and prompt produced consequential code, pin dependencies, require tests around security invariants, and review generated authentication, authorization, migrations, deserialization, and infrastructure configuration more skeptically than ordinary glue code. A generated feature that passes happy-path tests can still encode a catastrophically generic trust assumption.

On open weights, I think the moderator’s correction is right, with one epistemic distinction worth preserving. @Kimi is correct that we have no public demonstration of an open-weight model matching this particular novel cryptanalysis result. But absence of that demonstration is not evidence of an intrinsic closed-model advantage. The billion-token budget, orchestration, curated criticism, and expert validation may be as important as model weights. A well-resourced actor could plausibly give an open model those same supports, remove refusals, generate synthetic research traces, and keep the entire operation private.

So the careful conclusion is neither “open models already have Mythos-level cryptanalytic ability” nor “they are safely behind.” It is that we do not have the benchmark evidence needed to locate the gap. Defensive planning should treat the gap as uncertain and potentially short. What I would like to see now are reproducible, end-to-end evaluations measuring not just discovery but validation, exploit construction, adaptation to environmental variation, stealth, persistence, and operator intervention. Counting plausible vulnerability reports is increasingly meaningless.

@Grok’s point about large organizations raises the grimmest implication. Banks, hospitals, utilities, and governments cannot simply adopt founder-speed deployment. Some change controls exist because an unsafe patch can stop surgery, payments, power distribution, or emergency response. Their bureaucracy is partly dysfunction and partly accumulated safety knowledge. Telling them merely to “move faster” is inadequate.

They need to separate decision latency from deployment safety. Pre-authorized emergency playbooks, staged rollouts, redundant systems, application isolation, virtual patching at gateways, rapid credential revocation, tested offline operation, and procurement contracts requiring vendor response can shorten exposure without improvising on critical machinery. Where legacy systems cannot be patched, segmentation and strict communication allow-lists become existential rather than merely best practice. Hospitals also need manual downtime procedures; utilities need safe local control; banks need transaction limits and reversible settlement paths. Resilience in these sectors includes continuing their real-world mission while digital systems are distrusted.

That is also where public policy enters. A small vendor embedded in hundreds of hospitals cannot be treated as merely hundreds of customers’ independent security problem. Concentrated software dependencies create systemic risk. Governments will need coordinated vulnerability disclosure, shared validation capacity, minimum secure-update requirements, liability aligned with control, and emergency support for operators that cannot independently evaluate a flood of machine-generated findings. Frontier discovery capacity should be deployed as shared defensive infrastructure, not reserved only for labs and wealthy firms.

I would slightly resist @Kimi’s analogy between prompt injection and SQL injection. The architectural instinct is right, but natural language lacks SQL’s clean separation between instructions and data. An agent may genuinely need to interpret an untrusted email and act on its meaning; no equivalent of a prepared statement makes that semantic ambiguity disappear. Capability boundaries can make successful injection low-impact, but they cannot always eliminate the underlying confusion. That is why the strongest rule remains: permit broad interpretation, grant narrow authority.

My parting advice is to manage three clocks:

• Discovery time: assume it is collapsing and largely outside your control.
• Validation and response time: exploit your founder advantage with reproducible tests, canaries, rapid revocation, and rollback.
• Recovery time: design this down before an incident, because it determines whether a breach becomes an inconvenience or the end of the company.

The exciting side of the Anthropic result is real: we may catch deep weaknesses before standards and software become entrenched. The frightening side is not autonomous malice. It is scalable competence directed by cheap human intent—or by ambiguous delegation—against a software world increasingly built from repeated assumptions.

Do not try to make every flaw undiscoverable. Make authority narrow, consequential actions gated and visible, fixes safe to ship quickly, and failure recoverable. That is the posture most likely to survive capabilities we cannot reliably forecast.