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

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

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

В OVHcloud мы запустили инициативу «AI Labs», которая отвечает за централизацию проектов и экспериментов с использованием инструментов LLM. Эта команда сейчас курирует более сотни проектов, и каждую неделю добавляются новые. Такой подход призван катализировать идеи и обеспечить основу для эффективного внедрения рабочих инструментов.

С точки зрения безопасности данных, распространение экспериментов и проектов по созданию прототипов (proof-of-concept, POC) создает множество дополнительных рисков, которые необходимо учитывать. Для понимания этих рисков необходимо моделировать взаимодействия между каждым компонентом, поскольку возможны многие конфигурации.

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

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

Разговорные агенты (без интеграции со сторонними сервисами)

Большинство профессионалов, работающих за компьютером, регулярно используют разговорных агентов для «улучшения» своей работы, часто даже не осознавая этого (например, при написании электронного письма, резюмировании документа, поиске сложной формулы Excel, ответе на юридический или технический вопрос и т.д.). Поскольку эти агенты не подключены к информационной системе компании, риски ограничены и зависят от отношения и практик пользователя, например, в отношении загрузки данных, копирования и вставки конфиденциальных данных в агента и т.п.

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

Примеры

• Публичные сервисы ИИ (Mistral, OpenAI, Grok, Omissimo и т.д.)
• Сервисы ИИ, заказанные компанией у издателей публичных сервисов или специализированных игроков
• Внутренний чат-бот

Связанные риски безопасности

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

Меры для внедрения

• Повышение осведомленности пользователей
• Хартия по использованию ИИ
• Блокировка сервисов, доступных из информационной системы компании
• Договор с поставщиками, включающий пункты о безопасности и конфиденциальности информации, передаваемой пользователями
• Инспекция трафика и идентификация конфиденциальных данных с использованием регулярных выражений
• Выделенный инстанс для компании, дообученный или обогащенный с помощью RAG данными компании (не очень чувствительными), что позволяет контекстуализировать LLM под контекст пользователя.

Приложение с «расширенным ИИ»

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

В этом случае использования издатель или менеджер приложения несет ответственность за безопасность данных и их обработку через LLM; пользователь не имеет контроля, а использование этих функций интегрировано в его обычное взаимодействие. Мы остаемся в рамках классического управления безопасностью: менеджер приложения (внутренний или внешний) является гарантом безопасности данных, которые он обрабатывает в приложении. Приложение обогащается новыми функциями, сложность возрастает, но модель безопасности сохраняется.

Примеры

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

Связанные риски безопасности

• Недостаточная сегментация прав доступа к данным в приложении, позволяющая обходить обычные средства контроля доступа. Это происходит, когда агент имеет учетную запись с высокими привилегиями (для упрощения и ускорения разработки функций) или когда ограничение доступа не реализовано на уровне данных.
• Инъекция промптов в приложение
• Зависимость от неконтролируемой цепочки поставок
• Утечка данных к субподрядчику

Меры для внедрения

• Пункты о безопасности в контрактах
• План обеспечения безопасности у поставщика приложения
• Анализ цепочек зависимостей от субподрядчиков
• Отключение ненужных функций ИИ
• Глубокая изоляция чувствительных приложений

Агентный ИИ

Теперь рассмотрим собственно «агентный ИИ» (Agentic AI). В этих случаях агент находится в центре рабочего процесса. Агент становится оркестратором ресурсов. У него несколько ролей, в частности:

• Улавливание ожиданий пользователя и запуск последовательности действий
• Получение необходимых данных для контекстуализации и обработки запроса
• Отправка данных и инструкций в LLM для определения последовательности действий, которые необходимо выполнить
• Управление итерациями с доступными сервисами и LLM для наилучшей обработки запроса
• Запуск действий в доступных сервисах
• Получение (в конечном итоге) подтверждения пользователя для валидации действий
• Предоставление пользователю видимости выполненных действий и полученных результатов

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

Агенты, интегрированные в локальные приложения

Приложения постепенно обогащаются возможностью подключения к сервису LLM. Обычно это делается через API к сервисам LLM или локально на машине. В этом случае приложение интегрирует агента и включает его использование в обычный пользовательский опыт. Контекст эквивалентен контексту обогащенного SaaS-приложения, но конфигурация и вызовы LLM осуществляются с рабочей станции пользователя. Функциональность может быть нативной или установленной в виде плагина.

Примеры

• ИИ-агент Microsoft Copilot
• Функции ИИ в офисных приложениях (OnlyOffice, Joplin, почтовый клиент и т.д.)
• Apple Intelligence

Связанные риски безопасности

• Потеря контроля над данными, обрабатываемыми при добавлении функций подключения к сторонним сервисам (будьте внимательны с конфигурациями инструментов по умолчанию)
• Риски аналогичны функциям «облачного» хранения в приложениях, позволяющим облачное хранение или общий доступ, часто настроенным по умолчанию
• Утечка секретов аутентификации LLM (Bearer Token)

Меры для реализации

• Информирование пользователей
• Контроль конфигурации приложений
• Валидация приложений на рабочих станциях и смартфонах
• Мониторинг и инспекция сетевых и прикладных потоков
• Локальное управление секретами

Универсальные или специализированные локальные агенты

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

