Теория: Безопасность при работе с coding agents

Агент умеет запускать команды, редактировать репозиторий, ходить в сеть и в некоторых случаях взаимодействовать с внешними системами. Из-за этого вопрос безопасности стоит сразу и остро. По умолчанию, агенты непрерывно спрашивают можно ли совершить то или иное действие, чем сильно раздражают, потому что невозможно отвлечься от экрана иначе все встает колом. Что с этим делать?

Почему агент вообще что-то спрашивает

Если смотреть на современный coding agent упрощенно, то внутри почти всегда есть три части. Первая - сама модель, которая пытается понять задачу и решить, какой следующий шаг логичен. Вторая - инструменты: чтение файлов, запись, shell-команды, git, сеть, браузер и так далее. Третья - прослойка между ними, которая решает, какие действия разрешены, какие запрещены, а какие нужно сначала подтвердить у человека.

┌──────────────┐      ┌──────────────────┐      ┌──────────────┐
│              │      │   Прослойка      │      │              │
│    Модель    │─────▶│   безопасности   │─────▶│  Инструменты │
│              │      │                  │      │              │
│   "Хочу      │      │  ✓ Разрешено     │      │  Файлы       │
│    удалить   │      │  ? Спросить      │      │  Shell       │
│    файл"     │      │  ✗ Запрещено     │      │  Git, Сеть   │
└──────────────┘      └──────────────────┘      └──────────────┘

Именно эта прослойка и создает знакомый всем опыт: агент постоянно спрашивает, можно ли прочитать какой-то путь, записать файл или запустить команду. Так устроена базовая защита: система пытается не дать языковой модели слишком легко превратить текстовое предположение в реальное действие над вашим проектом или машиной.

Важно увидеть в этом правильную логику. Проблема у агента не в том, что он иногда ошибается в ответах. Проблема в том, что он может уверенно ошибиться действием. Он может не только предложить команду rm -rf, но и реально попытаться ее выполнить. Интернет полон статей о том, как агенты уничтожали инфраструктуру и стирали данные из продакшен баз.

Проблема ожидания

Однако тут почти сразу появляется обратная сторона. Если агент спрашивает разрешение на каждом заметном шаге, работа начинает рассыпаться. Вы поручили ему исследовать проект, а он останавливается каждые 10 секунд: разрешить чтение, разрешить запись, разрешить еще одну команду, разрешить еще один вызов. Вместо ощущения ускорения возникает чувство, что вы стали оператором всплывающих окон.

Из-за этого многие пользователи довольно быстро приходят к соблазну: а давайте просто отключим лишние подтверждения, дадим агенту побольше прав и пусть уже работает как взрослый. На короткой дистанции это действительно выглядит как решение. Сессия идет быстрее, агент меньше тормозит, у вас меньше трения. Но дальше возникает следующий вопрос: а что именно мы ему открыли и какова цена?

Как это обходят небезопасно

Самый очевидный, но и самый опасный путь - дать агенту полный доступ к рабочей среде. Например, запускать его прямо на основной машине без ограничений, с доступом ко всему домашнему каталогу, с уже активными credentials в shell, с рабочим VPN, с открытым доступом к сети, к репозиторию и к продовым сервисам. В таком режиме агент действительно перестает задавать лишние вопросы, но только потому, что ему уже почти ничего не нужно спрашивать.

Проблема такого подхода в том, что ошибка модели сразу становится ошибкой в реальном окружении. Агент может удалить не те файлы, переписать конфиг, установить сомнительную зависимость или просто выполнить команду не в том каталоге. И это происходит с лучшими из нас. Самое опасное, работать там где уже лежат боевые токены и доступы. Например, у вас в терминале настроен kubectl на реальный кластер или в переменных окружения доступны ключи от внешних сервисов. Тут все по закону Мерфи. Если есть возможность что-то сделать не так, он рано или поздно это сделает.

Как это обходят безопасно

Нормальный путь это уменьшать цену разрешенных действий. То есть строить такую рабочую среду, где агент может действовать достаточно свободно, но возможный ущерб все равно ограничен.

На практике это означает несколько простых принципов. Во-первых, агенту лучше давать доступ не ко всей машине, а только к конкретному проекту или даже к отдельной рабочей директории. Во-вторых, для его работы лучше использовать тестовые базы, временные credentials, отдельные токены с минимальными правами и окружения, которые не жалко пересоздать. В-третьих, подтверждения особенно нужны не для каждого чтения файла, а для действий с высокой ценой ошибки: сетевых запросов, удаления данных, git-операций и всего, что касается продакшен окружения.

