В Казахстане проходит месяц кибербезопасности и киберкультуры, инициированный Министерством искусственного интеллекта и цифрового развития РК. В рамках этого проекта хотелось бы углубиться в вопрос того, есть ли риск утечки данных при работе с ИИ агентами и что нужно сделать, чтобы максимально от них защититься.
Об этом мы поговорили с руководителем направления мониторинга и управления киберинцидентами Freedom Cloud Holding Климом Гольцманом.
Один из способов — AI Firewall, защитный слой между пользователем, корпоративными системами и моделью, — объясняет эксперт.
Инженер загружает в AI-ассистент часть журнала событий, чтобы быстрее найти причину сбоя. Через несколько секунд он получает ответ и решает задачу. Но вместе с описанием ошибки во внешний сервис могли отправиться имя клиента, внутренние адреса серверов, учетная запись администратора и токен, случайно сохраненный приложением в логе.
Согласно исследованию OECD за 2025 год, генеративным ИИ пользовался 31% опрошенных малых и средних предприятий в семи странах. А в опросе Cisco Data Privacy Benchmark 2025, который охватил более 2600 специалистов из 12 регионов, почти половина организаций признала: их сотрудники вводили в генеративные системы персональные или непубличные данные.
Как ИИ меняет движение корпоративных данных
При работе с обычным чат-ботом пользователь сам выбирает текст и отправляет его модели. Такой канал относительно легко понять и контролировать. Однако AI-функции все чаще встраиваются в редакторы кода, браузеры, офисные приложения, системы поддержки и другие корпоративные продукты.
Пользователь может написать короткий вопрос, но приложение автоматически добавит к нему открытый документ, историю переписки, фрагмент кода или содержимое рабочей папки. В результате человек не всегда видит весь контекст, который получает модель.
Тайные ИИ-агенты
Еще сложнее контролировать ИИ-агентов. В отличие от чата, такой агент способен самостоятельно планировать действия и подключать инструменты. Он может открывать документы, читать почту, обращаться к API и базам данных, искать информацию в интернете и менять настройки.
Допустим, агент получил задачу: «Разберись с ошибкой клиента». Он может найти карточку заказчика, изучить конфигурацию и запросить журналы событий. Хотя для ответа были нужны только код ошибки и несколько строк лога, модель получила сведения сразу из нескольких систем.
По отдельности эти данные могут не выглядеть опасными. Но вместе они раскрывают внутренние процессы, состояние клиента и особенности продукта.
По оценке сообщества OWASP (Open Worldwide Application Security Project — открытый проект обеспечения безопасности веб-приложений – прим. ред.), возможный ущерб зависит от полномочий агента. Если он умеет только формировать текстовый ответ, последствия будут ограниченными. Если агент может читать корпоративные файлы, отправлять письма, изменять настройки и обращаться к внешним сервисам, риски значительно возрастают.
Поэтому компании должны контролировать не только запрос пользователя. Важно понимать, какие источники доступны агенту, какие данные он может объединять, какой модели разрешено их передавать и какие действия выполнять после получения ответа.
Почему запрет не решит проблему
Полная блокировка внешних AI-сервисов может быть оправдана в изолированных сегментах или при работе с особо чувствительной информацией. Но как универсальная стратегия она неэффективна.
ИИ уже встроен в разрешенные корпоративные продукты. Если компания не предоставляет удобный инструмент, сотрудники начинают пользоваться личными аккаунтами и неучтенными приложениями. В результате ИИ никуда не исчезает, а служба безопасности теряет видимость происходящего.
Обучение тоже не решает проблему полностью. Сотрудник может помнить правила, но не заметить токен в журнале на несколько тысяч строк или не знать, какой контекст редактор кода добавляет к запросу автоматически.
Классические DLP-системы способны находить паспортные данные, номера банковских карт, маркированные документы и известные шаблоны секретов. Однако им сложнее определить деловую цель запроса, допустимость использования конкретной модели и риск объединения нескольких фрагментов информации.
Локальная LLM также не гарантирует безопасности. Запросы могут сохраняться в логах, кэше, истории диалогов, резервных копиях, трассировке и векторных хранилищах. Кроме того, локальный агент может получить такие же избыточные права, как и облачный.
Как работает AI Firewall
AI Firewall пока не является единым отраслевым стандартом. На рынке используются термины AI gateway, LLM gateway, guardrails и model firewall. В общем виде это промежуточный уровень контроля между пользователем или агентом, корпоративными данными, AI-моделью и подключенными инструментами. Он необязательно представляет собой отдельный продукт. Такой слой может объединять AI-шлюз, DLP, классификацию данных, управление доступом и механизм проверки действий агента.
Схема выглядит следующим образом:
Сначала система определяет, кто отправил запрос, из какого приложения и проекта он поступил, для чего используется модель и разрешена ли она компанией. Затем проверяется содержимое.
Базовые механизмы ищут API-ключи, токены, пароли, персональные данные и метки конфиденциальности. DLP может сопоставить файл с корпоративным шаблоном или цифровым отпечатком. Более сложные правила учитывают должность сотрудника, клиента, источник документа и назначение операции.
Проверка не обязательно должна заканчиваться блокировкой. Иногда достаточно удалить токен, заменить имя клиента условным идентификатором, сократить фрагмент лога или перенаправить запрос в одобренную локальную среду. Пользователь по-прежнему решит задачу, но модель не получит лишние данные.
Проверять нужно не только запрос
Защитный слой должен работать в обе стороны. Модель способна повторить секрет из контекста, показать данные другого проекта или предложить опасную команду.
В случае с ИИ-агентом необходимо проверять каждое обращение к инструменту. Разрешено ли ему удалить файл? Может ли он изменить сетевое правило? Имеет ли право отправить письмо от имени пользователя? Допустимы ли конкретные параметры операции?
OWASP рекомендует разделять принятие решения и исполнение. Агент может предложить действие, но запускать его должен независимый механизм, который проверит права, уровень риска и необходимость согласования с человеком.
Контроль данных и контроль действий — разные задачи. Фильтр может найти персональную информацию и убрать ее из запроса. Но если агент собирается изменить конфигурацию сервера, анализа текста недостаточно. Нужна отдельная проверка полномочий.
С чего начать компании?
Первый шаг — провести инвентаризацию. Бизнесу необходимо понять, какие AI-сервисы уже используются сотрудниками, какие корпоративные приложения имеют встроенные AI-функции и какие сведения передаются моделям.
ИИ-агента следует рассматривать как отдельного программного участника системы. У него должны быть собственная идентичность, ограниченный набор источников и только необходимые для задачи инструменты. Доступы разных сотрудников, клиентов и проектов нельзя смешивать.
Следующий этап — классификация данных. Компания должна заранее определить, какую информацию разрешено передавать внешним моделям, какую можно отправлять только после маскирования, а какая должна обрабатываться исключительно внутри защищенного контура.
AI Firewall при этом не заменяет другие инструменты. Он не исправит избыточные права и не увидит запросы, проходящие в обход контролируемого шлюза. Любой классификатор также способен допустить ошибку. Поэтому защитный слой должен работать вместе с IAM, DLP, SIEM, системой классификации данных и контролем инструментов агента.
Одновременно сотрудникам нужен удобный и одобренный AI-инструмент. В противном случае рабочие задачи быстро переместятся в личные аккаунты и неконтролируемые сервисы. Безопасная архитектура должна не блокировать пользу от искусственного интеллекта, а сокращать объем передаваемых данных и ограничивать действия агентов необходимым минимумом.