How to use Mythos-grade models with enterprise data

TL;DR Claude Fable 5 comes with mandatory 30-day data retention. The most capable model on the market won't sign a zero-retention agreement, and the evidence says the next one won't either. If this mandatory data retention is inhibiting your ability to use the most advanced model on the market, tokenizing your data before it reaches the model might help you get there. Read on for all the details.

Anthropic released Claude Fable 5 on June 9—the first Mythos-class model available to the general public, and by Anthropic's published benchmarks (opens in new tab) the most capable model anyone can rent. Three days later, the U.S. government placed it under emergency export controls and Anthropic pulled access worldwide. On June 30 the controls were lifted, and on July 1 the model came back online with restrictions (e.g. Fable hands-off coding tasks to Opus), with subscriber access running out July 19th.

Teams flocked to test and evaluate Fable 5, with some inspiring early access stories. Stripe, for example, reported it migrated a 50-million-line codebase in about a day. Every one of those evaluations runs into the same security review, and the review starts with the same question: what happens to our data?

For this model, the answer is worth reading carefully.

The fine print

Fable 5 is what Anthropic designates a Covered Model (opens in new tab). To operate the safety classifiers that made the release possible, Anthropic retains every prompt and output for 30 days. If you use the model zero-data-retention agreements don't apply—not for new customers, or customers who already have ZDR terms in place. The requirement propagates downstream, too: GitHub shipped Fable 5 in Copilot behind an admin policy that's off by default, because enabling it accepts the retention terms on behalf of your whole organization.

There's another safeguard that was added to Fable 5 and might matter more than it looks. Fable 5's classifiers route flagged requests to Claude Opus 4.8 (opens in new tab), which answers instead. Anthropic says rerouting is rare, and that the stricter post-redeployment classifiers may catch some routine work in the near term. That's fine for a consumer. But if you maintain data-flow documentation for a living, note what it means: the accurate answer to "which model processes our prompts" is now at least two.

For a bank, an insurer or a healthcare platform, none of this is merely a friction point in the review. It likely stops or stalls the review. Retention windows and inspection pipelines are exactly the things a data governance policy enumerates, as they likely conflict with typical enterprise data governance policies.

Is this one launch, or the new normal?

This might be the new normal, and the June timeline is the evidence.

Walk the sequence:

• An advanced model with capabilities that required a new class of safety infrastructure to be released is shipped.

• Within 72 hours, a government treats those capabilities as a controlled item. 

• Three weeks of negotiation follow, and the model returns with stricter terms, not looser ones: additional classifiers, a jailbreak-severity framework being developed jointly with the other major providers and expanded pre-release government testing. 

Every force in that sequence pushes toward more oversight, not less. The safety classifiers and the retention window aren't wrapped around the product. They're the requirement for the product release.

My prediction for the next two generations of frontier models: retention doesn't shrink, inspection deepens, routing gets more elaborate and jurisdiction becomes a product dimension (Fable 5 already sells US-only inference at a premium (opens in new tab)). And this won't stay an Anthropic story. Every vendor that reaches this capability tier faces the same forces, so every vendor's frontier release will likely carry its own version of these terms.

We've run a version of this experiment before. In the 1990s, strong cryptography was export-controlled as a munition, and enterprises spent most of a decade navigating rules that changed faster than an architecture review. The companies that handled it well were the ones whose systems didn't depend on the contested component. Fable’s release demonstrated that a frontier model can become a controlled item on 72 hours' notice, so the same design goal applies: Make your exposure analysis an invariant so it stays true even when the vendor's terms change. 

I've started calling this “terms-invariant architecture.” If the retention window, the classifier pipeline, the fallback model or a surprise export control can all change without changing what you've exposed, adopting terms-invariant architecture might allow you to adopt frontier models the week they ship instead of two quarters later.

The three responses available to you

1. Wait for the terms to improve: Zero-retention tiers return someday, legal signs off and you adopt the frontier late, every cycle. The cost compounds, because launch week is when task categories flip from impossible to routine and the competitive information is richest. Waiting is also a bet, as June's data point shows us that three weeks of government negotiation produced stricter terms.

2. Carve out an exception: Clean rooms, synthetic-only sandboxes, evaluation environments walled off from production. I've watched this play out at several enterprises, and the pattern is consistent: The sandbox proves the model can do the work, the announcement goes out and production doesn't change, because the data that matters never got approved to meet the model that matters. Carve-outs also scale badly (one per vendor, renegotiated per term change) so the governance load grows with every release.

3. Change what crosses the boundary. If the data that reaches the model is tokenized, the retention window might not be a problem anymore. The raw sensitive data never reaches the model, so it cannot be retained. Because this is one control at the data layer, this is the only response that can potentially absorb every vendor's terms, including the ones that don't exist yet.

How Databolt can help

Tokenization isn’t a new concept. It solved a version of this problem twenty years ago in payments. PCI compliance didn't get cheaper because companies hardened every system that touched a card number—it got cheaper because they took card numbers out of those systems. A merchant whose systems hold card data assesses against the full control set, a few hundred requirements, while one whose systems never touch a card number files the short-form questionnaire at a few dozen requirements. Same business, same transactions, roughly an order-of-magnitude compliance delta based purely on where the sensitive data sits. 

