ИИ-ассистенты как новый вектор риска: вызовы для корпоративной безопасности в эпоху генеративных технологий

Актуальность проблемы

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

Сервисы нейрошлюзов вроде ChatGPT, DeepSeek, Preplexity, Claude и других стали частью повседневной работы сотрудников, обеспечивая мгновенный доступ к аналитике, текстовой генерации, программированию, автоматизации документооборота, к оптимизации клиентских коммуникаций и даже консультированию. Интеграция LLM‑инструментов в корпоративные процессы воспринимается как очередной виток автоматизации, способный повысить эффективность и снять часть нагрузки с специалистов. Однако стремительный рост популярности таких ассистентов выявил и обратную сторону технологического прогресса. Генеративные модели, будучи внешними облачными сервисами, представляют собой новый неконтролируемый канал взаимодействия между корпоративной инфраструктурой и внешней средой.

Если раньше внимание специалистов по ИБ было сосредоточено на защите почтовых систем, мессенджеров, файловых хранилищ, то сегодня все чаще в зоне риска оказываются обращения сотрудников к публичным нейросервисам, происходящие за пределами корпоративных периметра и зачастую без ведома администраторов безопасности. Разбираемся вместе с Алиной Алакиной‑Каминской, бизнес‑архитектором Solar webProxy ГК «Солар», как ИИ‑ассистенты становятся новым вектором киберрисков.

Трансформация модели рисков

Новая реальность в корне меняет парадигму управления киберрисками. Помимо угроз, формируемых извне, в периметре организаций появляются и новые внутренние риски, в виде неосознанного использования инструментов, чья бизнес‑логика по умолчанию не предполагает контроль над данными. Любая отправка текста, документа или кода в LLM‑сервис становится потенциальным инцидентом — неизвестно, где и как эти данные будут обработаны, сохранены и в какой форме могут быть возвращены в ответы другим пользователям.

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

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

Современным средствам ИБ приходится адаптироваться:

• от классического периметрального контроля — к нулевому доверию и интеллектуальному анализу контента трафика

• от статических списков доменов — к гибким политикам категоризации и выявлению признаков утечек на уровне смыслов

• дополнять защиту от вредоносного кода мониторингом аномальных сценариев поведения пользователей и ИИ‑сервисов

Плоскости современных угроз

Внутренние контур риска корпоративного использования ИИ-ассистентов: неосознанная передача корпоративных данных

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

Такие действия могут привести к:

• утечке интеллектуальной собственности или исходных кодов через открытые API

• раскрытию персональных данных клиентов и сотрудников третьим лицам

• попаданию коммерческой информации в обучающие выборки внешних моделей

• нарушению комплаенс‑требований (152-ФЗ, ISO 27001, GDPR (в контексте Global Use) и др.)

Фактически, без централизованного контроля над веб‑трафиком обращения к LLM становятся альтернативным каналом утечки данных и новым типом теневых ИТ‑активностей (shadow IT), которые невозможно отследить стандартными DLP‑ или антивирусными решениями.

Внешний контур риска: использование ИИ злоумышленниками

Вторая сторона проблемы — это эволюция угроз при использовании тех же технологий против компаний. Современные LLM‑инструменты позволяют злоумышленникам быстро и правдоподобно генерировать вредоносные сценарии:

• фишинговые письма и сайты, визуально неотличимые от оригиналов

• вредоносные скрипты и инъекции, написанные в «один клик»

• динамические ловушки, где сгенерированные код подменяется в ответах на пользовательские запросы

• LLM‑инъекции (prompt injection), позволяющие обходить фильтры и выполнять нежелательные команды в чат‑интерфейсах компании

В совокупности это формирует новую категорию угроз — ИИ‑генерируемые атаки, отличающиеся высокой скоростью, автоматизацией и достоверностью подделок. Они подрывают доверие пользователей и усложняют задачи обнаружения, поскольку вредоносный контент маскируется под безобидные ответы ассистентов.

Новая зона ответственности ИБ-инфраструктуры

В условиях стремительной интеграции LLM‑инструментов в бизнес‑процессы контроль обращений к ИИ‑сервисам становится новой задачей для средств безопасности. Сегодня критически важно не просто ограничивать доступ к определенным ресурсам, а понимать контекст и содержимое взаимодействия — что именно передается, в каком виде, и что возвращается в ответ.

ИБ‑инфраструктура должна уметь:

