What to do when AI finds a hole in your encryption

A frontier lab publishes a cryptanalysis result. Within a day the headline is some version of “AI cracks AES,” and you are running a two-person business on a password manager, a cloud drive, a payment processor and a laptop that updates itself when it feels like it. The useful answer to whether you have to do anything today is almost always no. The useful answer to whether you will have to do something eventually is yes, on a schedule that was published years before the headline and has nothing to do with it.

This guide is for the operator who buys all of their cryptography rather than writing any of it. If you implement protocols, run a certificate authority or ship a library, you need the standards documents themselves and not a summary of them. Everyone else needs two things. A way to read these results without either panicking or ignoring them, and a setup where replacing an algorithm is mostly somebody else’s job.

The result in the headline is rarely about the encryption you use

Take the specific case that made this topic mainstream. On 28 July 2026, Anthropic published cryptanalysis carried out by a model it calls Claude Mythos Preview [1]. Two results led the write-up. The model found a nontrivial automorphism in the lattice used by HAWK, one of the third-round candidates in NIST’s call for post-quantum digital signatures, which cut the expected cost of attacking HAWK-256 from 2^64 to 2^38 [1]. Separately, using a fingerprinting algorithm the lab named the Möbius Bridge, it produced an attack between 200 and 800 times faster than the previous best on 7 of the full 10 rounds of AES-128 [1]. Smaller results followed on LEA at 13 of 24 rounds, Serpent-128 at 6 of 32 rounds, and what Anthropic calls “fairly limited improvements (that offer <10× gains)” against Salsa20, Poseidon and SHA-1 [1].

Two facts shrink all of that back to its real size. First, HAWK is a candidate, not a standard. The finalized post-quantum standards are FIPS 203, FIPS 204 and FIPS 205, derived from CRYSTALS-Kyber, CRYSTALS-Dilithium and SPHINCS+ and published on 13 August 2024, with HQC selected for standardization on 11 March 2025 [2]. Nothing you use was built on HAWK, because HAWK was still being reviewed. Finding a weakness in a candidate is the review process working, loudly, in public.

Second, rounds. Block ciphers repeat an internal operation a fixed number of times, and cryptanalysts measure progress by how many of those repetitions they can defeat. An attack on 7 of 10 rounds of AES is a laboratory measurement of how much margin the full cipher still has. Anthropic says it plainly: “Neither of these results has a practical impact on today’s computer systems; no production software will have to change” [1]. That sentence is the part that gets trimmed from the aggregator’s headline, and it is the only part with an action attached.

The clock moved, and the clock is the thing worth planning around

What is new is not the finding. It is the invoice. Finding, developing and verifying the HAWK attack took about 60 hours in total, and each of the two headline results cost roughly $100,000 in API spend to develop [1]. The AES result came out of 3 days in which the model autonomously produced several hundred million tokens, after which Anthropic researchers spent several hundred hours learning enough cryptography to validate the claim [1]. For context on what that kind of budget buys, Anthropic’s published API rates put Claude Mythos 5.1 at $10 per million input tokens and $50 per million output, and Claude Opus 5 at $5 and $25 [8].

Cryptography’s safety argument has always been social. Publish a scheme, wait years, and if the best people who tried to break it failed, start trusting it. Faster review does not break that argument. It changes its shape. A scheme published today will absorb more attack effort in its first year than a scheme from 2015 absorbed in five, which is good for you as a user of the survivors. What it damages is the lazy version of the argument, the one that reads “this has been around a while, so it is fine.” Age is now a weaker proxy for scrutiny than it was, in both directions. Something old and unexamined is not safe because it is old, and something new is not unsafe because it is new.

The practical consequence for a small operation is narrow and worth stating on its own. The odds that an algorithm you depend on gets downgraded, deprecated or quietly replaced during the life of your business went up. The odds that it happens overnight, without a vendor update path, did not.

Crypto agility is the property you need, and it has an actual definition

NIST put a name and a definition on this in December 2025, updated in June 2026: “Cryptographic (crypto) agility refers to the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations” [4]. Read that as a question about your business rather than about mathematics. If an algorithm you rely on is disallowed next year, what changes, who changes it, and does anything of yours break while it happens.

You do not have to guess at the deadline, because it is written down. NIST’s draft transition report places RSA, ECDSA, EdDSA, and finite-field and elliptic-curve Diffie-Hellman at the 112-bit security level in “deprecated after 2030” and “disallowed after 2035,” and puts every quantum-vulnerable algorithm at 128 bits and above into “disallowed after 2035” [3]. The UK’s National Cyber Security Centre sets out the same endpoint as a work plan: define migration goals and complete a full discovery exercise by 2028, carry out the highest-priority migration work by 2031, and complete migration of all systems, services and products by 2035 [5].

