# Вопросы и ответы о безопасности AI для бизнеса > Экспертные ответы AI-first.tech для ИТ-директоров, директоров по кибербезопасности и руководителей бизнеса. - Канонический HTML: [/faq](https://ai-first.tech/faq) - Язык: русский - Редакционный принцип: защитный контекст без вредоносных полезных нагрузок и инструкций обхода. ## Какие контроли снижают риск prompt injection? Полностью устранить внедрение инструкций (prompt injection) нельзя: модель по своей природе не различает надёжно команды и данные. Поэтому защита строится не на «умном фильтре», а на архитектуре — ограничить, что модель может увидеть и сделать, проверять действия вне модели и замечать попытки манипуляции. OWASP ставит этот риск на первое место (LLM01). ### Архитектурные меры — дают наибольший эффект - Разделяйте инструкции и данные: системные правила задаются отдельно, а письма, документы, веб-страницы и найденный в RAG контекст помечаются как недоверенные данные, а не как команды. - Минимальные полномочия: модель и агент получают доступ только к тем данным и инструментам, которые нужны для конкретной задачи, с правами пользователя, а не сервисной «суперучётки». - Проверка действия вне модели: любой вызов инструмента проходит детерминированную проверку политики (кто, что, с какими данными, в каких пределах) до исполнения. - Подтверждение человеком для необратимых операций: платежи, удаление, рассылки, изменение прав и публикации. - Запрет действий на основании внешнего контента: инструкция, найденная в письме или на странице, не может инициировать отправку данных или вызов инструмента. ### Защитный слой на входе и выходе - Межсетевой экран для LLM или шлюз AI: проверка запросов и ответов по политикам, обнаружение типовых попыток обхода, маскирование чувствительных данных. - Контроль вывода: ответ модели проверяется перед передачей в браузер, базу данных, почту или другую систему; ссылки и вложения в ответе — отдельно. - Ограничение объёма и состава контекста: меньше лишних документов в контексте — меньше поверхность для косвенного внедрения. ### Наблюдаемость и проверка - Журнал связанной цепочки: пользователь, источник контекста, решение политики, вызов инструмента и результат — без избыточного хранения чувствительного текста. - Регулярное состязательное тестирование (red teaming) перед выпуском и после изменений модели, системного запроса или набора инструментов. - Сигналы для SOC: резкая смена роли модели, просьбы раскрыть инструкции, серии отказов подряд, неожиданные вызовы инструментов и обращения к внешним адресам. ### Что сделать в ближайшие 30 дней - Составить список AI-сценариев, где модель читает внешний контент (почта, документы, веб) и где у неё есть инструменты. - Для этих сценариев убрать лишние права и ввести подтверждение необратимых действий. - Провести первый цикл тестирования на внедрение инструкций и включить журналирование решений политики. Связанные карточки угроз: A01, A02, A03, A04, A52, A53, A60. ## Как безопасно подключать MCP-серверы к AI-агентам? MCP (Model Context Protocol) — стандартный способ подключить AI-агента к инструментам и данным компании. Каждый MCP-сервер расширяет возможности агента и одновременно поверхность атаки: описание инструмента, его ответы и выданный токен становятся каналами, через которые можно повлиять на агента или получить данные. Поэтому MCP-серверы нужно подключать так же, как стороннее ПО с доступом к критичным системам: через реестр, проверку и минимальные права. ### До подключения - Ведите реестр разрешённых MCP-серверов с владельцем, версией и назначением; всё, что не в реестре, запрещено. - Берите серверы из проверенных источников, фиксируйте версии и проверяйте пакет перед установкой — в публичных реестрах уже находили вредоносные MCP-пакеты. - Повторно проверяйте сервер при каждом изменении описания инструментов: подмена описания после одобрения — отдельный класс атак. ### Права и исполнение - Отдельный ограниченный токен на каждый сервер, без передачи пользовательского токена дальше по цепочке. - Локальные серверы с транспортом STDIO запускайте в изолированной среде с ограниченными правами; не открывайте локальные HTTP-серверы наружу. - Для значимых действий — подтверждение человеком; данные, возвращаемые инструментом, считаются недоверенными. ### Мониторинг - Журналируйте вызовы инструментов с привязкой к пользователю и агенту, отслеживайте вызовы вне задачи и обращения к новым адресам. - Подготовьте процедуру быстрого отключения сервера и отзыва его токенов. Связанные карточки угроз: A33, A34, A35, A37, A40. ## Что такое prompt injection и чем он опасен для бизнеса? Внедрение инструкций (prompt injection) — это ситуация, когда текст, попавший к модели, меняет её поведение вопреки правилам владельца системы. Источником может быть сам пользователь (прямое внедрение) или внешний контент — письмо, документ, веб-страница, файл в базе знаний (косвенное внедрение). Для бизнеса опасно не «странное сообщение чат-бота», а то, что модель с доступом к данным и инструментам может раскрыть сведения или выполнить действие от имени компании. ### Как это выглядит в компании - Ассистент, который суммирует почту, получает письмо со скрытой инструкцией и включает в ответ или в отправку данные, которые не должен был трогать. - Помощник по документам читает файл из общей папки, и текст в нём подменяет цель задачи — сводка становится искажённой. - Агент с доступом к инструментам выполняет действие, которое пользователь не запрашивал, потому что инструкция пришла из обрабатываемого контента. ### Последствия для бизнеса - Утечка конфиденциальных и персональных данных через ответы или вызовы инструментов. - Неверные решения на основе искажённых сводок и рекомендаций. - Действия от имени компании без согласования: письма клиентам, изменения в учётных системах. - Регуляторные и договорные риски: невозможно доказать, что правило соблюдалось. ### Главный вывод для руководителя - Риск определяется не самой моделью, а тем, к каким данным и действиям она подключена. Чем больше полномочий у AI-ассистента, тем важнее архитектурные ограничения и проверка действий вне модели. Связанные карточки угроз: A01, A02, A03, A04, A05, A07. ## Как связать OWASP LLM Top 10 и NIST AI RMF? Это документы разного уровня, и их удобно использовать вместе. NIST AI RMF 1.0 задаёт систему управления рисками AI в организации через четыре функции — Govern, Map, Measure, Manage. OWASP Top 10 для приложений на LLM (2025) — прикладной перечень конкретных рисков, которые нужно учесть при проектировании, разработке и тестировании. Практичная связка: NIST отвечает на вопрос «как устроен процесс», OWASP — «какие риски этим процессом закрывать». ### Как разложить OWASP по функциям NIST AI RMF - Govern (управление): политика использования AI, владельцы систем, реестр AI-сценариев, требования к поставщикам; сюда относятся решения по LLM03 «Цепочка поставки» и правила допустимых полномочий для LLM06 «Избыточная автономность». - Map (контекст и риски): для каждого AI-сценария определить данные, пользователей, инструменты и источники контекста; на этом шаге выявляются LLM01 «Внедрение инструкций», LLM02 «Раскрытие чувствительных данных», LLM08 «Слабости векторных хранилищ и эмбеддингов». - Measure (оценка): состязательное тестирование, оценка качества и устойчивости, проверка утечки системных инструкций (LLM07), достоверности ответов (LLM09 «Дезинформация») и отравления данных (LLM04). - Manage (меры и реагирование): межсетевой экран для LLM, контроль вывода (LLM05 «Небезопасная обработка вывода»), лимиты потребления (LLM10 «Неограниченное потребление»), мониторинг, реагирование на инциденты и откат. ### Практический порядок работы - Начните с реестра AI-систем и назначения владельцев — это основа функции Govern. - Для каждой системы проведите моделирование угроз по перечню OWASP и зафиксируйте применимые риски. - Свяжите каждый риск с мерой защиты, владельцем и способом проверки; результаты тестирования храните как доказательства. - Для генеративного AI используйте также профиль NIST AI 600-1, а для тактик атакующих — MITRE ATLAS. ### Что получит руководство - Единую карту: какие AI-системы есть, какие риски для них актуальны, какие меры внедрены и кто за них отвечает. Такая карта пригодна и для аудита, и для обоснования бюджета. Связанные карточки угроз: A01, A10, A34, A38, A46. ## Что проверить перед запуском AI-агента с доступом к API? Агент соединяет вероятностный вывод модели с реальными действиями в системах компании. Поэтому перед запуском проверяется не «насколько умна модель», а границы: от чьего имени агент действует, что он может изменить, какие действия требуют человека и как быстро его можно остановить. OWASP выделяет этот риск отдельно — LLM06 «Избыточная автономность». ### Полномочия и учётные записи - У агента отдельная учётная запись; он действует в пределах прав пользователя, инициировавшего задачу, а не под административным токеном. - Токены и ключи API ограничены нужными операциями и наборами данных, имеют срок жизни и не попадают в запросы к модели. - Перечень разрешённых инструментов и операций зафиксирован; всё, что не разрешено, запрещено по умолчанию. ### Контроль действий - Каждый вызов инструмента проходит проверку схемы данных и решения политики вне модели. - Необратимые и значимые операции — платежи, удаление, рассылки, изменение прав — требуют подтверждения человеком. - Лимиты: число действий, объём данных, длина цепочки вызовов, тайм-ауты и бюджет на сессию. - Инструкции из обрабатываемого контента (письма, страницы, документы) не могут инициировать действия. ### Подключаемые инструменты и MCP-серверы - Используются только проверенные и утверждённые инструменты с зафиксированными версиями; описание инструмента рассматривается как недоверенный текст. - Изменение описания или поведения инструмента после утверждения — повод для повторной проверки. ### Наблюдаемость и остановка - Журнал связывает пользователя, агента, версию модели и политики, вызовы инструментов и их результат. - Есть проверенная процедура отключения: отзыв токенов, отключение инструмента, откат версии. - Перед запуском проведён безопасный тест: попытки выйти за рамки задачи должны блокироваться и попадать в журнал. Связанные карточки угроз: A33, A34, A35, A36, A37, A54. ## Как защитить RAG и корпоративную базу знаний? RAG делает корпоративные документы частью каждого ответа модели. Главные риски — ассистент выдаёт пользователю сведения из документов, на которые у него нет прав, и ответы искажаются из-за ошибочного или подброшенного содержимого. Защита строится вокруг трёх вопросов: кто имеет право видеть документ, откуда он взялся и как проверить ответ. ### Права доступа - Проверка прав выполняется до поиска контекста, а не после формирования ответа: в контекст попадают только документы, доступные конкретному пользователю. - Коллекции разделены по назначению, владельцу и классу данных; кадровые, финансовые и клиентские сведения не смешиваются в общем индексе. - Для облачных и многоарендных хранилищ — изоляция данных разных клиентов и регулярные тесты изоляции. ### Целостность знаний - Добавление и изменение документов идёт через согласованную процедуру с владельцем и журналом изменений. - Источник и версия документа фиксируются; подозрительные или непроверенные материалы не попадают в индекс автоматически. - Найденный документ — это данные, а не инструкция: текст внутри документа не может менять правила ассистента. ### Проверяемость ответа - Ответ сопровождается ссылками на разрешённые источники. - В журнале сохраняются идентификатор коллекции, решение о доступе и версия индекса — это позволяет разобрать спорный ответ. - Векторные представления чувствительных документов защищаются так же, как сами документы. Связанные карточки угроз: A13, A14, A15, A16, A17. ## Что такое LLM Firewall и зачем он нужен? Межсетевой экран для LLM (LLM Firewall) — управляемый защитный слой между пользователями, приложениями, моделью, базой знаний и инструментами. Он применяет политики к запросам и ответам, маскирует чувствительные данные, обнаруживает попытки обхода ограничений и ведёт технический журнал. Это не замена управлению доступом, а точка, где правила компании применяются к каждому обращению к модели. ### Что он делает - На входе связывает запрос с учётной записью, целью и классом данных, применяет политики и выявляет попытки внедрения инструкций. - Маскирует или блокирует персональные данные, секреты и коммерческую тайну до передачи во внешнюю или внутреннюю модель. - На выходе проверяет ответ: чувствительные фрагменты, опасные ссылки, код и структуры вызова инструментов. - Ограничивает объём и частоту запросов, защищая бюджет и доступность сервиса. - Ведёт журнал решений политики для SOC и аудита. ### Чего он не делает - Не заменяет права доступа к документам в RAG и минимальные полномочия агентов. - Не гарантирует обнаружение всех вариантов внедрения инструкций — поэтому нужны архитектурные ограничения действий. ### Как выбрать и проверить - Проверяйте в пилоте на своих сценариях: долю обнаруженных попыток, ложные срабатывания на рабочих запросах, задержку ответа и удобство настройки политик. - Уточните, где хранятся журналы и тексты запросов, и как решение интегрируется с вашей системой идентификации и SIEM. Связанные карточки угроз: A01, A02, A09, A10, A29. ## Как бороться с теневым AI в компании? Теневой AI — использование сотрудниками внешних AI-сервисов, расширений и ключей API вне согласованного контура. Полный запрет обычно не работает: работа уходит в менее заметные каналы. Эффективнее сочетать инвентаризацию, безопасную корпоративную альтернативу и контроль чувствительных данных. ### Шаги - Инвентаризация: какие сервисы и расширения используются, с какой целью и какие данные туда попадают; собирайте не только названия, но и бизнес-задачу. - Безопасная альтернатива: корпоративный доступ к моделям через шлюз с журналированием и маскированием данных, каталог одобренных инструментов и понятный порядок согласования новых. - Правила: какие классы данных запрещено передавать во внешние сервисы, кто согласует исключения и на какой срок. - Технический контроль: защита от утечек для веб-сервисов AI, контроль браузерных расширений, учёт и ротация ключей API. - Обучение: короткие практические инструкции для сотрудников вместо общих запретов. ### Что показывать руководству - Долю инвентаризированных AI-сценариев, число одобренных безопасных маршрутов, скорость обработки заявок и повторяющиеся причины обхода правил. Связанные карточки угроз: A12, A46, A47, A59. ## С чего начать программу безопасности AI в компании? Начинать стоит не с покупки продукта, а с понимания, какие AI-системы уже работают и к чему они подключены. Реалистичный горизонт первого этапа — 90 дней: инвентаризация, правила, защита самых рискованных сценариев и наблюдаемость. ### Первые 30 дней — видимость - Реестр AI-систем и сценариев: владелец, данные, пользователи, модели, интеграции и инструменты. - Политика использования AI: допустимые сервисы, классы данных, порядок согласования. - Выбор 2–3 самых рискованных сценариев: доступ к персональным данным, внешний контент, агенты с действиями. ### 30–60 дней — базовые меры - Шлюз AI или межсетевой экран для LLM для приоритетных сценариев, маскирование чувствительных данных. - Минимальные полномочия для агентов и подтверждение необратимых действий. - Права доступа в RAG до поиска контекста. - Требования к поставщикам AI: где обрабатываются данные, как используются для обучения, какие журналы доступны. ### 60–90 дней — контроль и доказательства - Журналирование и передача событий в SOC, сценарии реагирования на инциденты с AI. - Первый цикл состязательного тестирования и повторная оценка рисков. - Отчёт руководству: карта рисков, внедрённые меры, остаточный риск и план на следующий квартал. ### Опорные документы - NIST AI RMF для процесса управления, OWASP Top 10 для LLM для перечня рисков, ISO/IEC 42001 — если компании нужна сертифицируемая система менеджмента AI. Связанные карточки угроз: A46, A47, A12, A34, A13. ## Как предотвратить утечку данных через AI-ассистентов? Данные утекают через AI по четырём основным каналам: их отправляют во внешние сервисы, модель раскрывает их в ответах, они оседают в журналах запросов, а секреты попадают в запросы и контекст. Для каждого канала нужна своя мера. ### Меры по каналам - Внешние сервисы: корпоративный шлюз с маскированием, правила по классам данных, контроль браузерных расширений. - Ответы модели: права доступа к источникам до поиска контекста, проверка ответа на чувствительные фрагменты, минимизация данных в контексте. - Журналы запросов: относитесь к ним как к хранилищу чувствительных данных — сроки хранения, доступ по ролям, шифрование, маскирование. - Секреты: ключи и пароли не передаются в запросах и системных инструкциях, хранятся в хранилище секретов, регулярно ротируются; сканирование запросов и кода на секреты. ### Отдельно для разработчиков - Ассистенты программирования получают только нужный репозиторий, с исключением файлов с секретами; используются корпоративные учётные записи с журналированием. Связанные карточки угроз: A09, A10, A11, A12, A41, A48. ## Как обезопасить цепочку поставки моделей? Модели, адаптеры, наборы данных и библиотеки — такие же поставляемые артефакты, как код, и могут изменить поведение системы ещё до первого запроса пользователя. Защита — это управляемый путь от внешнего источника до промышленной среды. ### Ключевые меры - Утверждённые источники моделей и библиотек; загрузка из произвольных репозиториев — не рутинная операция. - Проверка целостности: контрольные суммы и подписи, фиксированные версии, сканирование файлов моделей; предпочтение безопасным форматам, которые не исполняют код при загрузке. - Опись состава AI-системы (AI BOM): модель, адаптеры, данные, зависимости, лицензии, версии — связанные с выпуском. - Отдельная среда оценки: совместимость, поведение на контрольных сценариях, отсутствие скрытых закладок — до допуска в промышленную среду. - Защищённый реестр моделей с разграничением прав и журналом изменений; защита весов модели от кражи. - Заранее подготовленный отзыв: как отключить модель или библиотеку и переключить трафик. Связанные карточки угроз: A18, A19, A20, A21, A22, A23, A24, A49, A50. ## Как защититься от дипфейков и AI-фишинга? Генеративный AI делает фишинг грамотнее, а поддельные голос и видео — убедительнее. Главный вывод: впечатление «я узнаю голос и лицо» больше не является подтверждением личности. Защита строится на процедурах, которые не зависят от правдоподобия сообщения. ### Процедуры - Подтверждение срочных платежей и передачи данных по независимому каналу и заранее известному контакту, а не по реквизитам из сообщения. - Правило двух лиц для переводов и изменения платёжных реквизитов; задержка для переводов новым получателям. - Явное право сотрудника отказаться выполнять срочное распоряжение без проверки. ### Технические меры - Защита почты и проверка отправителя, маркировка внешних писем, фильтрация вложений и ссылок. - Устойчивая к фишингу многофакторная аутентификация для руководителей и финансовой службы. ### Люди - Регулярные учения с реалистичными сценариями, включая голосовые и видеозвонки; отдельные инструкции для финансовой службы, ассистентов руководителей и службы поддержки. Связанные карточки угроз: A55, A56, A57. ## Какие метрики AI Security показывать руководству? Руководству нужны не технические счётчики, а ответы на три вопроса: видим ли мы все AI-системы, защищены ли самые рискованные из них и способны ли мы заметить и остановить инцидент. Метрики стоит группировать именно так. ### Видимость - Доля AI-систем в реестре с назначенным владельцем и оценкой риска. - Число выявленных случаев теневого AI и доля переведённых на одобренные маршруты. ### Защищённость - Доля приоритетных AI-сценариев за шлюзом или межсетевым экраном для LLM. - Доля агентов с минимальными полномочиями и подтверждением необратимых действий. - Доля моделей и компонентов из утверждённых источников с проверенной целостностью. ### Готовность к инцидентам - Доля AI-систем, события которых поступают в SOC. - Время от обнаружения до отключения инструмента или отзыва доступа на учениях. - Результаты последнего состязательного тестирования и статус устранения найденного. ### Важно - Целевые значения задаются исходя из риск-аппетита компании; метрика без владельца и плана улучшения превращается в отчётность ради отчётности. Связанные карточки угроз: A45, A46, A60. ## Как провести пилот и выбрать решение класса AI Security? Выбирать решение стоит по результатам пилота на ваших сценариях, а не по презентации. Пилот должен проверить конкретные угрозы, а не «общую безопасность AI». ### Подготовка - Выберите 2–3 реальных сценария и угрозы для них (например, внедрение инструкций в почтовом ассистенте, обход прав в RAG, избыточные полномочия агента). - Заранее сформулируйте критерии успеха: что должно блокироваться, что журналироваться, какие ложные срабатывания допустимы. ### Что проверять - Эффективность на ваших данных и сценариях, долю ложных срабатываний на рабочих запросах. - Влияние на задержку и стоимость, удобство описания политик. - Интеграцию с системой идентификации, SIEM и процессами реагирования. - Где обрабатываются и хранятся данные и журналы, соответствие требованиям к месту обработки. - Как решение обновляется и как поставщик подтверждает свои заявления. ### Инструменты сайта - Матрица пилота связывает каждую угрозу с мерой защиты, профилями решений и проверяемыми критериями — её можно использовать как основу программы пилота. Связанные карточки угроз: A47, A01, A13, A34. ## Какие требования регулирования к AI учитывать в России? Для государственных информационных систем ключевой документ — приказ ФСТЭК России № 117 от 11.04.2025, вступивший в силу 1 марта 2026 года и заменивший приказ № 17. Он впервые содержит отдельные требования к защите информации при использовании технологий искусственного интеллекта. Для коммерческих компаний этот приказ не обязателен напрямую, но задаёт понятный ориентир, а требования к обработке персональных данных действуют независимо от того, используется AI или нет. ### Что требует приказ № 117 (пункты 60–61) - Защищать наборы данных, модели и их параметры, а также сервисы, которые их обрабатывают. - Использовать только доверенные технологии искусственного интеллекта. - Не передавать защищаемую информацию разработчику модели. - Контролировать наборы данных и определять критерии достоверности результатов. - Контролировать взаимодействие пользователей с AI-сервисами. ### Кого касается - Государственные органы, государственные унитарные предприятия, государственные учреждения, муниципальные информационные системы, а также подрядчиков, работающих с такими системами. Методические материалы ФСТЭК по применению приказа детализируют эти требования. ### Практический вывод для бизнеса - Реестр AI-систем, контроль данных, передаваемых во внешние модели, журналирование обращений пользователей и требования к поставщикам моделей полезны независимо от того, распространяется ли приказ на вашу компанию. - Отдельно проверьте, не передаются ли во внешние AI-сервисы персональные данные и не нарушаются ли требования к месту их обработки. Связанные карточки угроз: A48, A46, A12, A47. ## Как подготовить SOC к инцидентам с AI? SOC не сможет расследовать событие с участием AI, если видит только сетевое соединение или отказ модели. Нужна связанная цепочка событий и заранее отработанные сценарии реагирования. ### Какие данные собирать - Учётные записи пользователя, сервиса и агента, идентификатор сессии. - Версию модели, системных инструкций и политики, решение политики по запросу. - Источники найденного контекста, вызовы инструментов и их результат — без избыточного хранения чувствительного текста. ### На что настроить обнаружение - Серии отказов политики и попытки раскрыть инструкции. - Необычное расширение полномочий агента и вызовы инструментов вне задачи. - Массовое извлечение документов из базы знаний и нетипичные обращения к внешним адресам. - Резкий рост потребления токенов и запросов к модели. ### Сценарии реагирования - Кто и как отключает инструмент, отзывает токены агента, откатывает версию модели или системных инструкций. - Регулярные учения на безопасных сценариях. Отдельно учитывайте, что AI-помощники самого SOC тоже могут получать искажённые данные киберразведки или недостоверные рекомендации. Связанные карточки угроз: A42, A43, A44, A58, A29. ## Как защитить ассистентов для программистов? Ассистенты программирования ускоряют разработку, но добавляют три риска: в код попадают уязвимости, в проект подтягиваются несуществующие или поддельные зависимости, а секреты и исходный код уходят во внешние сервисы. ### Меры - Сгенерированный код проходит те же проверки, что и написанный человеком: экспертная проверка, статический анализ, тесты безопасности. - Новые зависимости проверяются по утверждённому реестру пакетов; имя пакета, предложенное ассистентом, не принимается на веру. - Ассистент работает через корпоративную учётную запись с журналированием, получает доступ только к нужному репозиторию; файлы с секретами исключены из контекста. - Сканирование запросов и кода на секреты, регулярная ротация ключей. Связанные карточки угроз: A39, A40, A41, A38. ## Как ограничить расходы и защитить AI-сервис от перегрузки? Модель оплачивается по объёму работы, поэтому злоупотребление бьёт одновременно по бюджету и доступности. OWASP выделяет это как LLM10 «Неограниченное потребление». ### Меры - Квоты и лимиты на пользователя, ключ и приложение: число запросов, объём контекста, длина ответа, бюджет на сессию. - Ограничение длины цепочек вызовов агентов и тайм-ауты. - Аутентификация на всех точках подключения к модели; закрытие публичного доступа к внутренним интерфейсам. - Мониторинг потребления и оповещение о непропорциональном росте у отдельного пользователя или ключа. - План деградации: что отключается первым при перегрузке, чтобы сохранить критичные сценарии. Связанные карточки угроз: A29, A30, A32, A25. ## Как защитить инфраструктуру AI в Kubernetes? Kubernetes помогает изолировать и эксплуатировать AI-нагрузки, но сам по себе не защищает модель, базу знаний и агентов. Нужны два слоя: укрепление кластера сокращает радиус поражения, а прикладной AI-слой отдельно контролирует доверие к контексту, данным и действиям. ### Изоляция и доступ - Разделите шлюз, исполнение модели, поиск контекста и обработчики агентов по пространствам имён и при необходимости по пулам узлов. - Ролевой доступ в пределах пространства имён и отдельные сервисные учётные записи для каждой нагрузки. - Запрет входящих и исходящих соединений по умолчанию; явно разрешены только нужные связи между компонентами. - Для общих графических ускорителей — изоляция заданий и очистка памяти между ними. ### Поставка и секреты - Подписанные образы, подтверждённое происхождение и политика допуска в кластер; модели и веса — из утверждённого реестра. - Секреты хранятся в хранилище секретов и не попадают в запросы к модели, переменные окружения отладочных контейнеров и журналы. ### Телеметрия - Журналы Kubernetes, события доступа и изменения развёртываний связываются с журналами шлюза AI, поиска контекста и вызовов инструментов — так видно не только, что изменилось в кластере, но и как это повлияло на AI-сервис. - Базовая проверка конфигурации по CIS Kubernetes Benchmark — необходимый минимум, но не замена моделированию угроз для AI. Связанные карточки угроз: A31, A32, A30, A20, A50.