На форуме Cursor разработчик рассказал, как запретил агенту работать с удалённой базой, а тот всё равно выполнил npx supabase db push. Эта команда отправляет локальные изменения схемы в подключённый удалённый проект. Агент мог изменить рабочую базу данных — и только после этого сам признал, что нарушил правило.

Модератор форума Cursor посоветовал сократить правила, убрать доступ к рабочей среде и настроить отдельную проверку, которая будет блокировать опасные команды перед запуском. Это один случай, а не статистика надёжности Cursor. Но он хорошо показывает цену забытого правила: иногда агент затрагивает внешнюю систему, где простого отката файла уже недостаточно.

У меня всё закончилось проще. Вчера я попросил Cursor разобраться с упавшим сквозным тестом. Я ждал исправления в приложении, но агент поменял проверку в самом тесте и отчитался, что всё готово. Тест, разумеется, прошёл.

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

Я заметил подмену при просмотре изменений. Откатил правку теста, повторил условие в чате и снова отправил агента искать причину падения. Почему правило не сработало, я точно не знаю. Возможно, оно потерялось среди кода, результатов поиска и нескольких запусков тестов, которые появились в разговоре позже.

Сначала я ограничил область, где можно править файлы в рамках задачи

Для этой задачи мне нужно разрешить агенту менять приложение, но не сквозные тесты. Я начинаю с Edit Scope — области, где файловым инструментам Veai разрешена запись.

Настраивается она прямо в чате:

1. Нажимаю + у поля ввода.

2. Прикрепляю файлы или папки приложения, которые агенту можно менять.

3. Включаю для них Edit Scope.

4. Отправляю задачу.

5. После работы открываю изменения и проверяю результат.

Остальной проект агент продолжает читать.

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

В публичной документации Cursor я не нашёл аналога такой границы записи на одну задачу. Упоминания @file и @folder добавляют файлы и папки в контекст. Но они не запрещают агенту менять остальной проект.

Более грубый вариант: .writeignore - запрет правит файлы во всех задачах

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

Для этого я создаю в проекте файл .veai/tools/.writeignore и добавляю в него шаблон:

tests/e2e/**

Синтаксис такой же, как у .gitignore. Veai по-прежнему может читать и запускать эти тесты, но его файловые инструменты не смогут их переписать.

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

У Cursor есть .cursorignore. Но он работает иначе: закрывает путь для агента, индексирования и редактора целиком, а не запрещает только запись. Документация отдельно предупреждает, что терминал и MCP-инструменты могут обращаться к таким путям в обход этого ограничения. Прямого аналога .writeignore в публичной документации Cursor я не нашёл.

Как защититься от изменения внешних систем?

Ни Edit Scope, ни .writeignore не остановили бы npx supabase db push. Эта команда через терминал меняет удалённую базу, а не файл проекта.

В Veai можно отдельно настроить каждый инструмент, доступный агенту. Я открываю меню Tools у поля ввода и перехожу в раздел Terminal Tools.

У каждого терминального инструмента есть три режима:

• крестик — полностью запретить;

• знак вопроса — спрашивать перед каждым вызовом;

• галочка — разрешить без подтверждения.

Для проекта с рабочей базой можно заставить запуск команд каждый раз спрашивать разрешение. Проблема в том, что к таким вопросам быстро привыкаешь. Первые две команды я читаю внимательно, а на десятой уже машинально нажимаю «Разрешить». Формально контроль остался, но пользы от него всё меньше.

Если включить автоматическое одобрение всех инструментов, в Veai остаётся ещё одна проверка. Сама модель оценивает операцию. Если она считает её опасной, то всё равно просит явное подтверждение. Запросов становится гораздо меньше, но у этого удобства есть цена: решение о том, опасна ли команда, снова принимает модель.

У Cursor похожую задачу решают permissions.json и режим Auto-review. Разрешённые вызовы проходят сразу, команды оболочки по возможности запускаются в песочнице, а остальные действия проверяет классификатор. Он может запросить подтверждение. Cursor прямо предупреждает, что такой классификатор может ошибиться и не считается полноценной границей безопасности. Компромисс тот же: меньше ручных подтверждений в обмен на решение модели о риске.

Что, если модель тупая и может принять опасную операцию за безопасную?

Автоматическая проверка всё равно зависит от модели. Она может решить, что команда безопасна, и выполнить её без вопроса. Поэтому особенно важные запреты я ещё и записываю в правила проекта, чтобы агент видел их во время работы.

В Veai 5.16 появилась Rule Strictness — настройка частоты повторения правил. В режиме system правило передаётся только при создании разговора. user-message повторяет его перед каждым новым сообщением пользователя. Для своего случая я выбрал tool-call: правило возвращается после каждого результата инструмента — чтения файла, поиска, правки или запуска теста - это максимально часто (я не верю в слабую модель, которую использую).

Моё правило сейчас выглядит так:

---
filePattern: "**/*"
strictness: tool-call
---

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

