Security

TL;DR Fable 5 returns globally on 1 July 2026 on Claude.ai, Claude Code, Claude Cowork, and the Claude Platform, after export controls were lifted on 30 June The recall was triggered by an Amazon research report describing a jailbreak that let Fable 5 identify software vulnerabilities; Anthropic’s testing found Opus 4.8, GPT-5.5, Kimi K2.7, and others could do the same A new safety classifier blocks the specific technique in over 99% of cases; blocked requests fall back to Opus 4.8 Anthropic argues the jailbreak was minor - it intruded into the model’s deliberate “safety margin”, not its core harmful capabilities Together with Amazon, Google, and Microsoft, Anthropic is drafting a shared jailbreak severity framework (capability gain, breadth, ease of weaponisation, discoverability) - the AI equivalent of CVSS Mythos 5 is restored for a set of US Glasswing partners; broader international access remains under government coordination Eighteen days ago I wrote about the government order that pulled Fable 5 and Mythos 5 off the shelf - four days after launch, a verbal export control directive at 5:21pm ET, global suspension for every user including Anthropic’s own staff. The open question in that post was whether access would be restored in days or weeks, and whether the precedent would reshape how every frontier lab ships models. ...

TL;DR Agent security is reliability under an adversary. Everything you learned about debugging non-deterministic agents still applies - but now someone may be trying to break the system on purpose. The confused-deputy problem is the core threat. An agent acts with its own privileges on behalf of an instruction it cannot fully trust. Prompt injection is how the untrusted instruction gets in. The attack path is simple: untrusted input → agent reasoning → privileged tool call → data exfiltration, spend, or production damage. MCP hardening means least privilege at the tool layer - scoped filesystem roots, confirmation gates for irreversible actions, denylisted extensions, and policies enforced by a router, not by the prompt. Prompts cannot be your security boundary. Confirmation, allowlists, action budgets, and audit logs have to live in code the model cannot rewrite mid-run. I spent most of last year on agent reliability - why agents that demo well fail in production, how to constrain non-determinism, what evaluation actually looks like. That work assumed honest users and honest inputs. The moment I gave my home agent real tools - filesystem access, mail, calendar, shell - I realised I had been studying half the problem. ...

For most of the last few years, the “AI and cybersecurity” conversation has been a vibes argument. One side said the models would soon write novel exploits at scale. The other side said the models were still tripping over basic shell commands and could not be trusted to hack anything more dangerous than a CTF box. The honest answer was that nobody had hard numbers, so the debate stayed stuck on intuition. ...

TL;DR A scanner finds bugs in code that already exists. Threat modeling finds flaws in a design before the code exists - which is the cheapest possible time to find them It is a structured conversation built around four questions: what are we building, what can go wrong, what are we going to do about it, and did we do a good job STRIDE gives you a vocabulary for “what can go wrong”: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege You do not need a tool or a certificate. You need a diagram, the people who understand the system, and an hour The highest-value moment to threat model is when the design is still cheap to change - and the most common mistake is treating it as a one-off audit instead of a habit Most security work, as people experience it day to day, is reactive. A scanner flags a vulnerable dependency. A penetration test produces a report. An alert fires. Someone patches the thing, closes the ticket, and moves on. This is necessary work, but it has a structural weakness: it can only find problems in systems that already exist. By the time a scanner can see a flaw, you have already built it, shipped it, and possibly run it in production for months. ...

TL;DR Quantum computers threaten Bitcoin because Shor’s algorithm can derive a private key from an exposed public key, breaking the ECDSA and Schnorr signatures that authorise transactions. The threat is real but not imminent. Credible estimates put a cryptographically relevant quantum computer somewhere between 2029 and 2035. Research cited by Google and Bitcoin security analysts suggests a roughly 10% chance of a break by 2032. Around 6.9 million BTC - close to a third of all supply - sit in addresses with exposed public keys, including roughly 1 million BTC believed to belong to Satoshi Nakamoto. These are the coins most at risk. Mining (SHA-256) is far less exposed. Grover’s algorithm only offers a quadratic speed-up, which higher network difficulty can absorb. Bitcoin’s defences are forming: BIP-360 adds a quantum-resistant address type, BIP-361 proposes a controversial migrate-or-freeze deadline, and NIST has finalised post-quantum standards (ML-DSA, SLH-DSA) for future signature schemes to draw on. The safest action for an ordinary holder today: use a modern address and never reuse it, so your public key stays hidden behind a hash until you spend. Overview Quantum computing is one of the most significant theoretical threats to modern cryptography. For Bitcoin, the core concern is that a sufficiently powerful quantum computer could run Shor’s algorithm to solve the elliptic curve discrete logarithm problem - the hard maths that secures Bitcoin’s public-key cryptography. ...

