INFERA Security · текстовая версия

Методика безопасного использования ИИ

Методика INFERA Security для моделей, ассистентов и автономных агентов: что разрешать, какие данные куда направлять, как допускать компоненты и что делать при инциденте.

Версия 1.0 · июль 2026Текстовая версия PDFСкачать PDF
Статус методикиЭто методика INFERA Security, а не типовой нормативный акт и не готовый локальный документ организации. Её можно использовать как основу для собственной политики, регламента, модели угроз и технических требований. К1–К3 и Д1–Д6 — классификационная модель INFERA Security, а не термины законодательства. Перед внедрением юрист и ИБ-служба должны проверить применимые требования, включая 152-ФЗ, 98-ФЗ, требования к КИИ и 243-ФЗ о поддержке развития технологий искусственного интеллекта.
01

Область применения и термины

Методика предлагает набор принципов и контрольных требований для выбора, допуска, разработки и контроля ИИ-моделей и агентов, используемых на оборудовании организации, в её сетях или с её данными.

Принцип по умолчанию — fail-closed. В адаптированной на её основе политике то, что явно не разрешено, запрещается. При отказе контроля действие блокируется; послабление возможно только в изолированной экспериментальной среде. Ответственность за действие агента несёт назначенный или запустивший его человек.

ИИ-агент

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

Контур и компоненты

Конечная точка, MCP-сервер, скилл, RAG, база знаний, исходящий трафик, песочница, посредник секретов, AI-BOM и реестр доверенных компонентов.

Атаки на контекст

Prompt injection — вредная команда в тексте, письме или веб-странице. Отравление памяти или индекса — внесение недостоверных данных, влияющих на будущие ответы.

Контроль

HITL — ручное одобрение; kill switch — аварийный останов; circuit breaker — автоматическая остановка по порогам; shadow AI — неучтённые инструменты.

02

Классы ИИ-сервисов и данных

К1 Личный внешний сервис

Личный аккаунт или сервис вне реестра организации. Для любых рабочих данных запрещён.

К2 Корпоративный внешний сервис

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

К3 Внутренний контур

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

Классы данных
КлассСодержание и примеры
Д1 ПубличныеОпубликованные материалы, открытый код, общедоступные знания.
Д2 ВнутренниеРабочая переписка и инструкции без ограничительного грифа.
Д3 КонфиденциальныеКоммерческая тайна, закрытый код, договоры, финансы, данные клиентов.
Д4 Персональные данныеЛюбые ПДн, включая ФИО с идентификаторами, контакты и кадровые сведения.
Д5 СекретыПароли, токены, ключи, строки подключения и конфигурации доступа.
Д6 Особо регулируемыеГосударственная, банковская, врачебная и иная специальная тайна.
03

Матрица разрешённых потоков

Сервис вне реестра автоматически относится к К1. «Ограниченно» означает не автоматическое разрешение, а прохождение условий: минимизация, маскирование, согласование владельца, договор, правовое основание, локализация и журналирование.

ДанныеК1 · личныйК2 · внешний через шлюзК3 · внутренний
Д1 · публичныеРазрешеноРазрешеноРазрешено
Д2 · внутренниеЗапрещеноРазрешено с проверкамиРазрешено
Д3 · конфиденциальныеЗапрещеноТолько обезличенные фрагменты и с разрешением владельцаРазрешено при контроле доступа
Д4 · ПДнЗапрещеноТолько при правовом основании, мерах защиты и соблюдении 152-ФЗТребования 152-ФЗ сохраняются
Д5 · секретыЗапрещеноЗапрещеноВ модель не передаются; доступ только через посредник
Д6 · особый режимЗапрещеноЗапрещеноТолько отдельное решение ИБ
Никогда не отправлять во внешние модели: секреты, не обезличенные ПДн, идентифицируемую коммерческую тайну, данные под NDA, сведения о неисправленных уязвимостях и документы с ограничительным грифом целиком. Передавать следует минимальный контекст, а не каталог, базу или почтовый ящик целиком.
04

Выбор и допуск моделей

  1. Любая модель, сервис и агент допускаются только через реестр доверенных компонентов; при несоответствии допуск отзывается, использование блокируется.
  2. Фиксируются происхождение, поставщик или репозиторий, базовая модель, обучение и дообучение, версия и контрольная сумма.
  3. При допуске и обновлении проверяется целостность артефакта и цепочки поставок.
  4. Для Д3 и выше, решений в отношении людей и критичных процессов проводятся испытания качества и устойчивости, включая prompt injection и извлечение системного промпта.
  5. Договор К2 должен описывать обучение на данных организации, юрисдикцию и место обработки, инциденты, доступность и поручение обработки ПДн.
  6. Фиксируются встроенные фильтры безопасности; отключать их запрещено. Для КИИ и государственного управления применяются требования к доверенным технологиям ИИ.
