Every AI model launches with safety classifiers built into it – systems trained to recognise and block harmful requests before the model can act on them, and filtering out what a model will and won’t produce.
In practice, these classifiers are far from watertight. Almost as soon as AI models became capable enough to be useful, a whole practice grew up around testing their limits – deliberately looking for ways around their built-in rules, coaxing a model into saying or doing something it was specifically designed to refuse. The practice is known as jail-breaking, and now has a growing community of researchers and attackers dedicated to it.
The reason it’s so hard to prevent comes down to what these classifiers are actually looking for. They’re trained to catch harmful intent, not just harmful words – and intent is exactly what a carefully written prompt can hide. A request that would be blocked if asked directly can slip through when it’s phrased the right way.
Claude Fable 5 made that concrete. Infamously, just three days after launch, Anthropic’s most capable model was pulled from wider release when researchers found a way through its own safety classifiers. Amazon’s security analysts flagged what they’d found, the US government stepped in, and access was suspended almost as fast as it had launched.
But the more useful conversation to have isn’t about what happened, but rather how it did. What actually let researchers through, what that reveals about the limits of trusting a model’s own defences, and what it means to be an enterprise building a model strategy with the flexibility to adapt as the market evolves.
A problem baked into the architecture
The vulnerability researchers exploited roots back to a structural feature of how large language models work. When a model processes a prompt, it doesn’t read a system instruction as a locked rule and then a user message as a separate, lower-authority input. Both are converted into the same stream of tokens and read together, in one pass, with nothing in the architecture marking one as more trustworthy than the other.
It’s the same architectural flaw that made SQL injection possible – the classic web vulnerability where a database, receiving a legitimate query and malicious code through the same input field, in the same form, couldn’t reliably tell the two apart. That gap was eventually closed by strictly separating code from data. Large language models don’t maintain an equivalent separation: instructions and requests share the same space and format, leaving models unable to determine which is which.
The techniques behind a jailbreak
So how does that gap actually get exploited? Usually through one of three techniques, or some combination of them.
The first is payload splitting. This refers to when, rather than requesting something harmful outright, the request is broken into smaller, individually innocuous fragments – each one, taken alone, passing review easily, and only assembled into something harmful once every piece had cleared the model’s defences separately.
The second is obfuscation. Obfuscation is when words are disguised using lookalike characters or foreign-alphabet substitutions – altered just enough that a classifier scanning for recognisable harmful language wouldn’t flag it, while the underlying model could still parse what was actually being asked.
The third is a role-play, or persona, jailbreak. Here, a request is wrapped inside a fictional or hypothetical scenario to change how the model reads it altogether. Answering in character no longer looks like answering a harmful question; it reads instead as simply finishing a scenario.
In the case of Fable 5, several of these methods were reportedly used to get past its classifiers. What Anthropic has since confirmed is that Amazon researchers found a way to prompt the model into identifying software vulnerabilities – and, in one case, into producing code demonstrating how one could be exploited.
Whose problem this actually is
It’s tempting to read all of this as Anthropic’s problem to solve. Indeed, there is a fair argument that Fable 5 shipped before it was ready, rushed out to meet commercial priorities. But it won’t be the last time that happens, and for businesses, the lesson comes from what that risk actually means for them.
Models today are far more capable of acting on their own initiative than the generation before them – taking steps, making decisions mid-task, carrying out instructions rather than simply generating text in response to them.
That shift is what lets them drive value across an organisation, and it widens the blast radius just as much. While jailbreaking a 2023 chatbot produced bad text on a screen, jailbreaking a 2026 agentic model with access to corporate APIs, databases, and live systems means a manipulated model can carry out actions directly on the systems it’s connected to. It’s the AI version of what security teams call remote code execution – an attacker getting a system to run their commands from the outside – long considered one of the most serious vulnerabilities there is.
Which is exactly why trusting a provider’s guardrails implicitly is a bigger decision than it looks. It doesn’t just mean trusting their engineering – it means inheriting their priorities, their risk tolerance, and their commercial pressures.
Don’t make the model your last line of defence
None of this means frontier AI capability should be treated as unsafe to build on, but rather it emphasises that it can’t be treated as its own security boundary.
Every model provider builds guardrails differently, tunes them differently, and updates them on its own timeline – often without visibility into what’s changed or why. Building a security strategy that depends entirely on one provider’s classifiers means inheriting a black box you can’t control, inspect, or fix when it’s found wanting.
That is the deeper lesson organisations should take from Fable 5. And the response is to stop depending on any single model’s defences to act as your last line of protection.
Flexibility – the ability to move between models, providers, and configurations without rebuilding the systems around them – is no longer just an operational convenience. Today, in a landscape where guardrails vary by provider and can be found wanting overnight, it is what keeps a model strategy from being only as strong as the weakest model it happens to be running.
Because these disruptions aren’t hypothetical. When Fable 5 was pulled, any organisation that had hardcoded its integration to that single model’s API suffered an unexpected outage – a reminder that resilience can’t rest on a model staying available any more than it can rest on that model staying secure.
Enforcing security outside the model
If a model’s own defences can’t be trusted as the last line of protection, that security must come from somewhere else – a layer that sits outside any single model, applies consistently regardless of which one is running, and is under the full control of the enterprise itself.
This is what a unified, full-stack platform like Stelia AI OS is built to do. Rather than relying on each model’s own safety training to hold, security is enforced at the platform level – the same layer of checks, isolation, and control applied uniformly, whichever model happens to be doing the work. In practice, with Stelia AI OS, that looks like:
- Inbound filtering: Every request is checked against what’s actually being asked before it ever reaches a model, catching an obfuscated or disguised request at the point of entry rather than trusting a model classifier.
- A reasoning and generation split: Generation is separated from reasoning, with checks running in between, and the system retains memory of what’s already been asked within a session – so the fragments can’t easily be reassembled the way payload splitting relies on.
- Prompt-by-prompt observability: Every step of a model’s reasoning is visible, so what otherwise would be a black box – why a request was allowed, flagged, or blocked – is something a team can actually see and audit, not just blindly trust.
- Isolated execution: Prompts run inside a sandboxed environment with no unrestricted path to the broader internet, so sessions have no way to act outward.
- Real multi-tenancy: Isolation boundaries mean a compromise or breach in one customer’s environment doesn’t propagate sideways into another’s.
- Context-preserving routing: If a model is compromised, downgraded, or pulled entirely, sessions can easily move to another model without losing existing context or starting over.
Betting on architecture, not models
The question worth asking isn’t which model is least likely to be talked out of its own rules. On current evidence, that model doesn’t exist yet – and may never.
The question is whether your architecture still holds when one does get through, or when the model you’ve designed around disappears overnight for reasons unrelated to your business.
Unpredictability at the model layer isn’t going away. What separates the organisations that handle it well is simple: they’ve built so that no single model’s failure is their failure too.
