Как дать AI-агенту доступ к реальным системам и не потерять контроль

Сначала решите, нужен ли здесь агент

Если процесс можно надёжно описать обычным workflow, так и делайте. Модель не обязана выбирать следующий шаг, если этот шаг известен заранее. Например, сохранить заявку, проверить обязательные поля и уведомить менеджера — это нормальная детерминированная цепочка. Агент нужен там, где порядок действий зависит от контекста: разобрать запрос, найти данные в нескольких системах, выбрать подходящий сценарий и обработать исключение.

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

Инвентаризация инструментов важнее системного промпта

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

• прочитать карточку клиента;
• найти сделку;
• добавить внутреннюю заметку;
• изменить стадию;
• отправить сообщение;
• удалить запись.

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

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

Разделите действия по риску

Мы используем четыре практических уровня.

Риск зависит не только от названия действия. Письмо самому себе и массовая рассылка — разные инструменты. Чтение публичного каталога и чтение кадровых документов — тоже.

Не давайте агенту общий сервисный аккаунт

Безопаснее выполнять действие в контексте конкретного пользователя и его роли. Если менеджер не видит финансовый отчёт, агент менеджера тоже не должен его видеть. Если сотрудник не может менять права доступа, модель не должна получать это право через «техническую» учётную запись.

Это соответствует zero trust: нахождение внутри корпоративной сети само по себе не создаёт доверия. На каждом запросе важны идентичность, роль, ресурс и конкретное действие.

Подтверждение — отдельное состояние, а не вопрос в чате

Плохой approval выглядит так: «Вы уверены?» — «Да». Через пять минут непонятно, что именно подтвердил человек и не изменились ли параметры.

Хорошее подтверждение хранит:

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

В одной из наших архитектурных схем рискованный запуск переходит в отдельное состояние waiting_for_human. После подтверждения выполняется именно сохранённый план, а не заново сгенерированная версия. Это небольшая деталь, но она убирает класс ошибок «человек видел одно, модель сделала другое».

Защититесь от повторных действий

Агенты повторяют вызовы: из-за таймаута, сетевой ошибки, ретрая или непонятного ответа инструмента. Поэтому внешняя операция должна быть идемпотентной. Один submission_id — одна заявка; один payment_intent — один платёж; один ключ операции — одно изменение.

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

Журналируйте не мысли модели, а проверяемые события

Для разбора инцидента нужны факты:

1. кто инициировал задачу;
2. какая версия агента и политики работала;
3. какие инструменты были вызваны;
4. какие параметры прошли проверку;
5. что подтвердил человек;
6. какой внешний результат получен;
7. был ли откат.

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

Продумайте остановку до первого запуска

У агента должны быть stop conditions: лимит шагов, времени и стоимости; остановка после повторяющейся ошибки; запрет на смену цели; передача человеку, если действие не подтверждено или система отвечает неоднозначно.

И ещё — rollback. Для изменений файлов или кода мы предпочитаем изолированное рабочее пространство и контрольную точку до рискованного шага. Для CRM это может быть журнал предыдущих значений. Для отправленного письма настоящего rollback нет, поэтому отправка и требует более строгого gate.

Минимальный checklist перед production

• У агента нет универсальных инструментов и общих администраторских прав.
• Чтение, запись, отправка и удаление разделены.
• Высокорисковые действия требуют содержательного подтверждения.
• Повторный вызов не создаёт повторный внешний эффект.
• Все решения политики и действия попадают в аудит.
• Есть лимиты шагов, времени, стоимости и повторов.
• Негативные сценарии проверены до подключения реальных данных.
• Для обратимых операций существует проверенный rollback.

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