← All writing

Who Holds the Logs When AI Misuse Monitoring Splits Three Ways

Within three weeks, three model providers published different answers to the same problem: misuse that only becomes visible across sessions cannot be detected by a system that discards each session. Every one of those answers relocates risk rather than removing it, and knowing where it lands has become a procurement task.

Three Weeks, Three Answers

On August 19, 2026, OpenAI published a preview of Private Safety Processing, describing a design in which content for eligible zero-retention customers stays on infrastructure the customer controls, or sits on OpenAI infrastructure encrypted under keys the customer holds and OpenAI does not possess. Automated systems analyze that content and return a narrow signal describing the category and severity of the activity, with OpenAI personnel receiving no access to the underlying prompts even when a flag is raised.1

On September 1, Anthropic announced Enterprise Frontier Safeguards, built on the same split. Activity data used for misuse detection can live in the customer’s own Amazon S3, Azure Blob Storage, or Google Cloud Storage account, under the customer’s encryption keys, access policies, and audit logging. Flags route to the customer’s own review team, with no human review by Anthropic employees required.2 Anthropic reports developing the design with more than one hundred customers, a group whose conversations spanned a quarter of the Fortune 100 and every US global systemically important bank.

Google Cloud’s Advanced AI Safety Addendum takes the conventional route for its own models on the Gemini Enterprise Agent Platform. Where automated classifiers detect suspicious activity requiring investigation, Google may log customer prompts, storing them securely for up to 90 days in the customer’s selected region. Those abuse-monitoring logs are not encrypted by customer-managed encryption keys, authorized Google employees may assess flagged prompts, and the documentation notes that zero data retention may not be possible when using some Advanced AI features.3

Three providers have taken three postures against one underlying problem, and that problem is worth stating precisely because it survives whichever vendor an enterprise selects.

The signal Misuse of agentic systems increasingly reveals itself only in the pattern across sessions and accounts, and a stateless system cannot see a pattern. Restoring that visibility requires someone to hold the data, and the industry is now negotiating who.

Why One Prompt Stopped Being Enough

Both vendor arguments for retention rest on the same observation, and neither is self-serving in an obvious way.

OpenAI’s framing is that the most serious risks are often invisible in a single interaction, becoming clear only when several are read together, and that comparable risks arise when bad actors repeatedly probe safeguards, coordinate across accounts, or disguise threats as routine research. It adds a category that belongs specifically to agents: risk that develops over the course of a long task, as when a system continues acting after being told to stop.1

Anthropic’s version is more pointed about the enterprise’s own exposure. The most sophisticated misuse can involve many tasks spread across multiple sessions and accounts, so analyzing each interaction in isolation and discarding it immediately is insufficient. Some of those instances involve theft or misappropriation of enterprise customers’ credentials, which are difficult to detect without the ability to monitor traffic and identify abnormal behavior.2 That is a description of an attack against the customer rather than an attack conducted by the customer, and it reframes what the monitoring is for.

Additionally, anyone who has read the incident forensics published this summer will recognize the shape immediately. The behavior that mattered in those cases was not visible in any individual action, and it emerged from accumulation: hundreds of agents converging on a shared objective over days, credentials discovered in one context and used in another, a single instance drifting further from its assigned scope over a trajectory lasting many hours. Detection that resets at every request is structurally blind to all of it.

Interestingly, the agentic dimension compounds all of this in a way that older monitoring assumptions never had to handle. A single evaluation trajectory documented this summer ran for between roughly ten and thirty-four hours of continuous work, which is a span over which an agent’s behavior can drift a long way from where it started while every individual action stays unremarkable. Session-scoped monitoring evaluates the actions in isolation, whereas detecting drift requires evaluating the trajectory as a whole, which in turn requires that the trajectory still exist when the evaluation runs.

Furthermore, the enterprise-side constraint driving the opposite direction is equally legitimate. Regulated firms operate under rules governing who may see privileged legal material, non-public information, or drug-safety reports, and their teams are already trained and cleared for that work.2 A monitoring design that requires an outside vendor’s staff to read that content fails on contact with those obligations, whatever its safety merits.

The Division of Labor

Under the conventional model, the provider runs the detection, stores the flagged data, and has its own staff review it. The Anthropic and OpenAI designs break that apart, keeping detection with the provider while moving data storage, encryption keys, and human review to the customer.

Fig. 1 — Where detection, custody, keys, and review sit under each arrangement

Detection stays with the provider in all three cases because the classifiers are the provider’s intellectual property and are tuned against threat intelligence no single customer possesses. Custody moves to the customer in two of the three arrangements, and human review moves along with custody. Therefore the enterprise that adopts one of these arrangements gains control over its data and inherits an operational function it did not previously staff.

The retention window is the quiet variable underneath all of it, since cross-session correlation is only possible across whatever period the data exists.