• распознавать обращения к LLM‑платформам, включая скрытые поддомены и API‑интерфейсы

• анализировать исходящие запросы на наличие признаков конфиденциальной информации

• проверять входящие ответы на предмет внедренного кода, вредоносных скриптов или подозрительных ссылок

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

Именно в этом контексте продукты класса Secure Web Gateway, такие как Solar webProxy, выходят на новый уровень значимости. Сегодня они перестают быть просто инструментом категоризации и фильтрации трафика, фокусирующимся на сетевых адресах и репутации доменов. Современные SWG‑решения становятся полноценным элементом стратегии защиты данных, способным контролировать не только направление запроса, но и содержимое взаимодействия, включая файлы, текстовые фрагменты и семантические паттерны обращений.

Функциональность подобных решений эволюционирует в сторону «умного периметра» — промежуточного уровня между классическим шлюзом и DLP‑системой. SWG берет на себя функции первичной контент‑инспекции и выявления рисков утечки на ранней стадии: анализирует смысловую составляющую передаваемых данных, определяет наличие потенциально конфиденциальной информации, блокирует подозрительные загрузки и автоматизировано реагирует на аномальные сценарии взаимодействия с внешними сервисами.

Роль Solar webProxy

В экосистеме “Солара” именно Solar webProxy выступает ключевым элементом, способным обеспечить безопасность бизнеса в новых реалиях развития ИИ-ассистентов. Он становится неким “интеллектуальным шлюзом доверия”, который обеспечивает прозрачность и управляемость обращений к внешним нейроплатформам, сохраняя баланс между свободой использования инноваций и контролем безопасности.

На уровне политик веб‑трафика продукт позволяет:

• создавать точечные правила контроля и категоризации трафика к ИИ‑сервисам

• реализовывать анализ содержимого запросов и ответов (определение по типам файлов и инспекция передаваемого контента; дополнительно возможна проверка в решениях класса DLP‑, AV‑, Sandbox)

• предотвращать загрузку и выгрузку конфиденциальных данных

• блокировать подозрительные сценарии взаимодействия с внешними LLM‑платформами.

Кейсы нежелательного использования ИИ

Внутренний контур риска: предотвращение неосознанной передачи корпоративных данных в ИИ-сервисы (фильтрация запросов)

Кейс 1. “Отчет для проверки”

Угроза: Сотрудник загружает в DeepSeek, ChatGPT или Preplexity внутренний аналитический отчет, чтобы получить “упрощенную версию” для презентации или перевода. В документе содержатся конфиденциальные финансовые показатели, имена контрагентов и внутренние KPI.

Задача: предотвратить передачу во внешние нейросервисы документов, содержащих признаки финансовых или клиентских данных.

Действие:

Solar webProxy выполняет контент‑инспекцию исходящего запроса, проверяя при этом принадлежность домена к запрещенным ресурсам ИИ‑ассистентов и анализируя:

• расширение и MIME‑тип файла (например, docx, xlsx и др.)

• наличие паттернов финансовых метрик по заранее сформированным спискам ключевых слов (например, KPI, contract_no и др.)

• числовые последовательности, характерные для клиентских данных (например, ИНН, счета и др.)

При совпадении с эталонным шаблонов метаданных или DLP‑паттернов запрос блокируется с уведомлением пользователя (шаблоны блокировки).

Кейс 2. “Помощь с кодом”

Угроза: Разработчик копирует в нейросервис (категория ИИ-ассистенты) фрагмент внутреннего исходного кода с комментариями и названиями модулей, чтобы получить помощь в оптимизации. Код содержит бизнес-логику продукта и уникальные идентификаторы систем.

Задача: защитить исходный код и внутренние алгоритмы от утечки через публичные API‑интерфейсы.

Действие:

Solar webProxy проводит семантический анализ текстового содержимого запроса, проверяя при этом принадлежность домена к запрещенным ресурсам ИИ‑ассистентов:

• обнаружение фрагментов кода по синтаксису, служебным конструкциям и др.

• обнаружение внутренних namespace, имен функций, URL внутренних API

При подтверждении условий правила «Исходный код» запрос блокируется с уведомлением пользователя (шаблоны блокировки).

Кейс 3. “Проверка клиентского письма”

Угроза: Менеджер отдела продаж просит нейросеть (в DeepSeek, ChatGPT или Preplexity — категория ИИ‑ассистенты) переписать письмо клиенту «более вежливо», вставляя в запрос имя клиента, номер договора и условия сделки.