Часть проблем решается тем, что мы работаем с git-репозиторием и если регулярно сохраняться, то любые ошибочные правки без проблем откатываются. Но чтобы не терять нужные правки, имеет смысл после каждого изменения, которое вас устраивает, как минимум делать git add или даже git commit.

Autopilot

Во многих агентах есть режимы вроде autopilot. Это отдельный режим работы с сохранением части защит, где некоторые решения о безопасности система принимает сама. Например, в Claude Code перед выполнением заметной операции действие может проверяться отдельной моделью-классификатором: она смотрит, соответствует ли шаг задаче, не выходит ли он за границы доверенного окружения и не выглядит ли как следствие prompt injection.

То есть autopilot находится где-то посередине между ручными подтверждениями и режимом "делай вообще все". Часть действий проходит автоматически, часть отправляется на дополнительную проверку, а при серии подозрительных или заблокированных операций система может откатиться обратно к запросам подтверждения. Это важное отличие от режима без проверок, где любой вызов инструмента исполняется сразу.

Но переоценивать такой режим не стоит. Внутренний анализ риска полезен, но он все равно недетерминированный и тоже может ошибаться. Более того, у таких режимов обычно есть собственные допущения о том, что считать нормальным: например, локальные операции в рабочей директории могут считаться безопасными по умолчанию, а известные git-репозитории или заранее объявленные зависимости доверенными. Если эти допущения не совпадают с вашим реальным риском, защита получается слабее, чем кажется.

Поэтому autopilot имеет смысл там, где возможный ущерб уже ограничен извне: в отдельной ветке, внутри сендбокса, с временными токенами и без доступа к чувствительным системам. Для локальной разработки и исследовательских задач это практически идеальный инструмент. Для прода так лучше не делать :)

Безопасность                                            Скорость
  ◀──────────────────────────────────────────────────────────────▶

  ┌─────────────┐     ┌─────────────────┐     ┌───────────────┐
  │  Ручные     │     │                 │     │  Без          │
  │  подтвержде-│     │   Autopilot     │     │  ограничений  │
  │  ния        │     │                 │     │               │
  │             │     │  Часть действий │     │  Агент делает │
  │  Каждое     │     │  автоматически, │     │  всё сам,     │
  │  действие   │     │  опасные —      │     │  ничего не    │
  │  через      │     │  на проверку    │     │  спрашивая    │
  │  "можно?"   │     │                 │     │               │
  └─────────────┘     └─────────────────┘     └───────────────┘
        ▲                     ▲                       ▲
     Медленно,          Разумный               Быстро, но
     но надёжно         компромисс             рискованно

Сендбоксы

Идея у сендбоксов очень простая: если агент может ошибиться, то пусть ошибается внутри ограниченного контура, из которого ошибка не вытекает слишком далеко. Тогда можно ослабить часть ручного контроля, не открывая ему весь реальный мир.

Сендбоксом может быть devcontainer, виртуальная машина, отдельный пользователь в системе или специально поднятый workspace с тестовыми данными. Уже существуют специализированные решения под эту задачу, например, Docker Sandboxes.

cd ~/my-project
docker sandbox run claude

Это решает сразу несколько задач. Во-первых, снижается риск случайно задеть что-то вне проекта. Во-вторых, проще вводить ограничения. В-третьих, если агент все-таки натворил дичи, окружение можно просто пересоздать.

Но сендбокс не 100% гарантия, в конечном итоге все упирается в кожанного. Если внутрь изолированной среды проброшены боевые ключи, то однажды закон мерфи сработает.

┌─ Хост-машина ──────────────────────────────────┐
  │                                                │
  │  ~/.ssh/   ~/.aws/   kubectl   prod-токены     │
  │                                                │
  │  ┌─ Сендбокс (контейнер / VM) ──────────────┐  │
  │  │                                          │  │
  │  │  Проект      Тестовая БД    Временные    │  │
  │  │  /app        SQLite         токены       │  │
  │  │                                          │  │
  │  │  Агент работает здесь ◀── autopilot: on  │  │
  │  │                                          │  │
  │  └──────────────────────────────────────────┘  │
  │          ▲ нет доступа к хосту                 │
  └────────────────────────────────────────────────┘