Zero Trust и LLM в корпорации, что это и зачем надо

Дорогой мои Хабр! В 2026‑м почти в каждой крупной компании появился свой ИИ: чат‑бот для сотрудников, ассистент в CRM, помощник в DevOps, «умный поиск» по документации. На слайдах это выглядело как «повышаем эффективность и разгружаем людей». На практике быстро выяснилось, что один такой сервис иногда видит больше, чем любой живой сотрудник: обращения в поддержку, инциденты ИБ, договоры, переписку с ключевыми клиентами — всё это летит через один API.

Проблема в том, что защищаем мы эти штуки по старой памяти — как обычный внутренний сервис «за VPN‑ом». Логика такая: раз доступ только из корпоративной сети, значит, всё ок. Но LLM может крутиться в облаке, ходить в сторонние сервисы, дергать внутренние API и послушно выполнять любые запросы, если их правильно сформулировать. Отсюда вылезают знакомые уже истории: prompt‑injection, утечки через промпты и ответы, «внезапно» найденные в логах следы несанкционированных выгрузок.

На этом фоне Zero Trust перестаёт быть красивой теорией для CISO‑митапов. Если продолжать относиться к модели как к «чёрному ящику, который что‑то там отвечает», мы по сути открываем новый периметр атак — и для внешних злоумышленников, и для своих же людей с лишними правами. Модели и AI‑агенты становятся отдельными участниками инфраструктуры: у них есть доступы, они инициируют действия, они могут накосячить. Значит, им нужны свои роли, ограничения и прозрачный аудит.

В этой статье я разберу, как смотреть на LLM через призму Zero Trust: какие у такой системы реальные угрозы, как может выглядеть референс‑архитектура «доверенной» среды и с чего начать внедрение в живой компании. Цель простая: превратить AI‑сервисы из непонятной магии с доступом «ко всему сразу» в нормальных, управляемых жителей корпоративной ИТ‑архитектуры.
 

Почему старый подход к безопасности ломается на LLM

Долго работала простая модель: есть периметр (VPN, корпоративная сеть, пара железных фаерволов), внутри — «своё» и относительно безопасное. Если сервис стоит во внутреннем сегменте и туда не пускают снаружи, значит, жить можно. Для классовых веб‑приложений и пары интеграций это ещё как‑то работало.

С LLM всё иначе. Модель постоянно ест внешний ввод, часто ходит в интернет, дергает внутренние API и базы, а иногда ещё и сама инициирует действия через агента. При этом на уровне сети это всё тот же «обычный» сервис: порт, протокол, TLS — ничего подозрительного. Вся магия (и все проблемы) живут внутри полезной нагрузки — в промптах и ответах.

Что идёт не так в классическом подходе:

·         Периметр не защищает от prompt‑injection. Атака проходит не через уязвимость в коде, а через хитро сформулированный текст, который меняет поведение модели. Для фаервола это просто очередной POST с JSON‑ом.

·         Внутренний пользователь с доступом к LLM часто видит больше, чем должен. Если модель без ограничений ходит в DWH, CRM и файловые хранилища, один удачный запрос может вернуть огромный кусок чувствительных данных.

·         Логика «доверяем внутренней сети» не работает, когда сам LLM крутится в внешнем облаке или в отдельном кластере, управляемом другой командой. Граница между «внутри» и «снаружи» становится размытой.

·         AI‑агенты расширяют атаку: если модель умеет запускать джобы, ходить в GitLab, Jira, Kubernetes или ERP через инструменты, то любая манипуляция её выводом превращается в потенциальную цепочку действий в боевой инфраструктуре.

Отдельная проблема — прозрачность. Обычный микросервис можно продебажить: посмотреть логи, понять, какая ветка кода сработала и почему. С LLM это «чёрный ящик»: есть промпт, есть ответ, а что там произошло внутри — никто не знает. Для безопасности это кошмар: сложно объяснить, почему модель отдала лишние данные, кто их запросил в действительности и кто за это отвечает.

В итоге классическая картинка «файрвол по границе, IDS/IPS на периметре, внутри всё своё» превращается в иллюзию. Настоящий периметр смещается внутрь: вокруг самих AI‑сервисов, вокруг данных, которые они видят, и вокруг действий, которые они могут совершать. И это как раз та точка, где без принципов Zero Trust уже не обойтись.

