{"id":29,"date":"2026-09-04T07:00:50","date_gmt":"2026-09-04T07:00:50","guid":{"rendered":"https:\/\/www.0xprathamesh.com\/blog\/?p=29"},"modified":"2026-09-21T06:05:08","modified_gmt":"2026-09-21T06:05:08","slug":"anthropic-efs-ai-log-custody","status":"publish","type":"post","link":"https:\/\/www.0xprathamesh.com\/blog\/anthropic-efs-ai-log-custody\/","title":{"rendered":"Anthropic EFS Moves AI Logs Into Your Cloud. What Comes Next?"},"content":{"rendered":"

Anthropic\u2019s Enterprise Frontier Safeguards (EFS) changes where AI monitoring evidence is kept and who reviews it.<\/strong> For an enterprise evaluating that design, the work starts with the storage account and ends with a person who can investigate an alert. A privacy promise becomes useful when your team can demonstrate restricted access, dependable evidence delivery and a tested response.<\/p>\n

An AI transcript can contain a source-code fragment, a customer record and the result of a tool call in the same conversation. Put thousands of those conversations into a monitoring store and you have assembled a valuable dataset. The account that holds it deserves the same care as the applications that supplied it.<\/p>\n

That is what caught my attention in Anthropic\u2019s EFS announcement. I would read it with the person who runs incident response beside the person who approves data handling. Both will inherit decisions that the product team cannot make alone.<\/p>\n

What Anthropic has announced<\/h2>\n

On 1 September 2026, Anthropic announced Enterprise Frontier Safeguards<\/a>. The proposed system keeps activity data used for monitoring in customer-controlled cloud storage, under customer keys and access policies. Automated monitoring looks across a rolling window of traffic; flags go to the customer\u2019s reviewers, without requiring human review by Anthropic employees.<\/p>\n

Anthropic says customer-owned storage, customer-managed keys and fully automated review are separate opt-in choices. It plans a phased rollout later this fall. Eligible customers receive zero data retention on Fable 5 and Fable 5.1 during the transition. Anthropic charges no EFS fee, while customers pay their cloud provider\u2019s storage and related usage charges.<\/p>\n

Those are announcement claims, not results from a deployment I have tested. The engineering proposals below are my assessment criteria, not an EFS implementation specification. Exact retention periods, service permissions, alert delivery guarantees and failure behaviour need to be confirmed for the customer\u2019s integration.<\/p>\n

Read \u201czero data retention\u201d with a location attached<\/h2>\n

For a buyer, \u201czero data retention\u201d is incomplete until the agreement identifies the party, the data and the processing stage it covers. A provider\u2019s retention commitment does not automatically describe the customer\u2019s application logs, an observability tool, a support export or the evidence kept in a separate security account. Review the whole path a request travels.<\/p>\n

Consider a representative coding assistant used inside a SaaS company. A developer submits a task, the assistant retrieves a file, and a gateway records the request. The inference provider may have one policy for that interaction. The company\u2019s gateway has another. If a security analyst copies a suspicious exchange into a ticket, that copy has a third lifecycle. A purchasing questionnaire that asks only whether the provider retains prompts misses two places where the company now holds them.<\/p>\n

I would draw those copies before negotiating a number of days. Mark where readable content exists, the service that writes it, and the group permitted to inspect it. Include failed requests and debugging paths. The diagram often becomes more interesting at the retry queue than at the model endpoint.<\/p>\n

\n\"Proposed
An original assessment model for customer-held AI evidence. This is a review aid, not Anthropic\u2019s published internal topology.<\/figcaption><\/figure>\n

The evidence store needs its own permissions<\/h2>\n

Start with a simple question: can the same application identity run the AI workflow and erase the evidence of its actions? If the answer is yes, storage ownership has not given the responder much independence. A compromised application can affect both the business operation and the record needed to explain it.<\/p>\n

My proposed separation is deliberately small. Give the collection service the access it needs to deliver records. Give the analysis service only the reading scope its job requires. Put policy changes and evidence disposal behind a different administrative role. The actual permission names will depend on the cloud and integration, so review effective access rather than trusting the labels attached to roles.<\/p>\n

A useful acceptance test is to submit a harmless synthetic event, then attempt to alter or remove it using the application\u2019s normal service identity. The expected outcome should be documented before the test. Next, perform an authorised reviewer read and confirm that a separate audit record identifies the reader. This proves something a screenshot of an encryption setting cannot: who can act on the stored evidence.<\/p>\n

On AWS, there is a specific trap. S3\u2019s CloudTrail documentation<\/a> distinguishes bucket management events from object data events. Object reads and writes are data events, which CloudTrail does not log by default and which do not appear in its Event history. Configure the required data-event coverage and account for the additional charges. A history of bucket-policy changes does not establish who read a transcript yesterday.<\/p>\n

Keep enough context to investigate without collecting everything<\/h2>\n

A security store can become a second source of data exposure if every input and output is copied into it indefinitely. Start with the questions a reviewer must answer. Which authorised workflow produced the event? What operation was requested? Did the tool accept it? Which policy applied at the time? Some investigations will require content, but many first-stage decisions need a reliable event record before they need a complete transcript.<\/p>\n

OWASP\u2019s logging guidance<\/a> recommends recording the context and outcome of events while avoiding direct logging of access tokens, passwords and sensitive data. It also calls for protecting logs and auditing access to them. Those principles are a useful baseline for the customer\u2019s surrounding applications; they are not a claim about the fields EFS exports.<\/p>\n

For your own event pipeline, I would begin with a record like this. The values are fictional and the schema is illustrative.<\/p>\n

{\n  \"event_id\": \"review-demo-0042\",\n  \"occurred_at\": \"2026-09-04T09:00:00Z\",\n  \"workflow_id\": \"support-summary\",\n  \"principal_ref\": \"service-role-17\",\n  \"policy_version\": \"support-policy-12\",\n  \"requested_action\": \"export_summary\",\n  \"action_result\": \"denied\",\n  \"content_ref\": \"restricted-evidence\/demo-0042\",\n  \"review_state\": \"unassigned\"\n}<\/code><\/pre>\n
The distinction between requested_action<\/code> and action_result<\/code> earns its place. A model asking for an export and a tool completing that export have different consequences. Link to the tool\u2019s own event where possible. A transcript alone can describe a plan that never happened.<\/p>\n
Keep the identity mapping protected, too. An opaque principal reference can reduce casual exposure in the first review screen, but a responder still needs a controlled way to resolve it. Excessive redaction can leave a beautiful dashboard that cannot identify the affected workflow. Choose the minimum useful context by testing a real investigation question with synthetic data.<\/p>\n
A flag needs a route to a decision<\/h2>\n
The representative SaaS company now has a suspicious event. The first reviewer sees a support assistant request an unusual export. It might be an approved bulk operation, a compromised service account, or a bad instruction inside retrieved content. A generic severity score cannot distinguish those cases without workflow context.<\/p>\n
I would route the alert to an owner who can see the relevant evidence and establish whether the requested operation succeeded. That owner should be able to reach the application team without forwarding the full conversation to a broad chat channel. Restricting the original storage is of little value if ordinary triage republishes its contents.<\/p>\n
The review process also needs an outcome for a legitimate event. Record why it was cleared, which evidence supported that decision, and whether a detection change is justified. Avoid adding a blanket exception for a powerful service account because one alert was inconvenient. The next event from that account may have a different cause.<\/p>\n
\n\"Five
A proposed operating process. Assign a person and a measurable completion condition to each hand-off before the first production alert.<\/figcaption><\/figure>\n
For an initial service objective, measure elapsed time from event occurrence to ingestion, from ingestion to a delivered signal, and from the signal to a reviewer decision. Choose target times according to what the agent can do. A system that drafts internal prose can tolerate a different response window from one permitted to change production infrastructure. Report the slowest hand-off as well as the average; the delayed case is often the one an incident exposes.<\/p>\n
Test what happens when monitoring breaks<\/h2>\n
A monitoring feature needs a visible unhealthy state. Otherwise, an empty alert queue can mean either quiet operations or a broken integration. Before approving a pilot, ask for a supported way to verify delivery, then repeat the exercise while a test dependency is unavailable.<\/p>\n
For a customer-built evidence pipeline, the test might temporarily deny a writer access to a dedicated test prefix. Check whether the application reports the failure, whether buffered events are bounded and protected, and whether a later recovery produces duplicate or missing records. Do this in an isolated test environment. Do not assume that an undocumented fault-injection method is supported by the provider\u2019s monitoring product.<\/p>\n
Write down the application\u2019s behaviour during that gap. I would consider allowing low-impact drafting to continue while pausing actions that change external state, provided the application can enforce that distinction. Another organisation may require the entire workflow to stop. Either choice has a cost: continuing accepts reduced visibility; stopping creates an availability dependency. Leaving the choice unspecified simply hands it to the next outage.<\/p>\n
Yesterday\u2019s analysis of Unit 42\u2019s AI-assisted intrusion<\/a> focused on response across connected systems. This is where that response depends on the quality of the evidence reaching the team. A fast revocation process still needs to know which authority to revoke.<\/p>\n
A key change can interrupt the investigation<\/h2>\n
Customer-managed encryption gives the key owner consequential control over access. Put that owner in the incident plan. An emergency key operation can affect the monitoring store at the moment a reviewer needs to reconstruct events, so decide in advance how to preserve necessary evidence and how to restore an interrupted service.<\/p>\n
AWS\u2019s KMS deletion documentation<\/a> makes the distinction concrete. A deleted key cannot be recovered. Customer-managed key deletion has a mandatory waiting period of 7 to 30 days, and a key pending deletion cannot perform cryptographic operations. AWS also cautions that scheduling deletion may not immediately affect data keys already protected by that key.<\/p>\n
That makes \u201cdelete the key\u201d a poor generic containment instruction. For a design review, ask which access can be removed reversibly, what remains readable in caches or exports, and who can approve the change. Test the recovery path with a disposable key and fictional records. Record what the exercise demonstrates; do not extend it into a promise that every copy of plaintext has vanished.<\/p>\n
The evidence I would ask for before a pilot<\/h2>\n
These are proposed acceptance criteria for the enterprise deployment around an AI monitoring service. They describe observable outcomes and leave room for the provider to supply supported integration methods.<\/p>\n
\n\n\n\n\n\n\n\n\n\n\n
Decision<\/th>\nEvidence to request<\/th>\nAccountable owner<\/th>\n<\/tr>\n<\/thead>\n
Where is readable content retained?<\/td>\nA data-flow inventory covering logs, queues, exports and review tools, with a lifecycle for each copy.<\/td>\nData owner with the platform team<\/td>\n<\/tr>\n
Can the application alter its own evidence?<\/td>\nA synthetic write and an access test showing the application’s effective permissions.<\/td>\nCloud security engineer<\/td>\n<\/tr>\n
Who can read a flagged conversation?<\/td>\nA reviewer-role test and an audit event for the read, including any controlled identity lookup.<\/td>\nSecurity operations lead<\/td>\n<\/tr>\n
Will a missing event be noticed?<\/td>\nA supported delivery test, a visible integration-health signal and measured recovery behaviour.<\/td>\nService owner<\/td>\n<\/tr>\n
Can a reviewer stop harmful work?<\/td>\nA rehearsal connecting a fictional alert to a reversible pause of the affected workflow.<\/td>\nApplication owner with incident response<\/td>\n<\/tr>\n
What happens to old evidence?<\/td>\nA tested expiry process covering copies, with an explicit exception process for preserved investigations.<\/td>\nData owner with incident response<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
Storage charges are only part of the operating cost. Forecast the read volume from automated review, the access-audit volume and the time people spend resolving alerts. A low-priced storage tier may be unsuitable if retrieving evidence delays the reviewer beyond the workflow\u2019s response target. Use a pilot to measure those quantities instead of estimating every conversation as equally expensive.<\/p>\n
Questions teams will ask<\/h2>\n
Is Enterprise Frontier Safeguards generally available now?<\/h3>\n
As of 4 September 2026, the announcement describes a phased rollout later this fall. Confirm access and supported controls for your specific route to Claude before treating them as deployed.<\/p>\n
Does customer-held storage prove data residency or compliance?<\/h3>\n
Storage location answers one part of a larger review. Obtain the actual processing, support-access and transfer details, then assess them against your organisation\u2019s requirements. This article makes no certification or legal-compliance claim.<\/p>\n
Does misuse monitoring prevent prompt injection?<\/h3>\n
Do not treat an alerting capability as a substitute for action permissions. Your application should still check whether each proposed tool action is authorised, even when its monitoring is healthy. The AI gateway security field note<\/a> examines why the surrounding service authority matters.<\/p>\n
What should the first pilot demonstrate?<\/h3>\n
Use one workflow and synthetic data to show that an event arrives, a permitted person can inspect it, an unauthorised person cannot, and the application owner can act on the result. Then demonstrate recovery from a monitoring failure. Keep the evidence from those tests beside the deployment decision.<\/p>\n
I would put the first review rehearsal on the same calendar as the model pilot. Let the people who will own the alert experience the full path, including the permission they are missing and the evidence they cannot yet retrieve. Those gaps are much easier to close before a production conversation becomes an incident.<\/p>\n
<\/p>\n
One next action<\/h2>\n
If you run an agent that executes tools, AgentCrash<\/a> is an open-source harness that crash-tests it in a synthetic workplace: synthetic tools, visual evidence and regression tests. It is built for exactly this problem, turning a containment claim into something you can run against the system instead of arguing about it in review.<\/p>\n","protected":false},"excerpt":{"rendered":"
Anthropic EFS brings AI monitoring data into customer-controlled cloud storage. What CTOs should test around access, alert review, retention and recovery.<\/p>\n","protected":false},"author":0,"featured_media":30,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[12,21,18,46,45],"class_list":["post-29","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-notes","tag-ai-security","tag-anthropic","tag-cloud-security","tag-data-retention","tag-enterprise-frontier-safeguards"],"jetpack_featured_media_url":"https:\/\/www.0xprathamesh.com\/blog\/wp-content\/uploads\/2026\/09\/anthropic-efs-ai-log-custody.png","_links":{"self":[{"href":"https:\/\/www.0xprathamesh.com\/blog\/wp-json\/wp\/v2\/posts\/29","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.0xprathamesh.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.0xprathamesh.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.0xprathamesh.com\/blog\/wp-json\/wp\/v2\/comments?post=29"}],"version-history":[{"count":2,"href":"https:\/\/www.0xprathamesh.com\/blog\/wp-json\/wp\/v2\/posts\/29\/revisions"}],"predecessor-version":[{"id":95,"href":"https:\/\/www.0xprathamesh.com\/blog\/wp-json\/wp\/v2\/posts\/29\/revisions\/95"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.0xprathamesh.com\/blog\/wp-json\/wp\/v2\/media\/30"}],"wp:attachment":[{"href":"https:\/\/www.0xprathamesh.com\/blog\/wp-json\/wp\/v2\/media?parent=29"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.0xprathamesh.com\/blog\/wp-json\/wp\/v2\/categories?post=29"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.0xprathamesh.com\/blog\/wp-json\/wp\/v2\/tags?post=29"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}