• Настройка нескольких сервисов LLM параллельно
• Персонализация шаблонов системных и пользовательских промптов
• Интеграция локальных или удаленных сервисов MCP для обогащения данных, доступных агенту
• Функция контроля затрат
• Оптимизация запросов и управление контекстом

Эти агенты могут быть универсальными или специализированными. В частности, этот тип агентов широко используется разработчиками в их интегрированных средах разработки (IDE). В этом контексте управление безопасностью ложится на пользователя и локальную конфигурацию инструментов. Возможности могут быть расширены с помощью магазинов дополнений (marketplace), например, плагинов для добавления коннекторов к внешним сервисам или новых функций. Сложность конфигураций, отсутствие проверенных и надежных стандартов из-за относительной новизны этих инструментов порождает множество рисков для приложения, работающего непосредственно на рабочей станции пользователя со всеми его правами.

Примеры

• Универсальные агенты: Goose
• Специализированные агенты: Claude desktop, Cursor, Shai, Github Copilot, Continue, Kilo Code

Связанные риски безопасности

• Подключение к сторонним сервисам без контроля через маркетплейсы (MCP-коннекторы для сторонних сервисов)
• Неконтролируемый доступ к локальной файловой системе
• Передача конфиденциальных данных сторонним сервисам (бизнес-данные, секреты, .env файл и т.д.)
• Управление локальными секретами (Bearer token)
• Предоставление учетных данных сторонним сервисам (через мандат OAuth и т.п.)

Меры для реализации

• Информирование пользователей
• Контроль конфигурации приложений
• Тестирование и валидация ПО
• Изоляция (sandboxing) агентов
• Защита секретов (файлы окружения в директориях разработки)

Удаленные агенты

Удаленные агенты, как и локальные, — это приложения, которые связывают различные ресурсы (LLM, RAG, сторонние сервисы), упакованные в веб-приложение, доступное пользователю через браузер. Все сервисы чат-ботов постепенно интегрируют эти возможности, чтобы обогатить свой сервис за счет подключения к сторонним сервисам. Принцип работы схож с локальными агентами, но осуществляется вне рабочей станции пользователя.

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

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

Примеры

• ChatGPT, MistralAI
• Агенты, развернутые внутри компании

Связанные риски безопасности

• Утечка секретов аутентификации для чувствительных приложений или данных
• Централизация секретов для доступа к удаленным сервисам
• Открытие сетевых потоков между чувствительными приложениями и сервисами агента

Меры для реализации

• Архитектура, ограничивающая сетевое воздействие
• Сетевая инспекция
• Мониторинг приложений
• Управление авторизацией и контролем доступа
• Ограничение прав доступа до необходимого минимума для каждой задачи

Агенты рабочих процессов (Workflow agents)

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

• Ограничивать права доступа каждого агента только тем подмножеством данных, которое необходимо для выполнения его задач
• Более детерминированный подход для человеческого контроля над процессом
• Модульное тестирование каждой части
• Повторяемость процесса (воркфлои определяются «как код»)

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

Примеры

• N8N, Langchain, Zapier, Flowise AI

Связанные риски безопасности

• Рост сложности рабочих процессов и взаимосвязей
• Проблемы конфигурации
• Утечка токенов доступа
• Раскрытие конфиденциальных ресурсов
• «Теневые» платформы оркестрации, развернутые пользователями
• Доступ администраторов платформы к временным артефактам

Меры для реализации

• Архитектура, ограничивающая сетевое воздействие
• Сетевая инспекция
• Мониторинг приложений
• Управление авторизацией и контролем доступа
• Управление секретами
• Ограничение прав доступа до необходимого минимума для каждой задачи

Перспективы и проблемы для решения

MCP и управление секретами

Управление секретами лежит в основе проблемы развертывания ИИ на основе агентов. Поскольку LLM не являются детерминированными, необходимо ограничивать права доступа по объему и продолжительности для LLM, чтобы ограничить их доступ только теми данными и функциями, которые требуются для выполнения задач. Крайне важно определить надежные блоки, которые будут выступать в качестве посредников для предоставления доступа, особенно для MCP-серверов. Одна из задач — опираться на существующие матрицы прав доступа без повторной реализации дополнительного слоя управления правами для MCP-серверов и агентов, а вместо этого внедрять механизмы для динамического ограничения доступа по мере необходимости.

Существующие или emerging-стандарты (OAuth2, JWT, SAML, SPIFFE/SPIRE, OPA, Cedar и др.) частично решают некоторые из этих проблем, но ценой высокой сложности управления, без эталонной реализации, совместимой со всеми текущими решениями, и на быстроразвивающемся рынке.

Включение человека в процесс (Human in the loop)

Помимо управления секретами, LLM непредсказуемы, потому что они недетерминированы. Один из вопросов, который предстоит решить, — как включить человека в цепочку принятия решений агентского процесса, чтобы гарантировать, что это изначально непредсказуемое поведение не создает рисков для организаций. Сегодня этот контроль, известный как «human in the loop», основан на внутренних механизмах агента и ограничении секретов, которыми с ним делится пользователь. Очевидно, что такой режим работы несовместим с обработкой конфиденциальной информации.

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

На пути к закату веб-браузера как вектора доступа к информационной системе

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