Почему автономный агент вообще может удалить файлы без возврата
За последнее время получила огласку не одна история, где ИИ-агент удалял файлы пользователя без возможности восстановления - мимо привычной корзины. Среди публично разобранных случаев - потеря крупной домашней медиатеки за считаные минуты автономной работы и потеря многолетних записей проекта из-за неудачной команды инфраструктурного инструмента.
Инженерный блог Docker формулирует происходящее так: агент работает от имени пользователя, в его файловой системе, с его правами, и между решением модели и выполнением в терминале ничего не стоит. Это не баг конкретного инструмента - это общее свойство модели исполнения, актуальное для любого агента на рынке. Значит, защита строится инженерными барьерами вокруг агента, а не надеждой, что модель сама будет аккуратнее.
Git-страховка: то, что не видят встроенные чекпойнты
Встроенные чекпойнты Claude Code делают снимок кода перед каждым сообщением и открываются командой отмены в чате, но они видят только правки самого агента через его инструменты редактирования - не команды терминала. Официальная документация формулирует это без обтекаемости: чекпойнты не отслеживают файлы, изменённые командами bash, и такие изменения нельзя отменить через встроенный откат. А удаление файла - это именно команда терминала.
Отсюда два простых правила. Перед каждой сессией агента - коммит рабочего состояния: git add -A && git commit -m "before agent session". На рискованную задачу - массовую чистку, миграцию, рефакторинг - отдельная ветка, а не основная: git checkout -b risky-task. Исключение - файлы вне git, например домашняя медиатека: там страховкой служит обычный бэкап, а не коммит.
Какой permission-режим выбрать
У Claude Code несколько режимов прав - от полностью ручного до режима, где разрешено практически всё. Режим default выполняет без запроса только чтение - подходит для старта и чувствительных задач. Режим plan позволяет агенту читать и исследовать терминалом, но не менять файлы до вашего одобрения - хороший выбор для незнакомой задачи. Режим acceptEdits удобен для итераций над знакомым кодом, но автоматически разрешает и команды удаления и перемещения файлов - то есть ровно то, что чаще всего портит проект без спроса.
Режим с полным доступом Anthropic прямо рекомендует использовать только в изолированных контейнерах или виртуальных машинах без выхода в интернет, где агент физически не может навредить основной системе. На рабочей машине с реальными файлами включать его не стоит, даже если хочется ускорить работу.
Что запретить агенту явно: allow/deny в настройках
Даже с правильным permission-режимом отдельные команды стоит запретить явным списком в файле настроек проекта - классика - случайное чтение файла с переменными окружения или коммит с секретом внутри.
{
"permissions": {
"allow": ["Bash(npm run lint)", "Bash(npm run test *)"],
"deny": [
"Bash(curl *)", "Read(./.env)", "Read(./.env.*)",
"Read(./secrets/**)", "Read(~/.ssh/**)", "Read(~/.aws/**)"
]
}
}Если секрет уже попал в git-историю, почистить только текущий файл недостаточно - нужно чистить всю историю коммитов, а единственная настоящая гарантия - отозвать сам ключ у источника.
Зачем нужен sandbox, если права уже настроены
Permission-режимы решают, что агенту можно запустить. Sandbox решает, куда он физически может дотянуться на диске и в сети, пока команда выполняется. Без сетевой изоляции скомпрометированный или ошибшийся агент теоретически способен вынести приватные файлы вроде SSH-ключей наружу - именно от этого класса риска защищает песочница.
Исследователь безопасности Саймон Уиллисон описывает логику этой защиты в концепции «смертельной триады»: единственный способ оставаться в безопасности - избегать одновременного сочетания доступа к приватным данным, обработки чужого непроверенного контента и канала во внешний мир. Такая защита работает только тогда, когда она встроена в инструменты и настройки вокруг агента, а не держится на просьбе к модели быть аккуратнее.
Куда прятать токены и переменные окружения
Секреты должны жить в отдельном файле переменных окружения, который добавляется в список игнорируемых файлов git до первого коммита и никогда не попадает в историю версий. Агенту не стоит давать читать такой файл напрямую, а для тестовых задач лучше использовать отдельный ключ с коротким сроком жизни и низкой квотой, а не боевой ключ проекта.
Чек-лист
- Есть свежий коммит перед последней сессией агента
- На новую или рискованную задачу включён режим plan, а не полный доступ
- Включён sandbox, credentials вроде ~/.ssh и ~/.aws закрыты явно
- В настройках прописаны deny-правила хотя бы на .env и .env.*
- Перед принятием коммита от агента открыт git diff, а не только текстовый пересказ
Агент со страховкой - это сотрудник с регламентом
Права агента определяют радиус поражения на случай ошибки - вопрос доверия к модели здесь вторичен. Сотруднику с чётким регламентом можно доверить многое именно потому, что регламент ограничивает последствия одной конкретной ошибки. С агентом работает та же логика: широкая автономность безопасна ровно настолько, насколько под ней есть инженерная страховка - git-коммит перед сессией, permission-режим под задачу, sandbox с закрытыми credentials и секреты вне git-истории.