Когда AI-ассистент начинает выполнять задачи в продакшене, соблазн дать ему больше свободы велик. Но чем больше прав, тем выше риск. В статье на Habr описан кейс: AI-менеджер маркетплейсов получил доступ к API Wildberries, но для расчёта маржи, сроков поставки и аудита карточек ему требовались готовые инструменты. Команда решила не позволять менеджеру писать код самостоятельно, а поручила генерацию инструментов другой модели — Claude Opus — в изолированной службе. Менеджер мог только вызывать готовые функции. Разберём, как выстроить подобное разделение и какие ошибки подстерегают.

Зачем разделять генерацию кода и его выполнение

AI-менеджер постоянно обрабатывает внешние тексты (описания товаров, отзывы, запросы). Если он же пишет и выполняет код, любая инъекция в тексте может привести к нежелательным действиям: утечке ключей, изменению данных, обходу проверок. Изоляция генерации от выполнения снижает поверхность атаки. Генератор кода работает в отдельном контуре без доступа к секретам и продакшен-данным. Выполнение происходит только после проверки и подтверждения.

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

Как организовать изолированную службу генерации кода

Первый шаг — определить границы. Служба генерации не должна иметь сетевого доступа к продакшен-базам, API с секретами и файловой системе с ключами. Ей передаётся только описание задачи (спецификация) и, при необходимости, обезличенные примеры данных. Сгенерированный код сохраняется в артефактном хранилище и не выполняется автоматически.

  • Изоляция окружения: отдельный контейнер или виртуальная машина без исходящих соединений, кроме хранилища артефактов.
  • Спецификация вместо свободного промпта: менеджер формирует структурированный запрос: входные данные, ожидаемый результат, ограничения. Это снижает вероятность нерелевантного кода.
  • Проверка и тесты: сгенерированный код проходит статический анализ, юнит-тесты на синтетических данных и ревью человеком (или автоматическим агентом-ревьюером).
  • Версионирование: каждый инструмент получает версию и журнал изменений. Откат — обязательная возможность.

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

Права доступа и подтверждение действий

Даже готовый инструмент может быть опасен, если вызывается без ограничений. Нужна система прав: какие инструменты доступны менеджеру, какие параметры он может передавать, какие действия требуют подтверждения владельца. Например, чтение карточек — без ограничений, изменение цен или остатков — только после явного «да».

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

  • Разделяйте read-only и write-инструменты. Для write-операций требуйте подтверждения по умолчанию.
  • Ограничьте частоту вызовов и сумму изменений (например, не более N правок за сессию).
  • Логируйте все вызовы с параметрами и результатами — это основа для аудита и разбора инцидентов.

Типичные ошибки и как их избежать

Ошибка 1: доверять модели генерацию и выполнение в одном контуре. Даже с фильтрами риски остаются. Решение — физическое разделение сред и отсутствие секретов в среде генерации.

Ошибка 2: отсутствие спецификации. Свободный промпт «напиши инструмент для маржи» даёт непредсказуемый результат. Формализуйте входы и выходы, добавьте примеры.

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

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

Ошибка 5: отсутствие мониторинга. Без логов и алертов вы не узнаете о попытках обхода прав или аномальных вызовах. Настройте оповещения на подозрительную активность.

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