Полномочия, безопасность и устойчивость

Безопасный процесс начинается с ясного разделения: ИИ-система получает права на действие, а люди и организация сохраняют ответственность за решение, границы и последствия.

Фраза «агент отвечает за действие» опасна двусмысленностью. Система может технически исполнить действие. Она не принимает на себя юридическую ответственность и не освобождает человека, который утвердил процесс.

Четыре роли в одном действии #

Для значимого действия запишите:

1. Инициатор — кто поставил цель.
2. Владелец результата — кто отвечает за итог и меняет границы.
3. Исполнитель — человек, обычная программа или ИИ-система.
4. Проверяющий или согласующий — кто независимо подтверждает допустимость.

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

Отдельная служебная учётная запись #

ИИ-система не должна наследовать полные права разработчика или оператора.

Служебная учётная запись позволяет:

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

NIST рассматривает отдельные учётные записи, полномочия и границы программных агентов. Это концептуальный материал, а не отраслевой норматив. [NIST-2026-agent-id]

Для рабочего процесса используйте отдельную наблюдаемую учётную запись с ограниченными делегированными правами. [G1-D4-p18], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 18.

Нулевые фоновые полномочия #

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

В записи права есть:

• разрешённое действие;
• ресурс и область;
• максимальный объём;
• срок;
• инициатор;
• основание;
• обязательная проверка;
• событие отзыва.

Постоянный широкий доступ удобнее в настройке, но увеличивает возможный ущерб от ошибочного или вредоносного входа.

Политика вне инструкции #

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

Запрет закрепляют:

• в правах учётной записи;
• в программной проверке;
• в схеме инструмента;
• в лимите суммы или объёма;
• в обязательном согласовании;
• в изолированной среде;
• в сетевом ограничении;
• в неизменяемом журнале, если это нужно.

Контекст влияет на поведение, но не заменяет такую защиту. Тезис Google о контексте как новой границе безопасности отвергнут. [G1-D4-p10], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 10.

Модель угроз #

Минимальная модель угроз рассматривает:

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

NIST в аналитическом материале 2026 года рассматривает риски инструментов, идентичности, данных и действий. Сводка ответов не является окончательным стандартом, но помогает построить перечень вопросов. [NIST-2026-agent-security]

OWASP дополняет его открытой отраслевой моделью угроз. [OWASP-AGENTIC-TOP10-2026]

Изоляция #

Недоверенный код и инструмент запускаются в краткоживущей среде с минимальными правами и ограниченной сетью. [G1-D4-p13], Vibe Coding Agent Security and Evaluation_Day_4.pdf, с. 13.

Изоляция проверяется действием:

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

Наличие контейнера в схеме не доказывает изоляцию.

Уровни A0–A3 #

Уровень назначается конкретному типу действия в конкретном процессе.

A0 — советует #

Система анализирует или готовит материал для чтения. Она не запускает действие и не подготавливает привилегированную операцию к немедленному выполнению.

Примеры: объяснить отклонение, предложить варианты, подготовить черновик отчёта.

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

A1 — подготавливает #

Система создаёт готовое изменение. Человек проверяет его и отдельно запускает применение.

Примеры: подготовить изменение кода, платёжное поручение, письмо, изменение прав.

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

Человек должен совершить осмысленное действие. Кнопка «подтвердить» без видимого содержания создаёт видимость контроля.

A2 — исполняет в заданных границах #

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

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

Обязательные условия:

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

A3 — ведёт ограниченный цикл #

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

Обязательные условия:

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

Универсального уровня «делай всё» нет.

Почему зрелость не повышает A автоматически #

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

Управляемая медицинская рекомендация может навсегда остаться на A0. Зрелая система подготовки платежа может оставаться на A1.

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

Повышение A требует доказательств именно для действия. Общий балл процесса не подходит.

Договор о самостоятельности #

Перед A2 или A3 владелец подписывает рабочий договор:

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

Устойчивость #

Критический процесс должен пережить три класса отказа:

1. модель недоступна;
2. качество ухудшилось;
3. источник или инструмент недоступен либо скомпрометирован.

Варианты:

• ручной режим;
• обычная автоматизация;
• чтение без действия;
• сокращённая область;
• очередь до восстановления;
• безопасная остановка.

Резерв проверяют на практике. Документ «перейдём вручную» не доказывает, что люди, доступ и время действительно есть.

Правовая навигация #

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

Персональные данные в России #

Федеральный закон № 152-ФЗ устанавливает обязанности оператора при обработке персональных данных. Выводы о согласии, поручении обработки, трансграничной передаче и мерах защиты зависят от фактов. [RU-152-FZ]

С 1 июля 2025 года действуют изменения требований к первичной записи и хранению персональных данных граждан России.

Из этого не следует универсальное правило «использовать локальную модель по умолчанию». Архитектура зависит от роли организации, состава данных и операций. [RU-PD-localization-2025]

Вопросы для проверки:

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

Регламент ЕС об ИИ #

Регламент ЕС об ИИ использует риск-ориентированный подход и распределяет обязанности между участниками. Применимость зависит от роли и системы. [EU-AI-ACT-framework]

Разъяснения Европейской комиссии по статье 50 опубликованы 20 июля 2026 года. Требования прозрачности статьи 50 в общем случае начинают применяться 2 августа 2026 года.

Для отдельных ранее выпущенных систем, подпадающих под статью 50(2), действует переходный срок до 2 декабря 2026 года. [EU-AI-ACT-2026-transparency-guidelines] [EU-AI-ACT-timeline]

Проверьте:

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

Финансовый рынок России #

Банк России опубликовал 16 июня 2026 года рекомендации по безопасному применению ИИ на финансовом рынке. Они отражают отраслевые ожидания к риску, безопасности и контролю. Их нельзя автоматически переносить на организацию вне финансового рынка. [CBR-2026-safe-ai]

Рабочая карточка главы #