Anthropic делает auto mode режимом по умолчанию в Claude Code. Начиная с 14 августа новые сессии на тарифах Pro, Max и Team будут запускаться в auto mode. Если пользователь уже установил другой режим по умолчанию, он может увидеть одноразовый запрос с предложением переключиться на auto mode. Если у пользователя закреплён (pinned) режим по умолчанию, для него ничего не изменится. Классификатор auto mode использует небольшое дополнительное количество токенов на каждый вызов инструмента, и с сегодняшнего дня Anthropic больше не взимает плату за этот оверхед с пользователей Pro, Max и Team.
Для Claude Enterprise, Claude API, Claude Platform на AWS, Amazon Bedrock, Agent Platform Google Cloud и Microsoft Foundry auto mode пока остаётся опциональным — это даёт администраторам время оценить изменение. В течение следующего месяца, совместно с облачными партнёрами, планируется сделать auto mode стандартным и для этих платформ, а также отменить плату за оверхед классификатора. Тем временем администраторы Enterprise могут сделать auto mode стандартным режимом через managed settings.
Auto mode спроектирован так, чтобы, с одной стороны, не отвлекать пользователей постоянными запросами, а с другой — помогать избегать вредоносных действий: вместо диалоговых окон каждый вызов инструмента проходит через классификатор, задача которого — блокировать действия, которые необратимы, деструктивны или направлены за пределы рабочего окружения пользователя. Когда классификатор что-то блокирует, Claude обычно самостоятельно находит более безопасный способ продолжить работу или напрямую спрашивает разрешения; если продвинуться не получается — три блокировки подряд или двадцать за сессию — Claude Code переключается обратно на режим ручного подтверждения.
Последние несколько месяцев в Anthropic проверяли, насколько auto mode безопасен по сравнению с обычным пользователем, кликающим по запросам подтверждения. Провели внутреннее red-teaming, red-teaming с привлечением третьих сторон и оценки на prompt-injection, контролируемое исследование с участием 1053 платных тестировщиков, а также анализ реальных production-сессий. По всем измеренным показателям auto mode сравнялся с ручным подтверждением или превзошёл его.
Auto mode также позволяет Claude работать автономно дольше. Это делает более практичным оставлять надолго запущенными модели, созданные для длительной работы, например Claude Opus 5, — на часы для крупных задач. Снижение накладных расходов пользователей также увеличивает объём выработки: среди команд и предприятий, перешедших на auto mode, пользователи создают примерно на 25% больше pull request'ов. Отсутствие блокировок позволяет Claude работать дольше без перерывов и выполнять больший объём работы. Команды в Adobe, Nuro, Gusto и Garner Health уже используют auto mode как production-режим по умолчанию.
Сравнение ручного подтверждения и auto mode
Данные показывают, что ручное подтверждение может стать чисто механической привычкой: пользователи одобряют 97% запросов на разрешение в Claude Code. Хотя большинство запросов, вероятно, относятся к безопасным рутинным командам, настолько высокий процент одобрения говорит о том, что многие пользователи кликают рефлекторно, а не рассматривают каждую команду отдельно. Эти запросы заставляют разработчиков принимать десятки или сотни важных решений по безопасности каждый день, часто в разгар работы над проектом, что перекладывает нагрузку проверки на пользователей и увеличивает вероятность того, что что-то важное будет пропущено. Данные также показывают, что пользователи чаще внимательно относятся к другим типам диалогов и чаще отказывают: например, когда Claude представляет план на одобрение, пользователи отклоняют 39% таких планов. Но для отдельных запросов на разрешение процент отказа составляет всего 3%.
Та же картина проявляется в файлах настроек. По состоянию на июнь 2026 года 49,5% активных пользователей CLI вручную создали правило allow для Bash — 5% разрешают выполнение любых команд оболочки без ограничений, а ещё 43% используют правила для интерпретаторов вроде Bash(python:*) или Bash(node:*), которые на практике по сути эквивалентны первому варианту, — и эта доля растёт примерно на 5 процентных пунктов каждые 5 недель. Помимо allow-правил, 62% пользователей использовали bypassPermissions или нажимали «больше не спрашивать» для Bash, а 25% интерактивных сессий начинаются в режиме bypass permissions.
Правила разрешений всё ещё срабатывают раньше классификатора в auto mode — за исключением allow-правил, достаточно широких, чтобы разрешать произвольное выполнение кода (например, python:*). Такие произвольные правила игнорируются в режиме auto mode, поскольку иначе они позволяли бы командам полностью обходить классификатор. Файлы настроек при этом не изменяются, и правила снова начинают действовать в момент переключения на другой режим.
Повышение безопасности с помощью auto mode
Исследования, проведённые внутри компании и с участием нескольких сторонних организаций, показывают, что auto mode безопаснее, чем то, как типичный пользователь сегодня взаимодействует с запросами на разрешение. Auto mode протестировали против того, что разработчики реально одобряют, кликая по запросам подтверждения. По каждому из этих измерений — внутреннему red-teaming, стороннему пентестингу и анализу реальных сессий — auto mode сравнялся с одобрением человеком или превзошёл его.
Auto mode превосходит ручные разрешения по безопасности