Задача: исключить передачу персональных и коммерческих данных клиентов в публичные ИИ‑ассистенты.

Действие:

Solar webProxy выполняет лексико‑семантический анализ тела запроса, проверяя при этом принадлежность домена к запрещенным ресурсам ИИ‑ассистентов:

• поиск маркеров персональных данных (например, имена, номера телефонов и др.)

• обнаружение шаблонов коммерческих условий (например, контракт, NDA и др.)

• распознавание расширения вложений и проверка MIME‑типов

При выявлении — запрос блокируется с уведомлением пользователя (шаблоны блокировки).

Кейс 4. “Обработка внутренних коммуникации”

Угроза: HR‑специалист копирует в ИИ‑ассистент фрагмент переписки из корпоративного мессенджера, чтобы получить совет по управлению конфликтной ситуацией. В тексте присутствуют персональные данные сотрудников и упоминания внутренних ролей.

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

Действие:

Solar webProxy анализирует текстовые поля запроса, проверяя при этом принадлежность домена к запрещенным ресурсам ИИ‑ассистентов, на наличие:

• обращений к персоналиям, email‑доменов корпоративного формата

• упоминаний внутренних подразделений или ролей

• контекстных связок, характерных для описания конфликтных ситуаций (например, жалоба, увольнение)

При совпадении с корпоративными словарями — запрос блокируется с уведомлением пользователя (шаблоны блокировки).

Кейс 5. “Интеллектуальный помощник для тендера”

Угроза: Сотрудник загружает в Preplexity или Claude тендерную документацию для автоматического извлечения ключевых требований и подготовки КП (коммерческого предложения). Документ содержит цены, сроки, технические условия и сведения о поставщиках.

Задача: защитить коммерческие тендерные данные от несанкционированной обработки внешними сервисами.

Действие:

Solar webProxy проверяет принадлежность домена к запрещенным ресурсам ИИ‑ассистентов и:

• распознает расширение вложения и MIME‑тип файла

• распознает ключевые слова вложения, характерные для обозначенной тематики кейса (например, «тендер», «технические требования» и др.)

• анализирует контекст текста на наличие коммерческих числовых диапазонов и терминов по заранее созданному списку

При совпадении с справочником «Тендерные документы» — запрос блокируется с уведомлением пользователя (шаблоны блокировки).

Кейс 6. “Сценарий интеграции с API ChatGPT”

Контекст: В отделе маркетинга или разработки создается внутренний скрипт для обращения к ChatGPT API через https://api.openai.com/v1/chat/completions

Цель — автоматическая генерация текстов для публикаций или отзывов.

Разработчик для удобства вставляет в код реальный API‑ключ и параметры, взятые из внутренней конфигурации. Запрос идет напрямую через прокси — таким образом, Solar webProxy может перехватывать и анализировать его содержимое.

Угроза: Передача во внешний сервис:

• токенов и ключей доступа к корпоративным системам

• внутренних URL‑адресов стендов (например, «dev‑», «test‑» и др.)

• идентификаторов, описывающих внутренние объекты инфраструктуры

• фрагментов конфигураций и credentials (логины, пароли и др.)

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

Действие:

Solar webProxy способен:

