Когда ИИ-агенту дают право вызывать внутренние API, спор быстро смещается с «может ли он сделать запрос» на «кто это разрешил и как быстро это отозвать». Раньше казалось, что главная задача — фильтровать трафик. На практике важнее управление доступом к операциям, журналирование и понятный отзыв прав.

Почему контроль операций важнее проверки трафика

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

Инспекция запросов смотрит на форму, а не на полномочия. Она помогает ловить ошибки формата и грубые инъекции, но не понимает, имеет ли агент право менять лимит клиента или только читать карточку.

Именно поэтому в корпоративном контуре важен не общий доступ к системе, а доступ к отдельной операции. Это тот же принцип, который описан в разборе про безопасность MCP и доступ AI-агентов: меньше прав, меньше сюрпризов.

Три рабочих подхода и чем они отличаются

Один агент — одно приложение и свои ключи

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

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

Публикация не системы, а отдельных инструментов

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

Но одной видимости мало. Запрет должен работать на стороне шлюза или API-менеджера, иначе известное имя инструмента можно вызвать напрямую. Именно поэтому публикация и авторизация должны идти вместе.

Прокси с контролем ревью и версий

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

Слабое место — изменения на стороне исходного сервера. Описание инструмента передаётся в контекст модели, а значит, любое правки нужно ревьюить, версионировать и повторно проверять. Иначе в контур легко занести скрытую инструкцию или подмену имени.

Что обычно проверяет служба безопасности

ИБ смотрит не на красивую архитектурную схему, а на управляемость. Первое — кто владеет операцией и кто подтверждает её публикацию. Второе — можно ли отозвать только одну подписку, не ломая всё приложение.

Третье — есть ли журнал, где видно инициатора, время и результат вызова. Без этого через месяц никто не соберёт картину инцидента. Четвёртое — как устроены лимиты: на приложение, на подписку или на отдельную операцию.

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

Кому что подходит

Небольшой команде обычно хватает схемы «одно приложение — один агент — ограниченный набор инструментов». Она проще в сопровождении и быстрее проходит согласование.

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

Для сложных контуров с несколькими внутренними API подходит вариант с проксированием и жёстким ревью изменений. Это дольше и дороже, зато даёт более внятный контроль над тем, что именно агент умеет делать.

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

Практический вывод

Хорошая схема для ИИ-агента начинается не с модели, а с права на конкретную операцию. Если можно выдать только чтение, не выдавайте запись. Если нужен только расчёт, не открывайте изменение данных.

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

Чек-лист перед запуском

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