Правило создаётся из нового чата. Я задаю имя, выбираю Project, указываю filePattern, добавляю текст и выставляю strictness: tool-call. Для личного правила, которое должно работать во всех проектах, вместо Project выбрал бы Global.

После каждого вызова инструмента агент снова видит это короткое напоминание. Длинную методичку в этот режим ставить не стоит. Она будет повторяться много раз и занимать место в контексте, тратить токены. Но по мне так лучше пусть модель с меньшей вероятностью залезет куда не надо, а токены пусть тратятся.

Rules Cursor тоже можно подключать всегда, по шаблону файлов, по решению агента или вручную. Настройки, которая повторяет правило после каждого вызова инструмента, как tool-call в Veai, в публичной документации Cursor я не нашёл.

Как я проверяю результат

Способ проверки я выбираю по размеру и риску задачи.

Небольшие правки: просматриваю сам через Agent Changes

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

1. Дожидаюсь, пока агент закончит задачу.

2. Нажимаю Changes над полем ввода.

3. Выбираю Show diff view.

4. Открываю изменённые файлы по очереди.

5. Принимаю нужные правки и отклоняю лишние. Если всё хорошо, нажимаю Accept All.

6. Снова запускаю тест, с которого началась задача.

Например, в другом проекте я быстро просмотрел пару добавленных юнит тестов.

Подробнее: Agent Changes.

Средние правки: запускаю Auto Review

Auto Review пригодится, когда агент затронул несколько связанных файлов и глазами уже легко пропустить ошибку. Например, изменил сервис, модель данных и тесты или провёл рефакторинг внутри одного модуля. Это ещё не огромная задача, но второй взгляд уже полезен.

1. Дожидаюсь завершения задачи.

2. В строке с изменениями нажимаю Auto Review.

3. Жду, пока Review-субагент найдёт проблемы. Он смотрит на мою постановку задачи и сделанные изменения.

4. Выбираю интересные мне проблемы, прошу агента исправить.

5. После исправлений ещё раз просматриваю изменения сам.

Подробнее: Auto Review.

Большие правки: разбираю отчёт в Review

Окно Review удобнее для изменений в нескольких модулях, длинного списка находок или отдельной проверки ветки перед слиянием. Здесь замечания уже нужно фильтровать, группировать и разбирать по файлам, а к отчёту — возвращаться позже.

1. Перехожу в режим Review и прошу сделать ревью модуля, целой ветки или PRа.

2. После ревью нажимаю Open Report.

3. Отсматриваю находки, отмечаю ложные срабатывания.

4. Некоторые добавляю в чат через Add as Attachment и обсуждаю с агентом.

5. В итоге выделяю все реальные проблемы и нажимаю Fix with Agent.

6. При большом списке фильтрую находки по серьёзности и файлам.

7. После исправлений можно прогнать ревью агента ещё раз, когда изменения особо критичные.

Подробнее: Review Results.

Cursor тоже показывает изменения агента и создаёт контрольные точки, из которых можно восстановить состояние файлов. Отдельное ревью у него тоже есть: Agent Review работает в режимах Quick и Deep. Его можно запустить командой /agent-review, автоматически или из панели управления версиями. Где удобнее делать такие ревью — вопрос вкуса.

Что я в итоге оставил у себя

Если хотите повторить этот сценарий, установите Veai и возьмите обычную задачу. Ограничьте область изменений и добавьте короткое правило с tool-call. После работы агента откройте Agent Changes или запустите Auto Review. Лучше взять задачу, где агенту легко выбрать неправильный короткий путь. Например, исправить код, не переписывая падающий тест.