Что такое Zero Trust, если у вас есть LLM

Если совсем коротко, Zero Trust — это про недоверие по умолчанию. Мы больше не делим мир на «хорошую внутреннюю сеть» и «злую внешнюю», а считаем, что любая сущность (пользователь, сервис, устройство, теперь ещё и модель) потенциально может накосячить или быть взломана. Значит, каждый запрос нужно проверять, каждое действие — ограничивать и логировать.

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

Чтобы этого не случилось, LLM и AI‑агентов нужно воспринимать как отдельных участников системы — примерно как нового сотрудника:

·         у него должна быть своя идентичность (клиент в IAM, сервисный аккаунт, роль);

·         ему нужно выдать только те права, которые реально нужны в конкретном сценарии;

·         его действия нужно писать в логи и периодически пересматривать: всё ли ещё ок с уровнем доступа.

Из этого вырастают три практических принципа Zero Trust для LLM:

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

2.      Минимально необходимые права. Модель для поддержки не должна видеть всю CRM. Агент, который перезапускает сервисы, не должен уметь править конфигурации в проде. Лучше завести несколько разных ролей/профилей под разные сценарии, чем один «супер‑ИИ на все случаи».

3.      Сплошной аудит. Каждый промпт и ответ — это по сути транзакция. Важно понимать, кто, когда и что запросил, к каким данным модель залезла и какие действия в итоге были выполнены. Без этого расследовать инциденты и докручивать политику безопасности почти нереально.

Дальше на этих принципах можно уже строить модель угроз и референс‑архитектуру: где именно проверять права, где резать данные, где подключать DLP и SIEM, как ограничивать инструменты агентов и т.д.

Какие угрозы появляются с LLM в корпорации

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

1. Утечки данных через промпты и ответы

LLM любит «подглядывать» в контекст: базы знаний, документы, тикеты, переписку. Если не ограничивать, она легко:

·         вернёт в ответе фрагменты внутренних документов;

·         «соберёт» по запросу список клиентов, сотрудников, сумм, логинов;

·         сформирует резюме по инцидентам или договорам, которые человек видеть не должен.

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

2. Prompt‑injection и управление поведением модели

Модель не различает «хорошие» и «плохие» инструкции, если их грамотно замаскировать под запрос. Через prompt‑injection можно:

·         заставить её игнорировать системные ограничения («забудь все предыдущие инструкции и...»);

·         вытащить конфиденциальные данные, к которым она имеет доступ;

·         убедить агента вызвать нежелательный инструмент (например, выполнить команду в CI/CD или запрос к prod‑базе).

Это не баг в коде — это новая плоскость атак на уровне логики.

3. Избыточные права у моделей и агентов

Частая история: «чтобы не возиться, дадим ИИ доступ ко всему, потом разберёмся». В итоге:

·         один сервисный аккаунт от LLM видит несколько систем сразу (CRM, ERP, DWH, файловые хранилища);

·         у агента есть права, которых нет даже у обычного пользователя (например, на массовые операции в проде);

·         разграничения по проектам, странам, юрлицам и т.п. просто не отражены в правах модели.

Любая ошибка в промпте или атака на модель в таком случае бьёт сразу по всей инфраструктуре.

4. Атаки через инструменты и интеграции агентов

Если поверх модели построен агент с инструментами, поверхность атаки расширяется:

·         через скомпрометированный prompt можно заставить агента запускать скрипты, джобы, пайплайны;

·         можно инициировать нетипичные действия в сторонних сервисах (GitLab, Jira, Kubernetes, ERP, биллинг);

·         можно использовать агента как прокси для обхода обычных ограничений API (например, перегрузить систему массовыми запросами).

По сути, каждый инструмент агента — это ещё одна дверь в вашу инфраструктуру.

5. Shadow AI и «дикий запад» из SaaS‑сервисов

Пока корпоративная платформа только рождается, сотрудники уже тащат внутрь:

·         сторонние SaaS‑ассистенты;

·         браузерные плагины с ИИ;

·         «удобные» онлайн‑сервисы, куда они скармливают реальные рабочие данные.