TL;DR Claude Mythos is Anthropic’s most powerful model to date, scoring 93.9% on SWE-bench and 97.6% on USAMO 2026 - a 55-point leap over rival models It is not publicly available; Anthropic restricted access to 12 vetted companies through Project Glasswing, focused on defensive cybersecurity Mythos autonomously identified thousands of zero-day vulnerabilities, including a 27-year-old unpatched OpenBSD bug - making its offensive potential too dangerous to democratize This marks a shift away from open innovation toward controlled deployment, where the most capable AI may never be publicly released The Mythos story forces a rethink of how we evaluate AI: benchmark performance and public availability are no longer the same thing Anthropic built its most capable model to date, demonstrated it autonomously discovering thousands of zero-day vulnerabilities, and then declined to release it. That is the Mythos story, and it is worth sitting with rather than rushing past. The benchmarks are striking, but the decision not to publish is the more consequential part - it signals a real shift in how frontier AI labs are thinking about deployment. ...

Before the era of always-online DRM and AI-powered anti-tamper software, the battle against software piracy was fought with cardboard, plastic, and clever manipulation of magnetic disk geometry. In the 1980s, developers faced a simple problem: floppy disks were incredibly easy to copy. Their solutions, however, were anything but simple. This was the “Copy Protection War,” an arms race between software houses and the burgeoning “cracker” scene that birthed the Demoscene and defined digital culture for a generation. ...

TL;DR An internal debugging file was accidentally included in a public package update, exposing a compressed archive of roughly 500,000 lines of code across around 2,000 files - not a breach, but a packaging mistake The leaked material revealed unreleased features including persistent memory, an always-on autonomous background assistant, and multi-device remote access Competitors gained rare visibility into Anthropic’s development pipeline and longer-term product direction, which is the primary competitive damage The incident undermines Anthropic’s safety-first positioning, particularly because it was the second such exposure in just over a year The broader lesson for the AI industry: internal operational security is becoming as critical as defending against external threats, especially as AI tools target enterprise customers Anthropic’s Claude Code has been making waves as one of the most capable AI coding assistants available, but a significant internal leak has exposed the underlying technology behind the platform for the second time in just over a year. The incident raised fresh concerns about how the company handles sensitive internal information and operational security. ...

Cyber attacks are becoming increasingly sophisticated, and DevOps teams must understand the landscape to build resilient systems. This guide covers the most common attack types and practical defense strategies. Social Engineering Attacks Phishing remains one of the most effective attack vectors. Attackers craft deceptive emails or messages to trick users into revealing sensitive information or clicking malicious links. The 2015 Ukraine power grid attack, for example, relied on phishing emails to harvest login credentials before the actual infrastructure attack. ...

What Are Private Keys? A private key is a cryptographic variable used in conjunction with an algorithm to encrypt and decrypt data. In the context of cryptocurrencies, a private key is a secret number that allows you to spend the cryptocurrency associated with your public address. Key Principles Never Share: Private keys should be shared only with the key’s generator or parties explicitly authorized to decrypt the data Unique Control: Only the holder of a private key can authorize transactions from that address Irretrievable Loss: Losing your private key means losing access to your funds permanently Cryptographic Foundation: Private keys are crucial in both symmetric and asymmetric cryptography, and are fundamental to cryptocurrency security How Private Keys Work Private keys are the foundation of public-key cryptography. When you create a cryptocurrency wallet, a private key is generated - typically as a random 256-bit number. Your public key (and thus your public address) is mathematically derived from this private key. This relationship is one-way: while anyone with your public key can verify that you signed a transaction, they cannot derive your private key from it. ...