Design AI monitoring by separating custody from detection

A regulated buyer's security team will ask where AI activity data lives and who can read it. If the answer is a vendor-held log, the design has a custody problem, even when the intent is safety. The pattern that fixes it keeps storage, keys, and incident response with the customer while the vendor runs automated detection. The split also makes the safety story easier to explain to a regulator.

Custody is the trust surface

Regulated teams need proof that the monitoring store sits inside their own environment. A vendor can still detect misuse without owning the evidence. The customer keeps the audit trail, access controls, and incident response workflow in its own tooling.

The design choice is the part worth copying. Anthropic announced Enterprise Frontier Safeguards (EFS) on September 1, 2026. EFS is scheduled to reach customers through a phased release starting later in fall 2026. EFS allows the activity data used for monitoring to be kept in the customer's own Amazon S3, Azure Blob Storage, or Google Cloud Storage account under customer-held encryption keys. That keeps the evidence where the customer already audits it.

Encryption alone does not settle the question. The buyer needs to know who can read the data after the model run. If the customer holds the keys and the storage account, the vendor's safety system stays a detector.

Detection can run without human eyes

Many teams assume monitoring requires a person to inspect flagged content. That assumption creates a custody problem: if a vendor employee can read the flag, the customer must trust that employee's access, logging, and retention. A cleaner pattern sends only the flag to the customer's security team.

In EFS, misuse flags are delivered to the customer's security team, and Anthropic staff do not conduct human review of the flagged content. The vendor's role ends at automated detection. The customer's security team decides what to do with the flag.

The flag can enter the customer's existing incident workflow. The response stays with the customer, without vendor interpretation of the content.

The transition is part of the design

A monitoring redesign needs a safe path while the new controls are being deployed. The interim bridge is part of the architecture. If a vendor introduces retention to support monitoring, the transition itself must be designed, not improvised.

Anthropic introduced a 30-day data retention period beginning with Fable 5. Before EFS is ready, eligible customers will receive zero data retention on Fable 5 and Fable 5.1. That interim period lets customers move to the new safeguards without accepting a longer vendor-held window than necessary.

The transition also changes the procurement conversation. Instead of asking whether monitoring is available, the buyer can ask what happens to data before the customer-owned controls are live. A no-retention period gives the security team a concrete answer before rollout.

Use the split as a procurement test

When you design or evaluate enterprise AI data retention, use the custody-detection split as the test. The controls should be separable, auditable, and optional where the customer's risk model requires it.

• Customer-owned storage
• Customer-managed encryption keys
• Fully automated review
• Interim zero-data-retention bridge
• Disclosed detection boundary

EFS provides three optional safeguards—storage in customer accounts, keys managed by customers, and automated review—that do not alter model behavior, API fees, or request limits. That is a spec a regulated buyer can put in a contract. It also gives designers a way to separate safety from data access.

With this split, you can judge a monitoring proposal by three questions: who stores the data, who holds the keys, and who can read the flags. If the answers keep custody with the customer and detection automated, the design is easier for regulated buyers to approve and audit.