Для исследования наняли через агентство 1053 платных тестировщиков для участия в исследовании написания кода. Участники работали в тестовом окружении, созданном специально для исследования, а не в собственных кодовых базах и не на реальных проектах. Тестировщики знали, что их оценивают, но — в соответствии со стандартным дизайном слепого исследования — не знали, какое именно поведение измеряется. В середине каждой сессии один из запросов на разрешение подменялся явно опасной командой, и агентство фиксировало, одобрил ли тестировщик её (примечание: одобрение запроса никогда не приводило к реальному выполнению чего-то опасного — менялся только текст запроса, который видел тестировщик).
Тестировщики обнаруживали опасную команду лишь в 13,6% случаев (143 из 1053), тогда как auto mode блокировал те же команды в 89% случаев (937 из 1053). При прямом сравнении auto mode заблокировал 800 команд, которые человек одобрил, тогда как люди заблокировали лишь 6 команд, которые auto mode пропустил. С увеличением длительности сессии люди справлялись хуже: в начале сессии они блокировали около 17% опасных команд, а после 50 и более предыдущих запросов этот показатель падал до примерно 5%, тогда как процент блокировок auto mode оставался стабильным независимо от длительности сессии.
Auto mode предотвращает больше вредоносных действий
Исследование также показывает, что auto mode приводит к меньшему числу вредоносных действий, чем режим ручных разрешений.
Изучили, как auto mode работает в реальном использовании. С мая по июнь 2026 года были проанализированы сессии, отмеченные системой безопасности для проверки, — только из аккаунтов, давших согласие на использование данных для обучения и анализа. Каждую сессию переоценили с помощью модели по двум шкалам от 0 до 10. Первая шкала — тяжесть вреда: 10 означает необратимый вред в масштабе всей компании, например утечку всего исходного кода компании, 7 — вред уровня production, например удаление строк из production-базы данных, а 0 — полностью обратимое действие, ограниченное локальным рабочим пространством, например перезапись чернового файла. Вторая шкала — насколько явно пользователь запросил это действие, что позволило отделить вредоносные действия, прямо запрошенные пользователем, от вредоносных действий, которые агент совершил при менее явных указаниях.
Среди отмеченных сессий те, что прошли через ручное подтверждение, содержали серьёзный непреднамеренный вред более чем в два раза чаще, чем сессии в auto mode. На уровне серьёзности production (7 и выше) 6,3% сессий с ручным подтверждением содержали вредоносное действие, которое пользователь явно не запрашивал, по сравнению с 2,4% сессий в auto mode, и этот разрыв сохранялся на каждом уровне серьёзности из проверенных.
Состязательное red-teaming сделало auto mode устойчивее
Anthropic сотрудничала с британским стартапом в области безопасности AI, Apollo Research, в рамках двухнедельного пилота по внедрению синтетических атак в реальные траектории написания кода — на трёх наборах данных, охватывающих общие сбои, утечку данных и угрозы, связанные с безопасностью.
Работа велась по стандартному циклу «найти — исправить — проверить». Apollo предоставила набор успешных атак вместе с рекомендациями по усилению auto mode. Классификатор укрепили в первую очередь за счёт того, что дали ему больше контекста об окружении, которое он защищает (видимость репозитория, состояние git и правила обработки данных, описанные ниже).
После усиления Apollo повторно протестировала классификатор на отдельном закрытом наборе атак, доступа к которому у Anthropic не было. Auto mode обнаружил около половины атак, которые ранее пропускал, за счёт потери около 2% атак, которые ранее успешно обнаруживал. Поскольку настройку невозможно было подгонять под закрытый набор, это говорит о том, что усиление распространяется на новые атаки, а не просто закрывает конкретные дыры, которые показала Apollo. На объединённом наборе (общедоступном и закрытом) процент пропущенных атак классификатором снизился с 12% до 7%.
Эти атаки синтетические и намеренно состязательные — созданные специально для поиска слабых мест классификатора, и более злонамеренные, чем что-либо, что Claude сделал бы без провокации. 7% пропусков измерены именно на этом наборе и не отражают процент пропусков в реальном трафике.
Auto mode снижает риск prompt injection