Fig. 2 — Documented maximum retention windows attached to misuse detection

Furthermore, the cloud layer adds its own variation, and it is the layer most enterprises will actually contract through. Amazon Bedrock resolves retention from an explicit mode rather than a toggle, with none meaning no request or response data is written to durable storage, and aws_review retaining prompts and completions within the AWS boundary for up to 30 days for models whose provider requires human review as a condition of access. Under that mode, AWS performs the review and content is not shared with the model provider; accounts that refuse it see the affected models reported as unavailable.4 The architectural point is that the cloud provider has inserted itself as the reviewing party, producing a fourth arrangement distinct from all three above.

One exception runs through every design discussed here and cannot be negotiated away. Providers are required by law to report apparent child sexual abuse material, and content flagged on that basis is retained for manual review and reporting even in zero-retention deployments.1 Any internal statement that no content is ever retained is inaccurate on that point.

What the Split Actually Moves

However, the benefits are genuine, and they are the reason this architecture will spread rather than stall. Custody under customer-managed keys demonstrably narrows the blast radius of a provider-side breach, a subpoena served on the provider, or an insider incident in the provider’s organization. Review by cleared internal staff resolves the eligibility problem for regulated content. Treating agent activity as monitored traffic extends an existing insider-risk discipline to a new class of actor, which is a considerably cheaper path than inventing a new one. And the retained activity data is forensic evidence, which is the input to the reconstruction question I have argued elsewhere separates real agent identity governance from a procurement checkbox.

The costs deserve the same plain statement, and five of them are concrete.

  • The alert queue becomes yours to staff. Routing flags to the customer means someone in your organization triages them, at whatever hour they arrive, with whatever context the signal carries. Anthropic does not currently charge for Enterprise Frontier Safeguards, which makes the headline price zero and the operating cost entirely a function of alert volume and your analyst capacity.2
  • The bucket concentrates what an attacker wants. A store of prompts and agent transcripts from across the enterprise contains source code, deal terms, patient context, and credentials in roughly the density of a source-control system, held in an object store that until recently did not exist. It requires the protection profile of a crown-jewel data set from the day it is created.
  • Discoverable records now exist where none did. Activity data that survives for a rolling window is subject to legal hold, e-discovery, and regulatory production in a way that discarded data is not. A zero-retention posture was, among other things, a records-management position, and reversing it should involve counsel rather than only the security team.
  • The detection logic remains opaque. The provider still decides what constitutes a signal. A security team receiving flags it cannot tune, whose false-positive rate it cannot measure against a known baseline, is operating a control it does not fully understand.
  • The cost lands on your cloud bill. Anthropic is explicit that customers storing data in their own cloud accounts are billed by their cloud provider for storage, reads, writes, and egress in the ordinary way.2 Agent traffic at enterprise scale makes that a line item worth modeling before commitment rather than after.

One further asymmetry is worth naming before the procurement questions materialize. The provider holds the detection logic and the customer holds the consequences of its errors, which inverts the usual arrangement in security tooling. A managed detection service is normally accountable to its customer for precision, since a queue full of noise is a product defect the customer can escalate on. In this architecture the flag arrives with no comparable service commitment attached, and the internal cost of a poorly tuned classifier is absorbed entirely on the customer side of the line.

100+
Customers involved in designing Enterprise Frontier Safeguards
90 days
Google Cloud abuse-monitoring prompt log retention, outside CMEK
30 days
Bedrock aws_review retention for models requiring human review
Preview
Status of Private Safety Processing as of publication

The Question Nobody Has Answered Publicly

Cross-account correlation implies that something derived from your traffic is compared against something derived from other customers’ traffic. Both providers describe carefully what their own personnel can see, and neither has published what leaves the customer boundary.

Specifically, OpenAI says the system utilizes customer content regardless of where it is stored, and that when a risk is identified, OpenAI receives a narrowly defined signal indicating the type of activity involved, which it uses to determine whether enforcement is warranted.1 The design implies computation over customer-controlled content by provider-controlled code, with a classification result crossing back. Nothing in the announcement establishes the attestation model, how keys are released to the computing environment, how the identity of the executing code is verified, or how much information the signal itself carries. OpenAI stated in August that it planned to begin rolling out Private Safety Processing and publish a technical white paper in September.1 As of this writing, that paper is the most consequential unpublished document in enterprise AI security, and any organization evaluating the architecture should read it before signing rather than after.

Alternatively, Anthropic describes automated systems analyzing a rolling window of traffic for signals of serious misuse, specifically attempts to develop offensive cyber or biological capability and signs of stolen or leaked credentials, with flags going directly to the customer.2 The scope is narrower and clearer than a general misuse mandate, which is to its credit. The mechanism by which detection operating on customer-held data achieves correlation across accounts remains undescribed in the public announcement.

