Запретить нельзя разрешить: как ограничить свободу ИИ-агента

Лишь 7% респондентов, согласно исследованию Salt Security, оценивают риски управления ИИ-агентами хотя бы раз в месяц. Многие компании пока не воспринимают агентов как потенциальную причину утечки данных клиентов. Во многом из-за того, что в бизнесе более актуальной проблемой долгое время считается социальная инженерия. 

Сотруднику приходят правдоподобные сообщения: «Это директор, срочно вышли базу, иначе будут последствия». И под давлением он отправляет данные злоумышленникам. С ИИ-агентом может произойти то же самое. Его тоже можно уговорить, склонить к действию, запутать. Модель может принять пользовательский запрос за инструкцию разработчика и выполнить то, что ей фактически нельзя делать. 

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

Рассказывает Саша Данилов, CEO и основатель Nodul, российского аналога n8n.

Риски ИИ-агентов: утечки информации, форматирование данных

Главный источник уязвимостей ИИ-агентов сегодня — это архитектура доступа. Как только компания подключает агента к внутренним данным через протокол MCP (Model Context Protocol), она фактически отдает ему десятки рычагов управления: чтение и изменение записей, доступ к файлам, работу напрямую с базами данных. 

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

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

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

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


@Freepik (лицензия INV-C-2024-8250540)

Роль API-шлюзов

Шлюз полностью разрывает прямой доступ агента к MCP-серверу и backend-сервисам компаний. Агент больше не будет взаимодействовать с источником данных, например, с CRM напрямую, а вместо этого станет обращаться только к шлюзу. По сути, шлюз выполняет роль промежуточного уровня, который отвечает за маршрутизацию и изменение данных, контролируя доступ к ним. 

Шлюз работает по фиксированной логике: сам делает запрос к CRM или другому инструменту, получает данные и автоматически удаляет из них запрещенные поля, например, ФИО и номера телефонов.

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

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

Разница между MCP и шлюзами

В основе архитектуры стоит принципиальная разница в подходах к управлению доступом. MCP работает по принципу «разрешено все, что не запрещено». Агент получает практически полный набор рычагов, и, если конкретный запрет явно не прописан, система считает его допустимым. В итоге агент может вызвать любую внутреннюю функцию, даже если разработчики не планировали такой сценарий. Именно поэтому MCP создает высокий уровень риска.

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


@Freepik (лицензия INV-C-2024-8250540)

Почему писать шлюз с нуля — плохая идея

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

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

Поэтому код как основа для шлюза негибкий и наиболее дорогой подход. Любой новый сценарий может занять недели, тогда как в no-code-среде его можно добавить за считанные минуты.

---

Читайте также: Какие задачи E-commerce-бизнеса помогает решить разработка без кода, а какие — нет?

---

Внешний шлюз и внутренняя среда

Аналогом решения на коде являются оркестраторы ИИ-агентов, где от разработчиков требуется минимальное программирование или не требуется вовсе. Оркестраторы создают внешние шлюзы между сторонними ИИ-агентами (например, Eleven Labs) и корпоративными данными. 

Eleven Labs и другие голосовые платформы используют MCP-протокол без какой-либо фильтрации, поэтому прямое подключение агента к корпоративным данным представляет высокий риск. Оркестраторы встраиваются внутрь готового продукта между агентом и источниками данных, беря на себя всю логику проверки, ограничения и фильтрации запросов.

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

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

1. MCP — удобно, но не безопасно. Обязательно добавляйте в архитектуру ИИ-агента API-шлюз, который работает по принципу «запрещено все, что не разрешено». Он блокирует опасные операции, ограничивает объем выдачи, настраивает многоуровневые модели доступа, учитывает контекст запроса при проверке.

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

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

Саша Данилов, 
CEO и основатель Nodul, российского аналога n8n.

Для NEW RETAIL