«Дайте агенту доступ к терминалу и файловой системе, и он сам всё сделает» звучит привлекательно ровно до первого случая, когда агент вместо тестового файла отредактировал конфиг продакшена, или переписал файл с ключами API, потому что тот «мешал» задаче. После этого в компании обычно появляется вопрос от безопасника или тимлида: а как мы вообще контролируем, что этот агент делает с кодом?

Проблема в том, что «контроль над агентом» - это не один переключатель в настройках. Это набор независимых механизмов, каждый из которых ограничивает что-то своё: что агент видит, куда может писать, насколько самостоятельно действует и кто проверяет результат. «Разберём эти механизмы по отдельности на примере того, как это устроено в Veai — агенте, который работает и в OpenIDE, и в JetBrains IDE; в статье возьмём плагин для JetBrains IDE, потому что на нём проще показать конкретные экраны и файлы: так проще говорить предметно, а не абстрактно.»

Уровень 1: что агент видит и куда может писать

Как не дать агенту прочитать мои секреты из .env?

За это отвечает .readignore: файл в .veai/tools/ с синтаксисом .gitignore. Если путь попал туда, агент не увидит файл вообще: ни на чтение, ни на запись, файл просто не попадёт в его контекст.

# .veai/tools/.readignore
.env
secrets/**

Как защитить конфигурации деплоя и собственные инструкции агента от случайной правки?

За это отвечает .writeignore: файл с тем же синтаксисом .gitignore, но с другим эффектом. Если путь попал туда, агент может прочитать файл, но не может его отредактировать. Это подходит для файлов, которые агенту полезно видеть для контекста, но трогать не нужно: docker-compose.yml, манифесты Kubernetes, сам AGENTS.md, который агент не должен иметь возможность переписать.

# .veai/tools/.writeignore
docker-compose.yml
k8s/**
AGENTS.md

Классическая ситуация: агент чинит баг, не может разобраться в логике за разумное число попыток и вместо этого меняет ожидание в самом тесте, чтобы тот стал зелёным. Тот же соблазн работает и с другими файлами: конфигурацией деплоя (docker-compose.yml, манифесты Kubernetes) или собственными агентскими настройками вроде AGENTS.md, которые агент может решить «заодно поправить», раз они всё равно попали в контекст.

Edit Scope ограничивает не отдельные файлы, а всю область редактирования сразу: агент видит весь проект, но может предлагать и применять правки только внутри прикреплённых файлов и папок. Если прикрепить к задаче только исходный код модуля, не трогая тесты, конфигурацию деплоя и AGENTS.md, агент физически не сможет отредактировать ни то, ни другое, ни третье: он сможет только прочитать эти файлы для контекста. Это ровно то, что нужно для TDD: код можно менять, а тесты трогать нельзя, тогда агенту приходится чинить причину, а не следствие. Разница с .writeignore в масштабе: Edit Scope удобно включать на время конкретной задачи («на эту задачу трогай только модуль X, тесты и конфиги не прикрепляй»), а .readignore и .writeignore задают постоянную политику проекта, которую можно закоммитить и раздать команде.

Агент по умолчанию ограничен корневой директорией проекта и не читает произвольные файлы на диске за её пределами.

Уровень 2: как агент понимает границы задачи

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

Как договориться с агентом о едином формате тестов, например писать их только в стиле given-when-then?

За это отвечают Rules: markdown-фрагмент с glob-паттерном, который применяется, когда открытый файл соответствует шаблону. В правиле можно закрепить конкретный стиль: писать тесты только в формате given-when-then, называть переменные по единой конвенции, использовать определённый паттерн для новых сервисов. Правила можно хранить локально, только у себя, или в репозитории проекта, тогда вся команда работает по одним и тем же рекомендациям.

Как не объяснять агенту структуру проекта заново в каждом новом чате?

За это отвечает AGENTS.md: открытый стандарт файла в корне проекта, где описаны домен, структура репозитория и то, что нельзя трогать без подтверждения. Он не заменяет Rules, а даёт агенту общий контекст, чтобы не приходилось описывать устройство проекта в каждом чате с нуля.

Уровень 3: сколько автономности даёт режим

Как быть уверенным, что агент в режиме код-ревью не отредактирует файл случайно?

За это отвечает выбор режима работы: часть режимов физически не имеет инструментов для изменения кода.

Ask и Review работают в режиме только для чтения

Агент может искать, читать, объяснять, находить проблемы, но физически не имеет инструмента для правки файла. General - единственный режим кроме Orchestrator, который может вызывать субагентов, а привилегия вызывать инспекции IDE без доступа к терминалу и дебаггеру закреплена только за Review - в этом и его отличие от Ask.

Как не переплачивать за топовую модель, когда прошу агента внести мелкую правку?

За это отвечают профили субагентов (Model Routing): можно закрепить конкретную модель за конкретным типом подзадач. Например, для поиска по коду и чтения файлов взять дешёвую и быструю модель, а для сложного рефакторинга и глубокого ревью - модель с лучшим качеством понимания кода. Это тоже форма контроля, только не над тем, что агент может трогать, а над тем, какая модель принимает решения в каждой подзадаче и сколько это стоит.

Уровень 4: что происходит после

Даже если агент отработал полностью автономно, последнее слово должно оставаться за человеком.

Как проверить, что именно поменял агент, прежде чем это попадёт в коммит?

За это отвечает Agent Changes - окно, похожее на список изменений перед коммитом: слева файлы из текущего чата, справа diff по выбранному файлу. Можно принять правки целиком, отклонить часть или пройтись по каждому файлу отдельно. Изменения из разных чатов не смешиваются.

Как найти SQL-инъекцию, которую агент не заметил в собственном диффе?

За это отвечает отдельный движок статического анализа (SAST). Он работает на скомпилированных исходниках и отслеживает путь данных от источника (например, параметра HTTP-запроса) до опасной точки (например, SQL-запроса) в границах всего проекта, включая связи между функциями и классами. Анализ работает офлайн, без отправки кода куда-либо, и сейчас поддерживает Java и Kotlin в IntelliJ IDEA и Android Studio.

Находки попадают в отдельное окно Review вместе с результатами любой другой ручной проверки: список находок с привязкой к файлу и строке, кнопка «Исправить с помощью агента» на каждую проблему.

Финальное решение всё равно принимает человек в окне Agent Changes, но благодаря инспекциям у Review-агента есть опора не только на то, что модель заметила в диффе на глаз.

Уровень 5: расширения тоже под контролем

MCP-серверы, открытый протокол для связи LLM с внешними сервисами, дают агенту доступ к внешним инструментам: GitHub, таск-трекеры, поисковики и так далее.

Как не тащить токен GitHub MCP-сервера в проект, которому он вообще не нужен?

Конфигурацию MCP-серверов можно привязать к конкретному проекту (.veai/mcp_servers.json), а не разливать глобально на все проекты сразу.

Как не хранить токен MCP-сервера открытым текстом в конфиге, который лежит в репозитории?

Токены и ключи в конфиге не обязаны лежать открытым текстом: их можно подставлять из переменных окружения через плейсхолдер ${env:ИМЯ_ПЕРЕМЕННОЙ}.

Как подключить MCP-сервер JetBrains, не копируя вручную его адрес?

Если в IDE включён встроенный MCP-сервер JetBrains, Veai подключает его автоматически: адрес сервера не нужно копировать и добавлять в список MCP-серверов руками. После подключения инструменты JetBrains MCP доступны агенту вместе с остальными MCP-инструментами.

Что делать, если агент перестал работать после подключения пары MCP-серверов?

Раньше лимит инструментов чата составлял 128. Крупные MCP-серверы предоставляют десятки инструментов: например, GitHub - около 70 (прочитать issue, прочитать PR, посмотреть уведомления, поставить звезду и так далее). Достаточно было подключить 2-3 таких сервера, и агент переставал работать, потому что лимит исчерпывался.

Теперь, если суммарное число инструментов превышает 128, каждый MCP-сервер оборачивается в отдельного субагента. Основному агенту доступен только один инструмент для обращения к серверу, а полный набор команд остаётся внутри субагента. Если сервер небольшой (например, DuckDuckGo на 2 инструмента) и общий лимит не превышен, он работает как раньше, без запуска субагента. Настраивать ничего не нужно: плагин сам определяет, когда использовать субагентов, а когда работать напрямую.

Во время вызова в чате появляется раскрывающаяся панель Running <mcp_server>. Внутри Progress видно, какие инструменты использует субагент, а когда вызов завершится, результат появится в блоке Finished.

Уровень 6: куда уходит код и где работает модель

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

Здесь есть три варианта, и они выбираются тарифом и настройками, а не зашиты внутри кода агента:

• Платная подписка или флекс-пак (поминутная оплата доступа к топовым моделям OpenAI, Anthropic, Google и китайских провайдеров): код и промпт уходят по контролируемому каналу выбранному провайдеру модели, без обучения на данных пользователя.

• BYOK, свой API-ключ провайдера (в т.ч. в бесплатном тарифе «Сообщество»): данные идут напрямую выбранному провайдеру по его собственной политике, минуя серверы Veai.

• Локальные и on-premise модели (в контуре компании, через VPC или полноценное on-premise развёртывание): код вообще не выходит за пределы инфраструктуры компании.

В любом платном режиме заказчик сам выбирает провайдера модели, вместо того чтобы это решал вендор. Для enterprise-клиентов доступны отдельные контуры развёртывания: on-premise, частное облако (VPC) или self-hosted, с конкретной конфигурацией и моделью под их инфраструктуру и требования безопасности.

С файловым контролем это стыкуется Edit Scope из первого раздела: если в работе с моделью надо исключить отдельные файлы или папки, можно заранее ограничить, что вообще видит агент, ещё до того, как выбран канал доставки кода до модели.

Где это работает: матрица функциональности по IDE

Ни один из описанных выше механизмов контроля не является эксклюзивом IntelliJ IDEA. Согласно официальной матрице функциональности Veai, почти всё из этой статьи работает одинаково в семи поддерживаемых JetBrains IDE:

Строка в таблице одна и требует отдельного пояснения: статический поиск уязвимостей (SAST) завязан на анализ скомпилированных Java/Kotlin-исходников, поэтому доступен только в IntelliJ IDEA и Android Studio - в PyCharm, GoLand, Rider, WebStorm и PhpStorm этого слоя контроля нет вообще, и рассчитывать на него там не стоит. Остальные шесть уровней контроля из этой статьи - файловые ограничения, Rules, AGENTS.md, режимы, Agent Changes, MCP - в этих IDE доступны: базовые механизмы контроля не привязаны к конкретному языку проекта.

Чего контроль не гарантирует

Опишем честно, где проходят границы этого набора инструментов:

• Rules и AGENTS.md - это рекомендация агенту, а не строгое правило (см. уровень 2): модель может её не заметить или отступить от неё под влиянием других сигналов в промпте.

• .writeignore защищает от записи, но не от чтения. Если файл не должен попасть в контекст модели вообще, нужен .readignore.

• Edit Scope ограничивает, куда агент может писать, но не то, что он может прочитать: весь проект остаётся видимым.

• Auto Review - вероятностный инструмент: независимый Review-агент читает диф и может пропустить проблему или дать ложный совет. Поиск уязвимостей (SAST) работает иначе - это детерминированный анализ потока данных по скомпилированному коду, а не догадка модели по тексту, но он покрывает конкретный класс уязвимостей и только Java/Kotlin, а не любые ошибки.

• Выбор провайдера модели (provider control) отвечает только за маршрут данных к модели: куда уходит код и промпт для запроса. Какие файлы попадают в этот запрос внутри проекта, регулируется отдельно, через Edit Scope, .readignore и .writeignore.

• Ни один из этих механизмов не отменяет того, что итоговое решение (принять правку или отклонить) остаётся за человеком в окне Agent Changes.

Главное

• «Контроль над агентом» складывается из независимых уровней: доступ к файлам, инструкции о поведении, автономность режима, проверка после работы, безопасность расширений, маршрут кода до модели. Каждый уровень закрывает свою конкретную ситуацию и не заменяет остальные.

• Для жёстких гарантий («это точно нельзя тронуть») нужны файловые механизмы, и они решают разные задачи: .readignore скрывает файл от модели полностью, ещё на этапе сбора контекста, а .writeignore и Edit Scope разрешают читать файл, но запрещают его редактировать.

• Rules и AGENTS.md задают поведение агента в типовых сценариях (не трогать миграции, спросить перед правкой публичного API), но это инструкция для модели, а не техническое ограничение.

• Режимы только для чтения (Ask, Review) полезны там, где даже теоретическая возможность случайной правки нежелательна.

• Когда важно не только что агент делает в проекте, но и куда уходит код, поможет выбор провайдера модели: подписка на топовые модели, свой API-ключ (BYOK) или локальная либо on-premise модель в контуре компании.

• Diff-окно перед принятием правок - последний шаг перед человеком, а отдельный ревью-проход перед ним опирается не только на текст диффа, но и на инспекции IDE и статический анализ, а не только на то, что заметила модель на глаз.

Veai - платформа для разработки с ИИ, в которую входит Veai AI Agent для OpenIDE, GigaIDE и JetBrains IDE. Агент опирается на факты из IDE - отладчик, рефакторинги, навигация по символам, инспекции - а не только на текст в контексте, и помогает отлаживать, рефакторить, тестировать, собирать и запускать проекты прямо из IDE. Подробное описание всех перечисленных механизмов: матрица возможностей, документация. Обратная связь: support@veai.ru, чат с командой: t.me/veai_devs.