Nevertheless, neither gap is evidence of bad faith, and both are the ordinary condition of a capability announced ahead of its documentation. However, a control whose data flows cannot be described is a control that cannot be assessed, and an enterprise that deploys one is accepting an assurance in place of an architecture.

Reading the Postures Against One Another

Three observations follow from putting the arrangements side by side, and none of them favors a single vendor cleanly.

First, and this deserves saying plainly, the two designs that move custody to the customer are the two whose most capable models carry retention requirements the market resisted. Anthropic introduced 30-day retention with Fable 5 and states clearly that the policy was not motivated by a desire to train on enterprise data.2 Enterprise Frontier Safeguards is the remedy to a friction its own safety policy created, and that sequence is worth naming without treating it as disqualifying. A vendor that creates a problem and then engineers a genuine fix has still engineered a genuine fix.

Second, Google’s more conventional posture carries the clearest documentation and the weakest customer control. Ninety days, a named region, exclusion from customer-managed encryption keys, assessment by authorized employees, and an opt-out request path are all stated in product documentation rather than announced as a design philosophy.3 A buyer can read exactly what happens today, which is more than can be said for either alternative, and what they will read is that the provider holds everything.

Third, the hyperscaler channel changes the answer materially, and it is the channel most large enterprises actually buy through. The same model reached through Bedrock, Microsoft Foundry, or Google’s platform sits under that platform’s retention machinery, and Bedrock’s modes resolve from the most specific configured scope with an explicit opt-in required rather than inherited.4 An organization that negotiated a posture with a model provider and then deployed through a cloud marketplace has two contracts governing one data flow. Anthropic states that Enterprise Frontier Safeguards is planned across Amazon Bedrock, Google’s Agent Platform, and Microsoft Foundry with equivalent controls whether a customer buys direct or through a cloud partner.2 Equivalence asserted in an announcement and equivalence confirmed in a data processing agreement are separate artifacts, and only the second one is enforceable.

Seven Questions Before the Architecture Is Approved

Each of the following is answerable from published documentation or from the vendor in writing, and each corresponds to a gap identified above.

  1. What metadata, signals, or derived features leave our boundary, in what form, and to whom? A control whose egress cannot be described cannot be assessed against a data-transfer obligation.
  2. Does detection fail open or closed? If the customer-held store is unavailable, misconfigured, or has its keys rotated, does inference continue without monitoring, degrade, or stop entirely? The answer determines whether this is a safety control or a safety signal.
  3. Who can suspend an account or block a request on the basis of a flag, on what evidence, and with what appeal path? Enforcement authority is the part of the arrangement that has operational teeth.
  4. Do customer-managed keys cover the abuse-monitoring logs specifically, as distinct from the inference path? Google’s documentation states that its abuse-monitoring prompt logs are outside the CMEK boundary, and that distinction should be confirmed rather than assumed with any provider.
  5. How long is the rolling detection window, and how does it interact with legal hold, e-discovery, and records-retention schedules? Counsel should answer this one before the security team builds the bucket.
  6. What is the expected flag volume, what does a flag contain, and what is the documented false-positive rate? Staffing a queue of unknown size against signals of unknown precision is an open-ended commitment.
  7. When we reach this model through a cloud marketplace rather than directly, which contract governs retention, and which party performs any human review? Equivalence of controls across channels is a claim to verify per model and per endpoint.

A Control Plane Worth Building Deliberately

Consequently, the framing an enterprise brings to this decision also needs to be replaced. The industry has spent three years treating data retention as a binary and negotiating over which side of it a given deployment sits on. That framing is now obsolete at the frontier tier, replaced by a question with more variables and better answers available: who computes, who holds, who reads, for how long, and what crosses between them.

The direction of travel here is the right one. Custody under your own keys, review by your own cleared staff, and detection informed by threat intelligence no single enterprise could assemble is a better arrangement than the alternatives on offer eighteen months ago. The arrangement nevertheless carries costs that are operational rather than contractual, and operational costs surface after deployment rather than during procurement. An organization that budgets the analyst time, classifies the store correctly, and gets the egress question answered in writing will have built something genuinely stronger. An organization that reads the announcement, notes that the provider charges nothing, and ticks the box will discover the rest of it on the morning of its first serious alert.

References

  1. “Offering Zero Data Retention for Frontier Models,” OpenAI, August 19, 2026.
  2. “Developing Enterprise Frontier Safeguards with Our Customers,” Anthropic, September 1, 2026.
  3. “Abuse Monitoring,” and “Zero Data Retention,” Gemini Enterprise Agent Platform, Google Cloud Documentation, accessed September 2026.
  4. “Data Retention,” Amazon Bedrock User Guide, Amazon Web Services, accessed September 2026.