The PCI Council never made descoping automatic. The 2011 tokenization guidance (opens in new tab) presumes everything in scope until verified otherwise, and a system exits scope only when it shows it can’t reach the cardholder data environment and can’t retrieve a card number. The pattern that emerged, however, became the standard practice: tokenize early, segment hard and shrink the audit. The one component that never left the boundary was the tokenization system itself: The vault, the keys, the detokenization path stayed inside the boundary, because that’s where the risk was re-concentrated. 

The frontier-model version of the problem has the same shape, one level up. The scope now includes Anthropic's retention window, a classifier pipeline you will never audit and a fallback model you didn't pick. You cannot apply your governance policies to this external infrastructure. With tokenization, you might not need to.

The mechanics- concretely

Capital One Databolt replaces each sensitive value with a token that keeps the original's format: a card number becomes a different 16-digit number that still passes a Luhn check, an SSN stays SSN-shaped, a date stays a valid date. The mapping is deterministic, meaning that the same input always produces the same token, so joins, group-bys and entity-level analytics keep working across tables and time. And it's vaultless: there is no stored table mapping tokens back to real values. Tokens are dynamically generated within the boundary of your data ecosystem and are only de-tokenized when requested by authorized users and based on their specific level of access.

Run the Fable terms again under that posture: The 30-day retention window holds tokens, the classifiers inspect tokens and if a request reroutes, Opus 4.8 reads tokenized data. This tokenized workflow could be the evidence your CISO needs to allow the organization to use the frontier model. 

The two traditional alternatives to tokenization fail this test in opposite directions. Masking destroys information irreversibly, which is fine for a demo and fatal for any workflow that needs to re-identify results downstream. Conventional encryption protects the data by making it useless to the model. The resulting ciphertext preserves nothing a model can work with. Which raises the question that decides whether any of this is practical: Does a frontier model still work on tokens?

Where utility lives: entities as features, targets and context

Here's a framework to answer that. It has held up across every protection evaluation I've run. In any AI workload, a protected entity plays one of three roles, and the role determines what kind of protection it can tolerate.

• The entity is a feature: An input the model conditions on, like a customer identifier grouping transactions. The model never needs to read the value; it needs the value to stay consistent. Determinism is the whole requirement, and format barely matters.

• The entity is a target: The thing the model has to find, type or produce, as in extraction, PII detection and document parsing. The model's job is recognizing what a card number looks like, so format is the entire signal. Change or remove the shape and there's nothing to recognize.

• The entity is context: A value the model reads in order to reason, like the dates in a range filter or a card it has to validate. Format determines readability: A model can total March transactions only if the dates still parse as dates.

Now check the three schemes against these three roles:

• Tokenization is the only scheme that serves all three roles.

• Masking destroys value and linkage at once, so it fails wherever recognition or joins matter. 

• Deterministic encryption preserves equality, so it should hold up where entities are features. But it will fail where they're targets or context, because ciphertext has no shape and doesn't parse. 

You can check this against your own workloads: list your AI use cases and mark whether the sensitive fields in each are features, targets, or context. That mapping predicts what each protection method will do to them.

This framework, like any other, is only a hypothesis until it's measured. We're doing the measuring now and will publish the benchmark soon, as the second piece in this series. 

What the framework says the benchmark should show

The benchmark puts all three schemes through five experiments: recognition within a protected regime, entity matching across records, a context-ablation series, a transfer test across the plaintext/protected boundary and a zero-shot extraction run against a hosted model over the Anthropic API. Here’s what the framework above predicts the benchmark should show:

• Within a single regime, expect a parity trap. Train and evaluate inside one protected dataset and the deterministic schemes should look interchangeable, because in that setting entities behave as features and determinism is all that's being tested. Masking should already trail here, since a mask gives a recognizer less shape to learn from. If you stop measuring at this experiment, you'll conclude the protection method barely matters. The next four experiments are why you shouldn't stop.

• In entity matching, expect masking to collapse. Referential integrity is pure linkage and redaction destroys linkage by construction. The deterministic schemes should hold near-perfectly and masking should land near zero. This is where "just redact it" stops working as an analytics strategy.

• As context shrinks, expect format to carry more of the load. The less surrounding text the model has, the more the entity's own shape has to do the work, so the gap between format-preserving tokens and masks should widen as context is ablated away.

• At the regime boundary, expect encryption to drop to nothing. Evaluate on protected data the model was never trained on—the zero-shot posture—and entities become targets: shape is the only signal left. Format-preserving tokens should keep working. Ciphertext shouldn't, because there's nothing in it to find. This experiment separates memorization from understanding and it's the one that matters most when a frontier-model launches. 

• Against the hosted model, expect the same ranking, amplified. Zero-shot extraction over an API is the target's role in its purest commercial form. If tokens don't stay usable there while the format-destroying schemes fail, the framework is wrong.

If the results land where the framework says, you can plan on a mechanism. If they don't, the framework is wrong. This is precisely what the benchmark will show, so stay tuned.

Conclusion

The operational version is short. Tokenize at the source, before the API boundary and before any model call is composed. Detokenize at the edge, under authorization, only for workflows that genuinely need real values back. 

Extend the same posture to documents next: Fable 5's headline strengths include reading charts, tables and PDFs, so unstructured data is where this question goes next. Then evaluate frontier models as they are launched.

The next frontier model will arrive with its own fine print. Tokenization can help you decouple model evaluation from model terms.