What Anthropic Actually Did
Last week Anthropic published results from a research experiment that’s worth reading carefully. They ran Claude Mythos Preview — their most capable model — for 60 hours in a multi-agent harness, tasked with finding cryptographic weaknesses. The cost: approximately $100,000 in API calls. The outcome: genuine mathematical weaknesses found in HAWK, a post-quantum signature scheme that was a NIST candidate, and in a reduced-round variant of AES.
This wasn’t a capture-the-flag exercise with known answers. The weaknesses Claude found were real, subsequently verified by cryptographers at ETH Zurich, Tel Aviv University, and the University of Haifa. The model wasn’t pattern-matching against training data — it was doing novel mathematical reasoning.
I want to unpack what this actually means for those of us building production systems, because the knee-jerk reactions on both ends (“AI will replace cryptographers” vs “this is just a stunt”) both miss the point.
What Made This Work
The key word in the Anthropic writeup is “harness.” Claude didn’t just get a prompt saying “find weaknesses in HAWK.” The research team built a multi-agent orchestration layer with:
- Verification pipelines the model itself constructed: when it hypothesized a weakness, it built tooling to test the hypothesis before reporting it
- Human-in-the-loop checkpoints at strategic points — notably, the model needed human prompting to keep going when it hit difficult sections rather than giving up
- Extended compute budget: 60 hours of continuous operation, not a single API call
The last point matters most for how I think about this. We’re not talking about a model that solves hard crypto problems in a chat session. We’re talking about a model with enough compute, the right scaffolding, and the right checkpoints to do the kind of sustained mathematical work that normally takes a PhD student months.
# Simplified sketch of what the harness likely looked like
async def crypto_research_harness(target_algorithm, budget_hours=60):
hypotheses = []
while not budget_exhausted(budget_hours):
# Generate next hypothesis
hypothesis = await claude.think(
context=build_context(target_algorithm, hypotheses),
task="Identify potential mathematical weakness"
)
# Model builds its own verification
verifier = await claude.implement(
task=f"Write code to test: {hypothesis}",
language="python"
)
result = await run_verification(verifier)
if result.is_promising:
hypotheses.append(hypothesis)
# Human checkpoint before escalating
if await human_review(hypothesis, result):
return hypothesis
# Model decides next direction
next_direction = await claude.reflect(
failed_hypotheses=hypotheses,
task="What should we try next?"
)The architecture is basically what we’ve been calling “agentic coding” applied to mathematical research. Tool use, self-verification, iteration. The novelty is the domain.
What This Changes for Security Engineering
Here’s my honest assessment as someone who builds systems that need to stay secure:
Defensive timelines have compressed. If a model can find weaknesses in a NIST post-quantum candidate in 60 hours with $100K compute, the same approach will get cheaper and faster. Moore’s law applies here. What costs $100K today costs $10K in a few years.
This doesn’t mean “crypto is broken.” HAWK was a candidate — NIST evaluates many before standardizing. The weaknesses found were in specific variants, not the final standard. Reduced-round AES findings are a well-studied research area, not a practical attack on AES-256. Your production systems using standard, audited cryptography are not at risk from this paper.
But the research tooling is the story. The real implication isn’t “Claude broke crypto.” It’s that the kind of adversarial mathematical analysis that previously required a well-funded research team with deep domain expertise now has a credible automation layer. That changes who can do this work.
What Security Teams Should Actually Do
Don’t panic about your AES encryption. Seriously. Standard implementations of well-audited algorithms are fine. This research targeted variants specifically chosen to have reduced security margins — that’s how this kind of academic work is designed.
Do think about your algorithm selection process. If you’re evaluating post-quantum migration paths (and you should be, given NIST is finalizing standards now), the fact that AI-assisted cryptanalysis is viable changes your risk model. Candidates with narrower security margins are now at higher risk than they were two years ago.
Consider adversarial AI in your threat modeling. The more interesting implication isn’t Anthropic doing this — it’s that a sophisticated attacker with significant compute could apply the same approach to find weaknesses in proprietary cryptographic implementations. Custom crypto (which you shouldn’t be doing anyway) just got riskier. Standard, peer-reviewed algorithms got comparatively safer.
Watch the harness, not just the model. The architecture that made this work — self-verifying agents, sustained compute, human checkpoints for direction-setting — is the template. When evaluating AI-assisted security tooling, ask whether it’s built with this kind of verification loop or whether it’s just asking an LLM and trusting the answer.
The Part That’s Easy to Miss
There’s a detail in the Anthropic write-up that I think is the most important sentence: “the model needed human prompting to keep going when it hit difficult sections rather than giving up.”
This is not a limitation. This is the actual insight about how these systems work right now. Claude Mythos, given sufficient compute, can do genuine mathematical research. But it doesn’t have the kind of sustained goal-directedness that would let it work autonomously for 60 hours on a hard problem without getting stuck. The human-in-the-loop isn’t a safety guardrail — it’s a functional component of what makes this work.
That’s the right mental model for AI-assisted technical work right now: the AI provides capability (broad search over hypothesis space, rapid verification, sustained attention to detail), the human provides direction (what direction to push when stuck, when a finding is significant enough to escalate).
Applied to your team: the teams who will use AI effectively for security research, code auditing, and vulnerability analysis aren’t the ones who prompt the model and trust the output. They’re the ones who build the harnesses — verification loops, checkpoints, human-AI decision points — that make the AI’s capability reliable.
Practical Takeaway
If you’re a Tech Lead thinking about what this means practically:
-
Your current crypto stack is fine. Keep using TLS 1.3, AES-256-GCM, and wherever possible the algorithms NIST has finalized for post-quantum. Don’t migrate to anything non-standard based on this paper.
-
Start your post-quantum migration planning if you haven’t. Not because of this research specifically, but because the window for migration is measured in years and the relevant NIST standards are now final or close to it.
-
Think about AI-assisted code review for security-critical code. The same harness architecture that found crypto weaknesses — model generates hypothesis, model verifies hypothesis, human reviews significant findings — is applicable to security auditing of your own codebases. Not as a replacement for human security review, but as a first-pass that expands coverage.
-
Don’t build custom crypto. This was already the rule. It just became more urgent.
The research is genuinely impressive. The implications are real but measured. The most important thing it demonstrates is that agentic AI, given the right scaffolding and compute, can do sustained technical work in domains that previously required deep human expertise. That’s a capability change, and it’s worth taking seriously — not panicking about.
Thuận Lương is a Technical Lead with 15+ years of experience in .NET, cloud architecture, and AI systems. He writes about lessons learned building real production systems.