05

Роли и обязанности

РольМинимальная ответственность
ПользовательРаботает только с К2/К3 из реестра, соблюдает матрицу, проверяет ответы, не отключает контроль, сообщает об инцидентах.
РазработчикИспользует одобренные ассистенты и компоненты, проводит ревью кода, работает под профилем разработки.
Владелец агентаРегистрирует агента, отвечает за его действия и обеспечивает работу под контролем.
Администратор ИБВедёт реестр и классификатор, настраивает политики, проводит проверки и согласует исключения.
SOCМониторит события, управляет очередью одобрений, выполняет останов и разбирает инциденты.
Ответственный за ИИВедёт политику, оценку воздействия, отчётность и ежегодный пересмотр.
Юрист / ответственный за ПДнПроверяет договоры, уведомления, трансграничные передачи и режим коммерческой тайны.
Руководитель подразделенияОбеспечивает ознакомление сотрудников и согласование ИИ в процессах с Д3 и выше.
06

Меры технического контроля

До отправки

  • поиск секретов и ПДн с блокировкой или маскированием;
  • проверка класса данных и сервиса;
  • минимизация контекста и контроль буфера обмена, терминала и файлов.

На шлюзе

  • проверка входящих и исходящих данных на инъекции, ПДн и секреты;
  • блокировка обхода, SSRF, неразрешённых адресов;
  • лимиты частоты, объёма и стоимости.

При вызове инструмента

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

После ответа

  • человек проверяет факты, расчёты, ссылки и тему;
  • сгенерированный код не запускается автоматически;
  • ссылки и вложения считаются недоверенным вводом.
07

Базы знаний и RAG

RAG переносит документы в контекст модели, поэтому индекс — отдельная поверхность атаки.

  1. В индекс попадают только источники с установленным происхождением; внешние и пользовательские материалы сначала проверяются и маркируются как недоверенные.
  2. Для каждой записи сохраняются источник, автор, дата и версия; устаревшее удаляется, индекс регулярно проверяется на отравление.
  3. Извлечение соблюдает права пользователя и агента. Индексы разделяются по уровням конфиденциальности и подразделениям; секреты в индекс не помещаются.
  4. Извлечённые фрагменты обрабатываются как данные, а не инструкции; перед необратимым действием проверяется происхождение источника.
  5. Журналируется, какие записи попали в запрос. При отзыве доверия источник изымается из индекса, а обращения к нему прекращаются.
08

Правила для всех пользователей

  1. Использовать только К2/К3 из реестра; новый сервис согласовывать с ИБ.
  2. Работать под корпоративной учётной записью; личные аккаунты для рабочих задач запрещены.
  3. Не обходить средства контроля VPN, прокси, личной точкой доступа или иным способом.
  4. Считать ответ ИИ черновиком: проверять факты, цифры, цитаты, ссылки и нормативные акты. Решение о людях, деньгах и обязательствах принимает человек.
  5. Не выдавать непроверенный результат за проверенный и раскрывать использование ИИ там, где этого требует процесс.
  6. При самостоятельной отправке данных, удалении, запросе ключей или другом подозрительном поведении остановить агента и сообщить в ИБ.
  7. Никогда не передавать секрет агенту в запросе, файле или временно; доступ к учётным данным возможен только через посредник.
09

Правила для разработчиков

  1. Кодовые ассистенты, MCP-серверы, скиллы и расширения — только одобренные и из реестра; эксперименты — в изолированной среде без боевых данных.
  2. Во внешние модели не передаются закрытые исходники, конфигурации, реальные схемы БД, инфраструктурный код, секреты и код под NDA. Допустимы минимальные обезличенные или синтетические примеры.
  3. Сгенерированный код проходит ревью человеком, статический анализ, анализ состава, проверку пакетов, уязвимостей и лицензий. Прямые коммиты агента в защищённые ветки запрещены.
  4. В CI/CD агент имеет собственную идентичность и минимальные права; он не может одобрить собственное изменение; политики и развёртывание требуют второго человека.
  5. Собственные и сторонние компоненты проверяются на адресат токенов, подмену прав, безопасность сессий и возвратных адресов, URL, разрешения и зависимости; выпуск фиксируется версией и контрольной суммой.
10

Изоляция и контроль агентов

