A bank’s security team wants its agents running against the systems that already touch customer data, the same systems everything else in the business already touches. The model they want to run them on has just been designated a Covered Model, one of 4 Anthropic frontier models that now carry a mandatory data-retention requirement wherever they are offered [1]. The number attached to that requirement is worth stating carefully. Anthropic’s own two help pages describe it slightly differently, one saying at least 30 days and the other 30 days flat, so the honest version is roughly 30 days [1][2]. For that window, prompts and outputs from that model sit somewhere, retained specifically so a serious pattern of misuse, a leaked credential, a runaway agent, an attack spread thin across many sessions so no single one looks wrong, can be caught by looking back across a window wide enough to see it.
That single requirement forces a choice most security teams have never had to make in quite this shape. Somebody has to be able to see that retained activity data to look for misuse, so the obvious arrangement is to let the model vendor hold it and watch it themselves. A security team in banking, insurance, healthcare, or law reads that sentence and stops the project there, because a vendor holding a rolling window of everything the agent said and did is not a policy question they get to answer alone. It is a question for the regulator, the general counsel, and often the board, and the honest answer in a regulated industry is usually no. So the team reaches for the only other lever available and turns monitoring off, or narrows it until it catches almost nothing. The misuse that monitoring exists to find now goes unseen, because the alternative felt worse. Both of those answers are bad in the same specific way. They treat holding the data and watching the data as the same job, so accepting one means accepting the other.
Figure 1 - Custody stays, detection crosses: The customer’s own cloud account holds the data under the customer’s own keys and audit log. The vendor’s detector runs against it automatically. The only thing that ever crosses the boundary back is a flag, and it lands with the customer’s own review team, not the vendor’s.
The Trade Nobody Gets to Skip
Every regulated business that puts an agent in front of real infrastructure runs into the identical fork, whichever vendor, whichever model, whichever industry. Detecting the misuse that matters needs some retention and some analysis across that retention window, because a single interaction, judged in isolation and then thrown away, cannot show a pattern that only exists across 10 interactions. That is the actual reason Anthropic gives for why the retention window exists at all: “the most sophisticated misuse can involve many tasks spread across multiple sessions and accounts” [3]. Take that reasoning at face value, because it holds regardless of which vendor wrote the sentence. Detection needs memory.
Both answers throw away something the team cannot afford to lose. Full vendor custody forfeits the customer’s own control over information that may run from proprietary source code to protected health data, routed there by an agent doing the ordinary job it was asked to do. Monitoring off forfeits the one thing retention exists to buy. In our own consulting work we keep meeting teams that have quietly picked one of the two, without much vocabulary for naming what they gave up.
Figure 2 - Both usual answers give something up: Full vendor custody gives up the customer’s own control of the data. Monitoring off gives up the ability to catch the pattern retention exists to catch.
What “Mandatory Retention” Actually Means on the Ground
Amazon Bedrock’s own documentation shows what this looks like once a customer actually has to implement it, and it is more customer-protective than the launch announcements implied. Using a Covered Model on Bedrock, such as Claude Fable 5.1, requires setting a data-retention mode explicitly, and the mode AWS steers customers toward is aws_review, opt-in per account or per project rather than a default a customer discovers after the fact [4]. Under that mode, “AWS retains your prompts and outputs for human safety review within the AWS boundary” [5], and the review is performed by AWS personnel, not by Anthropic. Content is never shared with the model provider under this mechanism [4]. The sharper detail sits in what happens if a customer sets no mode at all. Their data is not silently retained anyway. They simply cannot invoke Fable 5 or Fable 5.1, which show as unavailable rather than available-but-watched [4]. That is a real, enforced boundary, and it is also the exact arrangement a bank’s security team was never going to accept, since it hands the human review step to a party outside its own control.
Figure 3 - Opt in, or the model simply will not run: A customer who declines aws_review is not monitored quietly. The model refuses to invoke at all. That is the baseline a bank’s security team was reacting against when it asked for something different.
The Split That Was Never Actually One Job
Enterprise Frontier Safeguards, announced by Anthropic on September 1, 2026, is built on a single observation, and what follows describes the design as announced rather than a system a reader can invoke yet [3]. Custody and detection only look like one job because the misuse-monitoring products a regulated buyer has been offered so far have bundled them, not because anything in the underlying work requires it. Storing data and analyzing data are different operations, performed for different reasons, and once a vendor separates them explicitly, the fork described above stops being a fork at all.
Under EFS, custody of the retained activity data stays inside cloud infrastructure the customer already controls, an Amazon S3 bucket, an Azure Blob container, or a Google Cloud Storage bucket, under the customer’s own encryption keys, access policy, and audit log over every read [3]. Anthropic never becomes a new data holder the customer has to onboard, disclose to its own customers, or amend a contract to cover, because the data was never handed over. Anthropic frames this as a deliberate architectural choice rather than a policy promise: “we architected EFS so that customers have the ability to store data on their existing cloud infrastructure” [3].
Detection is a separate operation running against that same data, performed by Anthropic’s automated systems, with no Anthropic employee ever looking at the underlying content. In Anthropic’s own words, “automated systems analyze a rolling window of traffic for signals of serious misuse, including attempts to develop offensive cyber or biological capabilities and signs of stolen or leaked credentials” [3]. The absence of a human reviewer is stated plainly, not implied: “EFS has automated safety monitoring, no Anthropic human review required” [3]. A speaker from Visa, unnamed anywhere in the companion video’s captions, puts the same point more bluntly: the review is machine only, and what comes out is “intentionally limited to the [findings], not customer content” [6].
That last clause is the whole mechanism in one sentence. When the automated detector finds a pattern worth a human looking at, what crosses the boundary back is a flag, not the underlying prompts and outputs that produced it. “Those signals are sent directly to customers so they can review what the automated systems detected,” and the reviewing itself is done by the customer’s own cleared staff, not by anyone at Anthropic [3]. Content stays on the customer’s side of the boundary from the moment it is written to the moment somebody the customer trusts reads it, if anyone ever does.
Turning monitoring off was never really about refusing detection. It was a proxy for refusing to hand a vendor custody of retained data, and the two had never been separable before because no vendor had shipped them as separable products.
KEY INSIGHT: Turning monitoring off was never a security decision. It was a proxy for refusing custody, mistaken for refusing detection because no vendor had ever shipped the two as separable.
The Tell Is in What the Customers Negotiated
EFS was built, per Anthropic, “in close collaboration with more than 100 customers” spanning financial services, healthcare, manufacturing, telecom, law, retail, and the public sector, and the announcement carries 17 individually attributed quotes from customers, cloud and service partners, and one industry consortium [3]. What is worth noticing is not that large regulated firms agreed to use a frontier model. It is what they specifically said they got.
Munish Kumar Sharma, Chief Information Security Officer at Wells Fargo, put it in one line: “Enterprise Frontier Safeguards gives us exactly what we asked for: our logs stay in a Wells-managed environment under Wells-managed keys. We keep custody of our data while Anthropic operates the detection” [3]. Philip Martin, Chief Information Security Officer at Uber, described the same shape from a different industry: “The safeguards and the design of them, clearly, you heard our feedback. They put us in the driver’s seat. The logs are under our control; they don’t go anywhere else unless we want them to. It gives us control of the data, control of the information, and control of what’s done after something that might exceed a safeguard is detected” [3]. Mayank Upadhyay, Chief Security and Trust Officer at Snowflake, and Matthew Kemelhar, Head of Security at Stripe, both land on the identical point in their own words, data staying in an environment the customer controls, under keys the customer holds [3]. Of the 17 cards, 5 print the generic label “Service Partner” where a company name would go, though the individual speaker is named and the firm is identifiable from the page’s own logo assets, among them Todd Lohr, an Anthropic service partner (KPMG), and Lan Guan, an Anthropic service partner (Accenture) [3]. Mastercard and Visa are both named in the announcement’s prose as companies Anthropic worked with, but neither carries an actual quote card [3]. The only genuinely unattributed quote across the whole source family is the Visa speaker in the companion video, given no name anywhere in its captions, and none should be invented for them [3][6].
Almost none of the 17 speakers argues about detection logic, and the one who comes closest still frames it as a boundary question rather than a tuning one. Scott DePasquale, President and CEO of the Analysis and Resilience Center for Systemic Risk, describes what his members set out to define as “who holds the data, who holds the keys, what automated review can and cannot see, and under what conditions a human is ever permitted to look” [3]. Even there the question is which reads are permitted, not how sensitive the detector should be. Not one speaker is quoted arguing about thresholds, or about what counts as misuse. The people quoted, whatever their title, negotiated who holds the data the detector reads and who can audit every time it is read. That absence, in quotes Anthropic itself selected, is at least a tell for what Anthropic believes closes agreements like these, and it inverts what most technical leaders prepare for walking into a vendor-security conversation, where the instinct is to interrogate the model’s judgment rather than the custody arrangement around it.
Figure 4 - What got negotiated, and what didn’t: The named quotes are about who holds the storage and the keys, and about which reads are permitted. None argues about how sensitive the detector should be or what counts as misuse. The negotiation that happened was over custody, not tuning.
What It Costs, and What Still Only a Vendor Says
Enterprise Frontier Safeguards is not something a customer can buy and turn on today. As of this writing it is announced and rolling out to customers in phases, with Anthropic’s own stated goal of being broadly available later this fall [3]. A team evaluating this should treat it as an architecture to design around and a specific set of questions to bring to a vendor conversation, not as a shelf product to procure this quarter.
Figure 5 - Ask for it, don’t shop for it yet: EFS is announced and shipping in phases, not generally available. The right move today is asking a vendor for this architecture by name, not procuring it as a finished product.
The financial cost, where it applies, is smaller and stranger than it first sounds. Anthropic states plainly that it does not charge for the program: “Anthropic doesn’t charge for Enterprise Frontier Safeguards. If customers elect to store their data in their cloud account, their cloud provider bills them for that storage, as well as reads, writes, and data egress fees, the same way it bills any other resource” [3]. The real cost of this architecture is not a line item on an invoice from the vendor. It is the engineering and staffing the customer has to stand up on their own side of the boundary, covered in the next section.
Figure 6 - No vendor fee, a cloud bill instead: Anthropic does not charge for EFS. The cost that exists lands on the customer’s own cloud bill, for storage the customer already runs, billed the same way any other bucket is billed.
What EFS does not solve is worth stating as plainly as Anthropic states the mechanism itself. This is one vendor’s program, announced by that vendor, illustrated with quotes that vendor selected. The architecture is real, and the mechanism is verifiable in the vendor’s own documentation, but no outside party has audited it, and no customer has yet published their own account of running it. Every figure in this article traces back to Anthropic’s own announcement and Anthropic’s own selected quotes. Verify the current status directly against the vendor before treating any of it as settled, because a rollout still described as “later this fall” moves.
KEY INSIGHT: An architecture you can verify in a vendor’s own documentation is not the same as an architecture that has been independently audited. Ask for the first. Do not mistake it for the second.
Figure 7 - The gap this article cannot close: Every claim in this piece traces to Anthropic’s own announcement and Anthropic’s own selected quotes. No independent audit and no published customer operating account exist yet. That is the honest limit of the evidence, not a flaw in the architecture.
The Four Questions That Separate a Real Split From a Marketing One
The interesting part of this is not that Anthropic built it. It is that the split is reusable against any model vendor a business already works with, and a reader does not need to wait for a specific product name to start asking for it. What matters is whether four specific things are true, and a vendor pitch that cannot answer all four plainly is not actually offering a split, whatever it calls itself.
- Who holds the storage? If the answer is the vendor, this is not a custody split. It is the old bundle with a new name.
- Who holds the encryption keys? Storage in the customer’s cloud account still does not help if the vendor holds the keys that unlock it. Custody and key control have to travel together.
- Who can read the logs, and is that read itself audited? A review workflow that lets anyone read raw activity data without leaving a record of having done so recreates the exposure the split was supposed to remove, just one layer down.
- Does anything other than a flag ever leave the boundary? The entire value of the architecture collapses if “detection” quietly means the vendor also gets a copy of the underlying content whenever something looks suspicious.
Figure 8 - The four-question test: A vendor that cannot answer all four plainly is not offering a real custody-and-detection split, regardless of what the product is called.
What You Have to Build on Your Own Side
Accepting this architecture is not free of work, and the work does not belong to the vendor. A customer choosing this path has to stand up its own side of the boundary, and that side has four real components, none of which a model vendor can supply on the customer’s behalf.
- Storage the customer actually owns and operates, not a vendor-managed bucket dressed up as customer-controlled.
- Encryption keys the customer holds and rotates, under the customer’s own key-management process, not a key the vendor can also reach.
- Audit logging over every read, including reads by the customer’s own staff, so that a security team can answer “who looked at this and when” for the data it now custodies.
- A trained, cleared review team that receives flags and knows what to do with one, since a flag that lands nowhere accomplishes exactly as much as monitoring that was turned off.
This is not abstract work for us. Our own txtToSql engine keeps tenant data isolated by boundary, not by promise, and the discipline transfers directly: define which party can reach which data, under which key, with which audit trail, and build the boundary so the answer is enforced rather than assumed.
Figure 9 - The part nobody else builds for you: A real custody split shifts real work to the customer’s side of the boundary. These four pieces are the price of the architecture, and no vendor conversation replaces standing them up.
This is one layer up from the argument The LLM Is Not Your Security Boundary makes [7]. That article’s point is that a model’s own output cannot be trusted as the thing standing between an agent and a system it should not touch. This article’s point is that the vendor holding the model cannot be the thing standing between a customer’s data and everyone who might want to see it, either. Neither boundary gets to be a promise. Both have to be an enforced architecture, verified rather than taken on trust.
Conclusion
The trade a regulated team faces once its agents touch real infrastructure was never actually a trade. It only looked like one because the misuse-monitoring products on offer bundled custody and detection into one thing, so accepting the detection a security team genuinely wanted meant also accepting a custody arrangement it could not defend to a regulator. Splitting the two apart, storage and keys on the customer’s side, an automated detector on the vendor’s side, a flag as the only thing that ever crosses back, dissolves the trade rather than negotiating a better version of it.
Anthropic’s own implementation of this is not yet something a team can buy off a shelf, and the honest evaluation of it stops at what a single vendor has announced and a single vendor’s selected customers have said about it. Neither of those facts weakens the architecture itself. The mechanism does not depend on Anthropic, and a reader evaluating any model vendor, current or future, can bring the same four questions into the room, in the same order. A vendor that answers all four plainly is offering a real split. One that cannot is offering the old bundle with new language wrapped around it, and the meeting where an agent rollout in a bank, an insurer, a law firm, or a healthcare business either proceeds or quietly dies deserves better than that.
The customer’s own side of that architecture, the storage, the keys, the audit trail, and the review workflow, does not build itself once the vendor conversation ends. That design pass, scoped to what a specific business actually needs to stand up before its own agents can safely touch real infrastructure, is the work that follows a meeting like this, and it is the work we do.
References
[1] Anthropic, “Covered Models,” Anthropic Help Center. https://support.claude.com/en/articles/15425695-covered-models
[2] Anthropic, “Data retention practices for Covered Models,” Anthropic Help Center. https://support.claude.com/en/articles/15425996-data-retention-practices-for-covered-models
[3] Anthropic, “Developing Enterprise Frontier Safeguards with our customers,” Anthropic News, Sep 1, 2026. https://www.anthropic.com/news/enterprise-frontier-safeguards
[4] Amazon Web Services, “Data retention,” Amazon Bedrock User Guide. https://docs.aws.amazon.com/bedrock/latest/userguide/data-retention.html
[5] AWS Machine Learning Blog, “Introducing Claude Fable 5.1 on AWS,” Sep 2026. https://aws.amazon.com/blogs/machine-learning/introducing-claude-fable-5-1-on-aws/
[6] Claude, “Building Enterprise Frontier Safeguards with our customers,” YouTube, Sep 1, 2026. https://www.youtube.com/watch?v=FoteuzPpx7E
[7] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Multi-Tenant Agent Security: The LLM Is Not Your Security Boundary,” 2026. /insights/ai-26-multi-tenant-agent-security/
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.