• определить, что запрос направлен к внешнему ИИ‑сервису (категория ИИ‑ассистенты или домены назначения (списки ресурсов, в том числе через regex для URL и URL‑паттернов)

• проверять HTTP‑заголовки на предмет наличия ключей и токенов

• проводить инспекцию тела запроса на наличие параметров JSON (по заранее сформированному списку)

  • для повышения точности можно использовать регулярные выражения в поиске ключевых слов в теле запроса

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

Дополнительно Solar webProxy может проверить:

• POST запросов с Content‑Type

• объем тела запроса

• Источник запроса на предмет вхождения в списки тех, кому запрещено/разрешено использовать API нейросервисов в целях R&D

При совпадении с справочником «Тендерные документы» — запрос блокируется с уведомлением пользователя (шаблоны блокировки).

Внешний контур риска: фильтрация ответов и защита от ИИ-генерируемых угроз

Кейс 1. “Фишинговые вложения, возвращаемые LLM (Office с макросами)”

Контекст:

Внешний LLM/интегратор возвращает пользователю ответ, в котором есть вложение (или ссылка на вложение) с офисным документом (.docx/.docm/.xlsm/.xlsx). Пользователь скачивает и открывает – в документе есть макросы.

Угроза: Загрузка зараженного документа (VBA-макросы) → компрометация рабочего места.

Задача: Отлов и блокировка потенциально опасных офисных вложений в ответах LLM до выдачи пользователю.

Действие:

Solar webProxy после соответствующей настройки правил в слое фильтрации ответов:

• проверит назначение (домен/категория) запросов на предмет вхождение в список ИИ‑сервисов/категорию ИИ‑ассистенты

• проверит файлы через тип идентификации / точное совпадение имени / имя через регулярное выражение / хэш (при наличии IOC списка)

• проверит размер файлов: например, офисные файлы > 10 KB

• проверит критичные для кейса типы файлов

• проверит ответы на наличие ключевых слов (например, «AutoOpen», «cmd.exe», «enable macros» и др.)

• среагирует на событие посредством исполнения действий:

  • блокировки

  • уведомления

  • установки маркера события

Кейс 2. “Встраиваемы двоичные/скриптовые объекты: ответ содержит вложение/файл с исполнителем (exe/ps1/js)”

Контекст:

Интеграция LLM возвращает ответ, который приходит в браузер/клиента как “файл для скачивания (через Content-Disposition: attachment; filename=…) или как бинарный ответ (Content-Type: application/octet-stream / application/x-msdownload / и др.). Известны метаданные ответа: заголовки, имя файла, размер и хеш.

Угроза: Скачивание или сохранение исполняемых файлов (.exe, ps1, .bat, .js и т.п.) приводит к запуску вредоносного кода на рабочей станции.

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

Действие:

Solar webProxy после соответствующей настройки правил в слое фильтрации ответов:

• проверит назначение (домен/категория) запросов на предмет вхождение в список ИИ‑сервисов/категорию ИИ‑ассистенты

• проверит файлы через тип идентификации / точное совпадение имени / имя через регулярное выражение / хэш (при наличии IOC списка)

• проверит размер файлов (от): любое приложение/исполняемый файл > 1 KB следует проверять

• проверит критичные для кейса типы файлов (например, application/octet‑stream / application/x‑msdownload и др.)

• проверит ответы на наличие ключевых слов (например, «powershell», «invoke‑expression», «msiexec» и др.)

• среагирует на событие посредством исполнения действий:

  • блокировки

  • уведомления

  • установки маркера события

Кейс 3. “Инлайновый исполняемый контент: ответ возвращает файл типа script/js (MIME) или Content-Disposition с .js/.vbs”

Контекст:

Ответ LLM приходит с Content-Type: application/javascript или как вложение с именем .js / .vbs / *.hta. Это может быть benign (пример: пример кода), но также – попытка доставки вредоносного скрипта.

Угроза: Автоматическое встраивание/исполнение скрипта в клиенте (встраиваемый виджет, расширение) приведет к выполнению вредоносного JS/HTA/WSH.

Задача: блокировать ответы с MIME-типом, указывающим на скриптовый исполняемый контент.

Действие:

Solar webProxy после соответствующей настройки правил в слое фильтрации ответов:

• проверит назначение (домен/категория) запросов на предмет вхождение в список ИИ‑сервисов/категорию ИИ‑ассистенты

• провери файлы через тип идентификации / точное совпадение имени / имя через регулярное выражение / хэш (при наличии IOC списка)

• проверит размер файлов (например, от 10 KB для снижения FP)

• проверит критичные для кейса типы файлов (например, application/javascript, application/x‑javascript и др.)

• проверять ответы на наличие ключевых слов (например, “ document.write«, „innerHTML“ и др.)»

• среагирует на событие посредством исполнения действий:

  • блокировки

  • уведомления

  • установки маркера события

• также можно создать правило исключение в слое для разрешенных персон/групп (например, ИТ или ИБ).

Кейс 4. “Клонирование / фишинговые AI-страницы, запрашивающие токены/ключи”

Контекст:

Пользователь переходит на страницу, визуально похожую на официальный интерфейс LLM, где форма просит «вставить API‑ключ» или «Enter your API key». Прокси видит URL (Host) и тело страницы HTML, но не имеет возможности выполнять сложную семантику — может сверять домен и ключевые слова.

Угроза: Пользователь вводит секреты/токены — утечка учетных данных.

Задача: блокировать загрузку страницы, если Host не совпадает с allowlist официальных доменов, а в теле страницы есть брендовые упоминания и поля для ввода ключей.

Действие:

Solar webProxy после соответствующей настройки правил в слое фильтрации ответов:

• проверит назначение

  • при этом должно работать правило исключение на известные LLM домены и ИИ‑ассистенты.

• проверит критичные для кейса типы файлов: text/html

• проверит ответы на наличие ключевых слов (например, справочник с наименованием брендов, текстовыми призывами на ввод, полями для ввода паролей/логинов/API‑ключей, параметрами явных атрибутов HTML‑форм — задавать в виде регулярных выражений)

• среагирует на событие посредством исполнения действий:

  • блокировки

  • уведомления

  • установки маркера события

• также можно создать правило исключение в слое для разрешенных персон/групп (например, ИТ или ИБ).

Кейс 5. “Внешний ответ содержит внутренние адреса, токены, конфигурационные имена (показ служебной информации)”

Контекст:

LLM или сторонняя платформа в ответах отображает внутренние endpoint’ы (dev., staging., intra., localhost, 10.x.x.x) или токеноподобные строки (ключи), что свидетельствует о потенциальной утечке/перемешивании служебных данных.

Угроза: Раскрытие внутренних адресов и токенов снижает барьер для сканирования, SSRF/SSIS атак и дальнейшей компрометации.

Задача: блокировать ответы, содержащие внутренние домены, IP‑адреса из приватных диапазонов и/или токеноподобные строки.

Действие:

Solar webProxy после соответствующей настройки правил в слое фильтрации ответов:

• проверит назначение (домен/категория) запросов на предмет вхождение в список ИИ‑сервисов/категорию ИИ‑ассистенты

• проверит критичные для кейса файлы через тип идентификации / имя / имя регулярное выражение (например, (?i).*config.*.json$ или (?i).*credentials.*.(json|txt)$ и др.)

• проверит размер файлов, если есть вложение с вышеуказанными наименованиями файлов

• проверит критичные для кейса типы файлов (например, text/html, text/plain, application/json)

• проверит содержимое ответов по заранее сформированному справочнику ключевых слов с использованием RegEx, например: 

  • внутренние домены/поддомены

  • приватные IP-адреса

  • токеноподобные строки

• среагирует на событие посредством исполнения действий:

  • блокировки

  • уведомления

  • установки маркера события

Заключение

Современные нейросетевые сервисы, ИИ-ассистенты становятся не только мощным инструментом повышения эффективности бизнеса, но и новым классом источников киберрисков. В этой среде Solar webProxy занимает принципиально иное место по сравнению с классическими шлюзами фильтрации: он эволюционировал в инструмент, обеспечивающий сквозной контроль информационного трафика на обоих векторах взаимодействия – исходящем и входящем.

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

Со стороны внешних угроз Solar webProxy обеспечивает интеллектуальную фильтрацию ответов от сервисов ИИ, предотвращая загрузку вредоносных объектов, скрытых скриптов и фишинговых страниц. За счёт анализа MIME-типов, имён и размеров файлов, ключевых слов и контентных признаков продукт выявляет попытки внедрения вредоносных инструкций, фишинговых редиректов и маскировки под легитимные интерфейсы нейросервисов. Таким образом, Solar webProxy формирует «умный периметр доверия», где каждая транзакция с внешними LLM-платформами проходит контентную и поведенческую валидацию без необходимости внедрения отдельных систем DLP или антифишинг-движков.

Ключевое преимущество решения — гибкость архитектуры политик. Администратор может задать granular‑условия проверки (по домену, категории, типу файла, хэшу, размеру, ключевым словам, расписанию и лимитам трафика), что позволяет не только блокировать трафик по сигнатурам, а выстраивать контекстно‑зависимые сценарии защиты, адаптированные под особенности конкретной организации. В результате Solar webProxy превращается в инструмент динамического управления цифровыми рисками, где каждый элемент фильтрации — осознанный и измеримый параметр политики, а не статическая заглушка. На практике это означает, что организация получает единый контролирующий слой, который:

• предотвращает внутренние утечки через ИИ‑ассистентов,

• блокирует вредоносные и фишинговые ответы от внешних сервисов,

• сохраняет баланс между безопасностью и доступом к инновационным инструментам.

Solar webProxy — веб‑шлюз, который уже сегодня способен сочетать функции SWG и DLP в рамках одного продукта, благодаря интеллектуальной контентной фильтрации нового поколения. В условиях, когда границы между рабочими и облачными инструментами становятся все менее понятными, именно такой подход становится основой стратегической киберустойчивости бизнеса.