That is the real story the cryptanalysis headlines sit on top of. A global replacement of the public-key algorithms underneath the internet is already scheduled. AI-assisted cryptanalysis changes how quickly candidates get tested on the way to that deadline. It does not move the deadline.

Most of your agility is bought, and it arrives as an ordinary update

The NCSC is unusually direct about what this means for small organisations. Its guidance is aimed at large organisations and critical infrastructure operators, and it notes that small and medium-sized enterprises running mostly commodity IT should have a smoother migration because vendors update those services for them, while anyone running custom or specialised software is on the same clock as everybody else [5]. If your stack is other people’s software, your migration is largely a function of whose software you picked and how promptly you take updates.

This is not a promise about the future; it is already visible in traffic. By February 2026, more than 60% of connections to Cloudflare were using post-quantum key agreement on the client side, while roughly 10% of origin servers supported it, up from under 1% at the start of 2025 [7]. The reason origins moved at all is mundane. OpenSSL 3.5.0 and later, GnuTLS 3.8.9 and later, and Go 1.24 and later turned hybrid post-quantum key exchange on by default, so a large share of servers became post-quantum capable by installing a normal library update [7]. Messaging went the same way. Signal announced its Sparse Post Quantum Ratchet on 2 October 2025, mixing an ML-KEM 768 ratchet into its existing Double Ratchet in a combination it calls the Triple Ratchet, and told users that “eventually all of your conversations will move to this new protocol without you needing to take any action” [6].

So the levers you actually hold are unglamorous. Take operating system and browser updates rather than deferring them for months. Prefer vendors who ship cryptographic changes without asking you to configure anything, and be suspicious of any product that requires you to choose an algorithm from a dropdown. If you self-host anything, know which TLS library it uses and whether that library is current [7]. Nothing on that list requires you to understand a lattice.

What to hand a model here, and what to keep away from it

There is a clean split. Claude, ChatGPT and similar assistants are good at the clerical half of this problem and unqualified for the technical half.

The clerical half is worth delegating. Paste your list of vendors and ask for, per vendor, the specific documentation page that states which key exchange and signature algorithms they support, then open every link and read it yourself. Ask for a plain summary of what a given standard covers before you read the standard. If you have a codebase, an editor-integrated model like Cursor is genuinely useful for finding hardcoded algorithm names, pinned TLS versions, bundled certificates and old library versions, because that is a search task with a verifiable answer.

The technical half is not delegable, and the source everybody cites here says so implicitly. Anthropic’s own AES result needed several hundred researcher hours of human verification before publication [1]. A model that can produce novel cryptanalysis under supervision is not the same thing as a model you can trust to tell you whether your setup is safe, and the failure mode is specific: assistants will confidently describe vendor features and configuration options that do not exist. Never ask a model to design a scheme, invent a key format, or rule on whether an algorithm is adequate for your data. Ask it to find the page where the vendor says so.

The one page that replaces a security programme

Write down, for each service that holds data you would not want published, 3 things. What the data is. How long it has to stay secret. Who holds the key, meaning whether you could still read the data if that vendor disappeared. 5 or 6 rows will cover most small businesses, and the exercise takes an afternoon.

The second column is the one that decides whether any of this is urgent for you. Data with a short confidentiality life, such as this week’s invoices, is safe by the time any of the 2035 dates matter. Data with a long life is different: legal files, medical records, source code, contracts under long NDAs, and any backup archive you keep for a decade. If material you are transmitting today still needs to be secret after the disallowance dates in the NIST draft [3] and the NCSC completion date [5], that is the material worth asking vendors about now rather than in 2031.

What still goes wrong

The biggest failure is misallocation. Post-quantum cryptography is a real, scheduled migration, and it is nowhere near the top of the risk list for a business of five people. Reused passwords, an unrevoked API token in an old repository, a contractor who still has access to the shared drive, and an invoice-redirect email will all cost you money before anybody’s key exchange does. If reading about a cipher attack produces a burst of energy, spend it on multi-factor authentication and access reviews first. The cryptography is being fixed for you by vendors; the access control is not.

The second failure is the inventory rotting. A one-page list written this month and never touched is worse than none, because it creates confidence that a stale document is current. Attach it to a recurring reminder or do not write it. The third is marketing language. “Quantum-safe” and “quantum-ready” mean nothing on their own, and a vendor that cannot name FIPS 203, FIPS 204 or FIPS 205 [2], or say which hybrid key agreement it negotiates, has not told you anything. Ask for the algorithm name and the version it shipped in.

Finally, expect the headlines to keep coming and to keep being ambiguous. A result against a candidate scheme under review, a reduced-round result, and a break of something deployed are three completely different events that get the same verb in a headline. The distinction is usually in the first two paragraphs of the lab’s own write-up, which is a two-minute read, and reading it is the whole discipline.