Anthropic переносит данные защитного мониторинга в облако клиента

Попытка совместить ZDR и длительное обнаружение злоупотреблений

Anthropic анонсировала Enterprise Frontier Safeguards, или EFS, — архитектуру, в которой данные для safety monitoring хранятся не у Anthropic, а в cloud infrastructure самого клиента. Компания называет целью сочетание zero data retention со своей стороны и обнаружение злоупотреблений, которое требует видеть поведение не как изолированный prompt, а в динамике нескольких сессий и аккаунтов.

По объяснению Anthropic, сложные атаки могут быть разложены на множество задач, а скомпрометированные enterprise credentials трудно распознать по одному взаимодействию. Если каждый фрагмент мгновенно удалить, корреляция во времени становится невозможной. Ранее компания ввела 30-дневное хранение начиная с Fable 5, но регулируемые отрасли указали, что обычная retention policy не всегда совместима с их требованиями.

Что остаётся под контролем заказчика

EFS должна хранить activity data в аккаунте клиента — например, в Amazon S3, Azure Blob Storage или Google Cloud Storage. Заказчик управляет encryption keys, access policies, audit logging, retention period и удалением. Anthropic описывает модель, при которой автоматический мониторинг работает с этими данными, но человеческая проверка со стороны Anthropic не требуется: если событие нужно расследовать, это делает уполномоченная команда самого клиента.

Для банков, медицины, юристов и государственных организаций разница принципиальна. Внутренняя команда уже имеет допуски к непубличной информации, privileged legal material или safety reports, тогда как внешний reviewer может не иметь права видеть такой контент. Customer-controlled storage не отменяет мониторинг, но меняет границу доверия: Anthropic не становится владельцем архива корпоративной активности.

Не только хранилище

Согласно анонсу, EFS включает automated safety monitoring и workflow для customer-led review. Система должна помогать обнаруживать паттерны, которые становятся видимыми лишь при сопоставлении нескольких действий. Это не эквивалент запрету каждого подозрительного запроса: решение рассчитано на длительное злоупотребление и автономное поведение, где отдельные шаги могут выглядеть допустимо.

Anthropic утверждает, что разрабатывала EFS вместе более чем со 100 клиентами из финансов, healthcare, manufacturing, telecom, law, retail и public sector, а также с AWS, Google Cloud и Microsoft Azure. Заявлена поддержка Claude Code, Claude Enterprise, Claude Platform, Amazon Bedrock, Claude Platform on AWS, Google Agent Platform и Microsoft Foundry. Развёртывание планируется поэтапно, начиная позднее осенью 2026 года.

Ограничения анонса

Сейчас EFS — объявленная архитектура и план rollout, а не общедоступная функция с опубликованными результатами независимого аудита. В материале нет детальной схемы threat model, точных сроков хранения по умолчанию, измерений false positives или списка поддерживаемых регионов. Поэтому утверждать, что конфликт privacy и safety уже полностью решён, преждевременно. Проверяемый факт состоит в том, кому принадлежит инфраструктура хранения и кто выполняет human review.

Anthropic также подчёркивает, что не обучает модели на enterprise data без явного разрешения. Это отдельный вопрос от retention для защиты: отсутствие обучения не означает автоматического отсутствия журналов, а zero data retention у провайдера не означает, что заказчику запрещено хранить activity data в собственном контуре.

Почему это важно

EFS предлагает практический компромисс для компаний, которые одновременно обязаны расследовать злоупотребления и ограничивать передачу чувствительных данных поставщику модели. Если заявленная схема будет реализована последовательно, security team получит temporal correlation, а compliance team — контроль над ключами, доступом, аудитом и удалением.

Практический вывод: до подключения EFS организации стоит описать собственные категории activity data, период хранения, роли reviewers, правила escalation и порядок удаления. Отдельно нужно проверить, какие облачные журналы увидит Anthropic automation, какие метаданные покидают tenant и как отзывается доступ. Customer-owned bucket сам по себе не гарантирует compliance; ценность архитектуры появляется только вместе с минимальными правами, контролируемыми ключами и проверяемым audit trail.

До общего rollout полезен и технический threat-model review. Клиенту нужно проверить, может ли monitoring service читать исходный content или только выделенные signals, где выполняется анализ, как изолируются tenant data и что произойдёт при недоступности customer bucket. Отдельные тесты должны подтвердить rotation keys, deletion requests, export журналов и невозможность обхода review workflow привилегированным внутренним пользователем. Эти вопросы не опровергают анонс EFS, но определяют, сможет ли заявленная модель контроля пройти реальную проверку регулятора и внутреннего аудита.