Представим учебную ситуацию: агенту поручили исправить фильтр в админке. Для проверки он запускает проектный скрипт, а тот подключается к общей базе и очищает таблицы. В постановке не было ни слова об удалении данных. Ошибка возникла раньше: рабочая среда позволяла действию с небольшим названием иметь слишком большие последствия.
Границы автономной работы нужно определять по доступным ресурсам: файлам, данным, сети и учётным записям. Текст задания объясняет намерение человека. Технические разрешения ограничивают то, что процесс действительно способен сделать. Одно дополняет другое.
Сначала составить карту доступов
Перед первой задачей с записью выясните, что доступно сессии. Рабочая папка — только часть ответа. Проверьте, какой адрес базы использует тестовый конфиг, куда отправляется почта, есть ли ключи облака в окружении и какие каталоги подключены в контейнер. Не выводите значения секретов в отчёт: достаточно имени ресурса и назначения среды.
| Ресурс | Что нужно для задачи | Граница |
|---|---|---|
| Код | Правки фильтра и его теста | Отдельная рабочая копия, исходные изменения сохранены |
| База | Учебные записи для проверки | Отдельная тестовая база с отдельной учётной записью |
| Почта | Проверка письма | Локальный перехватчик, без реальных получателей |
| Удалённый репозиторий | Чтение истории | Отправка изменений только в согласованном процессе |
Эту таблицу заполняют под конкретный проект. Она не означает, что агенту всегда нужна сеть или что чтение всех файлов безопасно. Если в каталоге лежит выгрузка клиентов, разрешение читать весь каталог уже шире задачи.
Название команды не описывает её полномочия
Разрешение на любой docker compose нельзя считать узким разрешением на тесты. Возможности зависят от сервиса, смонтированных путей, пользователя контейнера и доступа к Docker daemon. В документации Docker по безопасности доступ к управлению daemon рассматривается как существенная граница доверия. Контейнер с широкими доступами не становится безопасным от того, что его запускают для разработки.
Аналогично, отсутствие инструмента Edit не делает проверяющего агентом только для чтения, если ему доступен shell, способный записывать файлы. Отдельно задайте допустимые инструменты, файловые границы и сетевые доступы. Формат таких настроек зависит от используемого агента; универсальный JSON с разрешениями здесь только создал бы ложную уверенность.
Задание описывает границы результата
После настройки среды сформулируйте ограничения задачи. Для фильтра списка они могут выглядеть так:
Добавь фильтр по статусу публикации.
Работай с экраном списка и его тестами.
Существующие незакоммиченные изменения не отменяй.
Не меняй подключение к БД, настройки окружения и правила доступа.
Если нужен новый индекс или изменение схемы — сначала опиши причину.
Результат: diff и фактически выполненные проверки.
Публикация и выкладка в эту задачу не входят.Условие остановки связано с изменением риска: понадобилась новая среда, другой доступ или миграция. Произвольный предел в сто строк этого не заменяет. Две строки подключения к базе способны изменить больше, чем длинный шаблон страницы.
Проверить отказ на безопасной заготовке
Испытайте ограничения на отдельном учебном каталоге и временной базе без ценных данных. Попытка записи за разрешённую границу должна останавливаться средствами среды, а не только вежливым ответом модели. Повторите проверку через разрешённый shell: иначе вы протестировали лишь один путь записи.
Для опасных внешних действий используйте безопасный макет или проверку конфигурации. Не просите агента пробовать удалять продовую таблицу «чтобы убедиться в запрете». Отсутствие повреждений в одном прогоне не доказывает изоляцию. В отчёте нужны проверенная граница, способ проверки и остающиеся доступы.
Подготовить восстановление отдельно от разрешений
Ограничения уменьшают доступный ущерб, но не исправляют неудачную разрешённую правку. Сохраните исходное состояние кода, отделите чужие изменения и определите, что потребуется для отката данных. Коммит хранит код, а не содержимое базы и не отправленные письма.
Человек решает, какие действия допустимы для задачи, проверяет конфигурацию среды и принимает итог. Перед расширением доступа полезен один конкретный вопрос: какой новый ресурс станет доступен процессу и зачем он необходим сейчас? Ответ «так будет меньше подтверждений» описывает удобство, но ещё не обосновывает полномочия.