Эти штуки не видны ни ИБ, ни ИТ, у них нет нормальных договоров и политик, а данные уже утекают наружу.

6. Непрозрачность и сложности с аудитом

Даже если вы что‑то логируете, без системы получается:

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

·         невозможно быстро ответить на вопросы «что видел этот сотрудник» или «что делал этот агент за последний месяц»;

·         сложно доказать регулятору, что доступ к чувствительным данным был под контролем.

Из‑за этого любая проблема превращается в «чёрную дыру»: все чувствуют, что что‑то не так, но объяснить и исправить быстро не получается.

Референс‑архитектура доверенной среды для LLM

Представьте схему: слева пользователи и сервисы, справа — данные и бизнес‑системы, посередине — слой AI‑платформы. Ниже по блокам, что там должно быть.

1. AI‑шлюз (входная точка для всех LLM)

Это «единый фронт‑дверь» для любых обращений к моделям:

·         Аутентификация и авторизация: кто стучится — человек, сервис, агент, какой сценарий, через какое приложение.

·         Привязка к ролям и атрибутам: на этом уровне уже понятно, каких данных и действий можно ожидать (подразделение, проект, тип пользователя).

·         Базовые фильтры: ограничение размеров запросов/ответов, простейшая защита от очевидного мусора и попыток обойти политики.

Идея простая: ни один запрос к модели не проходит мимо этого слоя.

2. Слой политик и фильтров (policy engine + DLP)

Следующий слой отвечает за то, «что можно, а что нет»:

·         Политики доступа: по роли и сценарию решаем, какие типы данных можно отдавать в модель и из модели.

·         DLP‑контроль: вычищаем или маскируем ПДн, номера документов, финансовые атрибуты и прочую чувствительную информацию из промптов и ответов.

·         Специальные правила для «опасных» команд: генерация SQL, shell‑команд, конфигов и т.п. — отдельно контролируем и валидируем.

Этот блок не даёт модели «увидеть лишнее» и снизит ущерб, даже если промпт окажется вредоносным.

3. Контур данных и RAG‑слой

Здесь живёт всё, к чему модель обращается «по делу»:

·         Отдельные хранилища/индексы по зонам безопасности (публичные, внутренние, конфиденциальные и т.д.).

·         RAG‑слой, который ходит в эти хранилища от имени конкретного пользователя/сценария, а не «от имени сверхразумного ИИ».

·         Шифрование, токенизация, спец‑обработка особо чувствительных полей.

Ключевая мысль: LLM никогда не ходит «напрямую в прод‑базу». Она стучится в RAG/сервис, а тот уже решает, что ей можно показать.

4. Контур идентичностей (IAM для людей, сервисов и агентов)

Тут мы приравниваем модели к полноценным участникам инфраструктуры:

·         У каждого типа ассистента и агента свой сервисный аккаунт/клиент в IAM.

·         Роли и права описаны так же, как для обычных сервисов: какие системы, какие операции, в каких контекстах.

·         Связка «пользователь → приложение → сценарий → агент» фиксируется и используется при принятии решений в шлюзе и RAG‑слое.

Это позволяет не бояться фразы «агент сам сходил в ERP» — понятно, под каким аккаунтом, с какими правами и что он там делал.

5. Слой инструментов и интеграций агентов

Чтобы агенты не превратились в «root‑скрипт на стероидах», нужен отдельный слой:

·         Обёртки над инструментами (API‑адаптеры) с чётким контрактом: что можно вызывать, с какими параметрами, в каком объёме.

·         Ограничения по операциям: чтение/запись, лимиты по количеству, запрет на массовые и разрушительные действия.

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

По факту это превращает каждого «инструмент агента» в нормальный, управляемый микросервис.

6. Логи, мониторинг, SOC/SIEM

И наконец, «глаза и уши» всей конструкции:

·         Централизованные логи со всех уровней: шлюз, политики, RAG, инструменты, сами модели.

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

·         Интеграция с SOC/SIEM: алерты по аномалиям (нестандартные запросы, массовые выгрузки, странное поведение агента).

Без этого Zero Trust остаётся на бумаге — здесь он превращается в работающий цикл: увидели, поняли, подкрутили политику.

Как это внедрять по шагам в живой компании