Пользователь
или задача
Политика
и реестр
Песочница · шлюз · журнал
  1. Агент работает в контейнере, песочнице или отдельной учётной записи с минимальными правами; администраторский запуск запрещён.
  2. Файловый доступ ограничен белым списком; профили браузера, ключи ОС и каталоги секретов недоступны. Агенты разных владельцев не разделяют сессии, память и учётные данные.
  3. Каждый агент имеет идентичность, владельца и сквозной идентификатор сессии. Права назначаются белыми списками инструментов и адресов; ключи короткоживущие и подставляются посредником.
  4. Прямой исходящий трафик блокируется; для SaaS фиксируются журналы и порядок инцидентов; для Д6 применяется изолированный контур без интернета.
  5. Журналируются вызовы моделей, инструментов, MCP и ОС в защищённый журнал не менее 12 месяцев. Действуют предохранители по итерациям, объёму, стоимости и отказам.
  6. Необратимые действия проходят через очередь ручных одобрений. Доступен kill switch с обрывом трафика и сохранением снимка состояния.
  7. Ведётся AI-BOM: модели, агенты, MCP-серверы, скиллы и индексы с версиями и происхождением. Неучтённое обнаруживается и помещается в карантин.
11

Организационные меры

  1. Утвердить политику ИИ, назначить ответственного и владельцев агентов; управлять по циклу «планирование — внедрение — проверка — улучшение».
  2. Вести классификатор Д1–Д6 и перечень коммерческой тайны; защищать режим совокупностью мер.
  3. До запуска с Д3+ или в процессах, затрагивающих права людей, проводить оценку воздействия: назначение, данные, ущерб и меры снижения.
  4. Проводить инструктаж при приёме и не реже раза в год; разработчиков дополнительно обучать инъекциям, цепочке поставок и утечкам через контекст.
  5. Закреплять требования к ИИ в договорах и NDA; для ПДн выполнять процедуры по 152-ФЗ и отдельно оценивать трансграничную передачу.
  6. Нормировать нагрузку на контролёров ручных одобрений; перегрузку решать перераспределением, а не ослаблением контроля.
  7. Проводить внутренний аудит не реже раза в год, фиксировать несоответствия и сроки устранения.
12

Инциденты

Инцидентом считаются утечка Д3–Д6, компрометация ключа, неконтролируемое действие, вредоносный MCP или скилл, обход контура, успешная инъекция, изменение системного промпта или отравление базы знаний.

Действия работника

  1. Остановить агента штатным механизмом.
  2. Не удалять переписку и следы.
  3. Немедленно сообщить в SOC/ИБ.

Действия SOC

  1. Выполнить аварийный останов.
  2. Отозвать токены, ключи и доверие к артефакту.
  3. Сохранить снимок, разобрать журнал и воспроизвести сессию при необходимости.
Сообщение об ошибке в течение рабочего дня — смягчающее обстоятельство. Сокрытие инцидента — отягчающее. Удаление истории после передачи данных не отменяет факт утечки.
13

Исключения

В организации, которая адаптирует методику, отступление оформляется администратором ИБ как временное исключение с обоснованием, владельцем и сроком. Бессрочные исключения запрещены. Для Д4–Д6 требуется дополнительное согласование с директором ИБ. Все исключения пересматриваются при обновлении локальной политики.

14

Контроль и пересмотр

В организации, которая адаптирует методику, соблюдение проверяется автоматическими точками контроля, журналом аудита и ежегодными аудитами. Нарушение утверждённой локальной политики влечёт предусмотренные ею меры; при утечке ПДн или коммерческой тайны применяются 152-ФЗ, 98-ФЗ и иное применимое право.

Не реже раза в год проводится тестирование контура имитацией атак, обновляется модель угроз по БДУ ФСТЭК и признанным таксономиям атак на агентный ИИ. Локальный документ пересматривается ежегодно и после существенных изменений, новых классов агентов или инцидентов.

Нормативные и методические ориентиры

Приказ ФСТЭК России №117 и методические материалы ФСТЭК по защите информации при использовании ИИ; ГОСТ Р 59276-2020; ГОСТ Р 56939-2024; ГОСТ Р 59547-2021; ГОСТ Р ИСО/МЭК 42001-2024; 152-ФЗ, 98-ФЗ, 187-ФЗ; 243-ФЗ о поддержке развития технологий искусственного интеллекта. Перед утверждением необходимо проверить действующие редакции и применимость к конкретной организации.

Что улучшено в текстовой версииЛогика PDF сохранена, но убраны разрывы страниц и плотные таблицы, формулировки «запрещено / ограниченно / разрешено» приведены к одному виду. Добавлены быстрый маршрут внедрения, явная граница между методикой и законом и проверяемые обязанности владельца, SOC и пользователя.