#AI-агенты: процедура исполнения (runtime)

Версия: 1.0 · Обновлено: 2026-05-28 · Теги: AI-агенты, runtime, мониторинг, kill-switch, ограниченный режим, аварийное отключение · Tier: 1-4

TL;DR. Состояния агентного сценария от запуска до аварийного отключения. Каждое состояние имеет владельца, сигналы перехода и обязательные подтверждения. Без определённого пути обратно в нормальный режим — релиз в прод не допускается.

#1. Состояния runtime

stateDiagram-v2
    [*] --> Off
    Off --> Staging: enable\n(prepare environment)
    Staging --> Pilot: pilot approval
    Pilot --> Production: production approval
    Production --> Restricted: degraded signals
    Restricted --> Production: signals recovered
    Restricted --> Paused: incident
    Production --> Paused: incident
    Paused --> Production: resume approval
    Paused --> Off: rollback
    Production --> KillSwitch: emergency
    Restricted --> KillSwitch: emergency
    Paused --> KillSwitch: emergency
    KillSwitch --> Off: stabilize

Состояние	Что значит	Кто переводит
Off	Агент не запущен, коннекторы недоступны	По умолчанию после регистрации
Staging	Изолированная среда, утверждённые тестовые данные	Владелец агента
Pilot	Ограниченный круг пользователей, реальные коннекторы с лимитом	AI Lead + MLSec
Production	Полный круг пользователей в рамках области	AI Lead + Risk
Restricted	Часть действий заблокирована, остальное продолжает работать	Автоматически по сигналам или владелец
Paused	Все действия заблокированы, агент не принимает новые запросы	Владелец / SecOps
Kill-switch	Аварийная остановка всей платформенной интеграции	SecOps / IR-on-call

[!warn] Переход Production → Restricted должен быть автоматическим по сигналам. Если этот переход требует человека — пилот не пройден.

#2. Включение и предзапуск

Перед переходом в Pilot / Production проверяется:

Проверка	Подтверждение
Реестр инструментов и коннекторов соответствует утверждённой карточке	Diff vs утверждённая версия = 0
Делегированные полномочия активны, срок не истёк	valid_until > now + 14d
Сервисные учётные записи имеют RBAC-потолок, ниже которого делегирование не работает	Тест без полномочий → действие отклонено
SIEM получает события с задержкой ≤ 5 минут	Контрольное событие → запрос в SIEM ≤ 5m
Kill-switch отрабатывает за заданное время	Замер 3 прогона: каждый ≤ SLA
Резервный сценарий описан	Документ + сценарий тестирования

#3. Мониторинг

Минимум сигналов, собираемых в SIEM / Prometheus:

Сигнал	Назначение
agent_actions_total{tool,scope,result}	Объём действий по инструментам и областям
agent_action_latency_seconds{tool}	Латентность инструмента
agent_policy_denied_total{reason}	Сколько раз политика отказала, по причинам
agent_approval_pending_seconds	Сколько висят запросы согласования
agent_memory_writes_total{purpose}	Активность записи в долгосрочную память
agent_handoffs_total{from,to}	Передачи управления
agent_killswitch_state	0 / 1
agent_runtime_errors_total{type}	Ошибки исполнения по типу

Иллюстративные правила — prometheus-agent-alerts.yaml.

#Триггеры автоматического перехода в Restricted

• всплеск agent_policy_denied_total выше базового порога (X3 за 10 минут);
• всплеск ошибок коннектора;
• появление новых policy.violation событий;
• латентность инструмента > 95-процентиль за окно;
• утечка PII в tool.call аргументах (детектор DLP).

[!info] Restricted не значит «всё сломано». Это «работаем в read-only / без чувствительных коннекторов, разбираемся с сигналом». Часть пользы агент продолжает приносить.

#4. Ограниченный режим (Restricted)

В Restricted допускаются только:

• инструменты с read_or_write = read;
• инструменты с уровнем согласования Auto;
• внутренние утверждённые коннекторы;
• ответы без действий с внешним эффектом.

Запрещены:

• write-действия любого уровня;
• внешние коннекторы (включая email, мессенджеры);
• запись в долгосрочную память.

Переход обратно в Production — только после зелёного статуса сигналов в течение окна стабилизации (обычно 30 минут — 2 часа) и подтверждения владельцем.

#5. Изменения в утверждённом сценарии

Тип изменения	Процесс
Косметика (логи, имена)	Обычный PR + ревью
Уточнение существующего инструмента в пределах области	PR + согласование владельца + журнал в реестре
Расширение области инструмента / коннектора	Существенное изменение → повторная оценка
Добавление инструмента / коннектора	Существенное изменение → повторная оценка
Смена базовой модели / провайдера	Существенное изменение → повторная оценка
Смена identity среды исполнения	Существенное изменение → повторная оценка

[!warn] Существенное изменение обновляет evidence_pack_ref в реестре. Нельзя «дописать» сценарий, не пройдя через rubeж готовности.

#6. Приостановка (Paused)

Применяется, когда:

• получен внешний сигнал от MLSec / IR;
• защитная проверка обнаружила прорыв (см. Security Overlay §1);
• зафиксировано подозрение на компрометацию коннектора;
• запущен инцидент-плейбук.

В Paused агент не принимает новые входы, но сохраняет состояние, чтобы расследование могло восстановить контекст.

#7. Аварийное отключение (Kill-switch)

Должно быть одной командой, владелец процедуры — SecOps / IR-on-call.

Что происходит:

1. Все коннекторы агента переводятся в режим Deny на уровне платформы.
2. Сервисная учётная запись агента отзывается (или ротируется).
3. Делегированные полномочия аннулируются.
4. Текущие in-flight действия останавливаются (по возможности откатываются).
5. Создаётся snapshot состояния памяти и журнала.
6. Запускается incident playbook.

[!danger] Kill-switch — это не «остановить контейнер». Контейнеры можно перезапустить. Kill-switch отзывает полномочия так, чтобы даже при возврате к работе агент не мог продолжить с того же места без явного re-approval.

Шаблоны команд и регламент — runbook-connector-quarantine.md (ссылка).

#8. Возврат к работе после Paused / Kill-switch

Из состояния	Что нужно для возврата
Paused → Production	Корневая причина устранена + ревью + ретест защитных проверок
Restricted → Production	Окно стабилизации зелёных сигналов + подтверждение владельца
Kill-switch → Off → Pilot	Полный re-approval как при первичном включении + новый evidence pack

#9. Свидетельства (evidence pack)

Минимум для прохождения rubeжа:

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

Шаблон — agent-evidence-pack-template.md.

#10. Связь с другими документами

• Сигналы и переходы → Operating Overlay §5.
• Уровень контроля → Security Overlay.
• Действия при kill-switch → Incident Playbook.
• Что должно быть готово до Production → Production Readiness Checklist.