Классификатор auto mode добавляет дополнительный уровень защиты от атак prompt injection, пытающихся заставить агента отклониться от инструкций пользователя. При работе в auto mode результаты вызовов инструментов проверяются специальными пробами на потенциально злонамеренные инструкции, а auto mode проверяет соответствие действий намерениям пользователя. Auto mode протестировали в сравнении с незащищённой моделью, чтобы показать эффективность такого многоуровневого подхода к защите.
Была заказана оценка у стороней организации, Trajectory Labs, которая протестировала разные модели в рамках последних публично доступных версий Claude Code и Codex на 17 июля 2026 года. Тестировщики прогнали 72 сценария непрямого prompt injection, скрытых от Anthropic. Каждый сценарий тестировался 10 раз. Успешные атаки в реальных условиях привели бы к необратимым действиям, способным нанести вред пользователю: утечке конфиденциальных данных, финансовому мошенничеству или фишингу учётных данных. Атаки были оптимизированы против Claude Opus 4.7, которая не входит в число отчётных моделей, поэтому все модели в оценке столкнулись с ними как с незнакомыми атаками. Помимо auto mode, в оценке рассматривались режим bypassPermissions Claude Code и режим Full Access Codex.
И Codex, и Claude Code оценивались с использованием идентичной интеграции с браузером, разработанной Trajectory Labs, PBC. Эта интеграция предоставляет набор MCP-инструментов, представляющих собой тонкую обёртку над стандартными API Chrome, такими как `navigate`. Защитные механизмы, встроенные в официальные браузерные интеграции — например, расширения Chrome от OpenAI и Anthropic, — не тестировались. Поэтому эти результаты следует рассматривать как оценку базовой модели, а не полного набора защитных механизмов, которые могут присутствовать в конкретном развёртывании.
В этой оценке ни одна из 720 попыток атак не увенчалась успехом против Claude Fable 5, Opus 5 или Sonnet 5, работающих в auto mode. В то же время 5,83% атак оказались успешными против GPT-5.6 Sol, работающей в режиме Auto-review Codex. Примечательно, что это выше среднего показателя успешности атак 0,09% против последних моделей Anthropic, работающих в режиме bypassPermissions без дополнительных защитных мер. Тесты показали 19,03% успешных атак против GPT-5.6 Sol при работе в режиме Full Access. Процент успешных атак различается между задачами, где инструменты возвращают результаты в виде текста, и задачами, требующими взаимодействия с браузером через скриншоты, как показано ниже.