Тут важно не пытаться «сразу построить идеальную платформу», а аккуратно навести порядок вокруг уже существующих ИИ‑инициатив.

Шаг 1. Инвентаризация: понять, что у вас уже есть

Сначала собираем поле боя:

·         Список всех LLM‑сервисов и пилотов: внутренние боты, ассистенты в продуктах, эксперименты команд.

·         Какие данные они трогают: базы, индексы, хранилища, внешние API.

·         Кто владелец каждого сервиса: команда, продукт, бизнес‑заказчик.

Параллельно имеет смысл поговорить с безопасностью и ИТ‑поддержкой — у них часто есть свои списки «подозрительных ИИ‑штук», которые никто не оформлял.

Шаг 2. Минимальные политики и запреты

Дальше — быстрые правила, которые можно ввести почти сразу:

·         Чётко прописать, какие типы данных нельзя скармливать внешним ИИ‑сервисам (персональные данные, коммерческая тайна и т.п.).

·         Запретить использование несанкционированных SaaS‑ассистентов для рабочих задач, пока они не пройдут оценку.

·         Для текущих пилотов: хотя бы зафиксировать, к каким системам у них есть доступ, и сократить очевидно лишние права.

Это уже снижает риск, даже если архитектура пока далека от идеала.

Шаг 3. Вводим единый AI‑шлюз для новых интеграций

Следующий шаг — перестать плодить прямые подключения:

·         Любая новая интеграция с LLM идёт через один входной слой (прокси, API‑шлюз, собственный сервис).

·         В этом слое сразу делаем аутентификацию, базовое логирование и хотя бы простые проверки запросов.

·         Для существующих пилотов планируем постепенную миграцию через этот шлюз.

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

Шаг 4. Обособляем данные и доступы

Теперь можно заняться данными и правами:

·         Разделяем индексы/хранилища по зонам доступа, убираем «общие суперхранилища» для всех ассистентов.

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

·         Ограничиваем перечень систем, с которыми конкретный ассистент или агент может работать.

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

Шаг 5. Вводим базовые фильтры и DLP для промптов/ответов

Когда шлюз и зоны данных есть, можно усиливать проверку содержимого:

·         Вешаем DLP‑правила на входящие и исходящие сообщения (маскирование, блокировка чувствительных паттернов).

·         Добавляем проверки для «опасных» режимов (генерация SQL/кода/команд) — либо через отдельные эндпоинты, либо с ручным подтверждением.

·         Начинаем собирать примеры срабатываний, чтобы донастраивать правила по реальным кейсам.

Шаг 6. Пилотный кейс «по-взрослому»

Чтобы не утонуть в теории, берём один конкретный сценарий и делаем его образцовым:

·         Выбираем популярный, но относительно контролируемый кейс (например, ассистент для службы поддержки или ИТ‑сервиса).

·         Прогоняем его через все слои: шлюз, политики, зоны данных, IAM, логи.

·         Замеряем до/после: какие риски сняли, сколько инцидентов ловим, насколько усложнили жизнь разработчикам (и как это компенсировать).

Этот кейс потом становится внутренним «референсом» для других команд.

Шаг 7. Платформенная модель и развитие

Когда один‑два кейса уже живут по новым правилам, можно:

·         Оформить всё как внутреннюю AI‑платформу: документация, гайды «как подключаться», шаблонные политики.

·         Завести регулярный процесс пересмотра: новые угрозы, новые сценарии, обратная связь от команд.

·         Постепенно подтягивать старые пилоты и новые инициативы под этот зонтик.

Вместо вывода

LLM в компании — это уже не игрушка для R&D, а новый крупный участник инфраструктуры. Он видит реальные данные, ходит в боевые системы и всё сильнее влияет на процессы. Если продолжать относиться к нему как к «умной библиотеке за прокси», мы по сути устраиваем ещё один неконтролируемый периметр внутри компании.

Подход Zero Trust даёт удобную рамку, чтобы вернуть эту историю под контроль: воспринимать модель и агентов как отдельных пользователей, раздать им минимально нужные права, ограничить видимость данных и действий, а весь трафик пропустить через слой политик и логирования. Это не делает ИИ «безопасным по определению», но превращает риски из хаотичных и непредсказуемых в управляемые.

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

Владислав Прокопович | CIO.логия