Три инцидента, которые auto mode предотвратил внутри Anthropic
Auto mode также является режимом по умолчанию для всего внутреннего использования Claude Code в Anthropic. Вот три случая, когда классификатор предотвратил нежелательные действия внутри компании:
- Утечка данных за пределы сети: когда загрузка на внутренний диск не удалась, запасным вариантом для Claude стала публикация того же отчёта на публичном сайте для обмена кодом. Auto mode заблокировал этот запасной вариант и запросил у пользователя дальнейшие указания.
- Деструктивная массовая операция: в рамках длительной сессии Claude попытался выполнить массовое завершение процессов на примерно двух тысячах подов и поставил в очередь удаления, которые остановили бы задачи обучения, выполнявшиеся на сотнях GPU. Auto mode пометил деструктивные команды до их выполнения.
- Избыточное повышение привилегий: получив задачу настроить доступ только на чтение к биллингу, Claude попытался использовать облачную роль, дающую полный административный контроль на уровне root аккаунта. Auto mode обнаружил несоответствие между запрошенным доступом и тем, какие права были бы фактически предоставлены.
В каждом из этих случаев Claude либо самостоятельно нашёл более безопасный путь, либо уточнил у пользователя, прежде чем продолжить.
Дальнейшее повышение безопасности auto mode
В Anthropic непрерывно инвестируют в новые функции auto mode, которые делают его безопаснее и упрощают выпуск production-кода. Среди недавних примеров:
- Жёсткие запреты (hard denies): утечка данных — например, отправка кода или секретов куда-либо за пределы окружения — относится к категории действий, которые классификатор в принципе не одобрит. Чтобы выполнить такое действие, нужно выйти из auto mode или запустить команду самостоятельно. Правила жёсткого запрета настраиваются через settings, так что можно добавить собственные правила действий, которые никогда не должны быть разрешены, даже если их запросят пользователи в организации.
- Правила доступа к данным и их передачи: классификатор теперь содержит явные правила, различающие секреты и потенциально конфиденциальную информацию, а также то, где к ним можно получить доступ и куда их можно передавать. Чтобы эти правила можно было применять на практике, классификатор также проверяет, является ли адресат git push или pull request публичным, приватным или доверенным, прежде чем действие выполнится. Один и тот же push может быть рутинным или представлять собой утечку данных в зависимости от того, куда он попадает: код, который должен оставаться в приватном репозитории команды, не должен оказаться в публичном, и классификатор теперь помечает такие случаи.
- Проверка git status перед деструктивными действиями git: перед выполнением команды, которая может отбросить незакоммиченные изменения, например git reset --hard, классификатор видит текущий git status репозитория, что позволяет auto mode понимать, что именно будет сброшено.
- Проверка на prompt injection: когда Claude получает содержимое из внешних источников — веб-страниц, файлов или результатов работы инструментов — специальная проба на стороне API проверяет это содержимое на попытки перехватить управление поведением Claude. Если что-то похоже на попытку инъекции, в контекст Claude добавляется предупреждение, прежде чем результат будет показан пользователю.
Auto mode в production
Некоторые команды уже используют auto mode как режим по умолчанию в production:
- Команда платформы merchandising в Adobe отвечает за точность и актуальность страниц с ценами и промоакциями на Adobe.com в более чем 90 странах и на более чем 30 языках. Для сборки и проверки этих страниц команда построила агентный цикл, работающий в auto mode, так что инженеры получают на проверку уже готовые pull request'ы.
- Nuro использует auto mode во всей исследовательской и инженерной организации, применяя его для работы ночных исследовательских агентов, которые постепенно улучшают метрики оценки и к утру возвращают готовые pull request'ы на проверку.
- Gusto внедрила auto mode, чтобы избавиться от усталости от постоянных запросов разрешений, которая толкала инженеров к полному обходу проверок разрешений. Около 10% сессий с середины мая включают отказ классификатора — это свидетельствует, что механизм реально работает, не замедляя легитимные задачи.
- Garner Health сделала auto mode стандартным режимом для всех 550 сотрудников через managed settings, стандартизировав общекорпоративный цикл разработки ПО (SDLC), который больше не зависит от вручную составленных списков разрешённых команд.
Начало работы
Для пользователей Pro, Max и Team: если режим разрешений по умолчанию не был настроен, появится уведомление в продукте, и новые сессии будут автоматически запускаться в auto mode. Если был установлен другой режим по умолчанию, может появиться одноразовый запрос с предложением переключиться на auto mode. Если администратор команды установил режим по умолчанию через managed settings, для пользователя ничего не изменится.
Для пользователей Enterprise и тех, кто обращается к Claude Code через Claude API, auto mode пока остаётся опциональным. Планируется сделать его режимом по умолчанию в течение следующего месяца, предварительно уведомив администраторов Enterprise.
Чтобы переключить режим, нужно нажать Shift+Tab в CLI или использовать выпадающий список режимов в десктоп-приложении. Администраторы могут закрепить единый режим по умолчанию для всей организации с помощью параметра `defaultMode` в managed settings, либо полностью отключить auto mode параметром `disableAutoMode`.
Наконец, хотя в Anthropic считают, что auto mode снижает риски для большинства пользователей, он основан на системах классификации и поэтому не исключает риск полностью. Для критически важных изменений в production-инфраструктуре в компании всё равно рекомендуют самостоятельно проверять действия Claude. Полную инструкцию по настройке можно найти в документации по auto mode.