Kill Switch для AI-агентів: як аварійно зупинити дії без релізу

Ідея за 30 секунд

Kill switch — це аварійний контроль у runtime, який дозволяє миттєво зупинити нові дії агента під час інциденту, без релізу і без зміни prompt.

Коли це потрібно:
коли агент може виконувати write-дії, працює з зовнішніми API і помилка вже переростає в production-інцидент.

Проблема

Коли агент починає робити шкідливі дії, часу на "підкрутити prompt і зробити реліз" зазвичай немає. Поки команда аналізує проблему, агент може продовжувати робити ті самі дії. І кожна хвилина затримки — це нові побічні ефекти в production.

Типова картина:

• дублікати листів або повідомлень
• масові create/update операції
• зайві виклики зовнішніх API

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

Якщо kill switch працює тільки в UI, це не аварійний контроль. Реальна зупинка має відбуватись у runtime loop і в tool gateway.

Рішення

Рішення — додати централізований kill-switch policy layer, який перевіряється після формування наступної дії агента, але перед її виконанням. Policy повертає allow або stop з явною причиною: killed_global, killed_tenant, writes_disabled, tool_disabled.

Базова модель:

• global kill — аварійно зупиняє всіх
• tenant kill — зупиняє конкретного клієнта
• writes disabled — дозволяє read, блокує write
• tool disabled — точково блокує конкретний інструмент

Це окремий аварійний рівень керування, а не частина промпта чи UI-логіки.

Kill switch ≠ повна governance-система

Kill switch і governance вирішують різні задачі:

• Kill switch зупиняє інцидент "тут і зараз"
• Governance керує поведінкою агента постійно (RBAC, ліміти, бюджети, approval)

Одне без іншого не працює добре:

• без kill switch інцидент складно зупинити миттєво
• без governance інциденти трапляються надто часто

Контур kill-switch контролю

Ці перевірки працюють разом як аварійний контур у runtime.

Як це виглядає в архітектурі

Kill switch policy layer стоїть у runtime loop між плануванням і виконанням наступної дії агента. Кожне рішення (allow або stop) фіксується в audit log.

Кожен крок проходить через цей flow перед виконанням: runtime не виконує дії напряму, а передає рішення policy layer.

Коротко по flow:

• Runtime формує наступну дію
• Policy читає global/tenant flags + writes/tool rules
• allow -> виконується наступна дія агента
• stop -> run зупиняється з явним reason (killed_global, killed_tenant, writes_disabled, tool_disabled)
• рішення пишеться в audit log

Приклад

Агент підтримки почав масово відправляти email.send через помилковий сценарій. Оператор вмикає writes_disabled для конкретного tenant.

Результат:

• нові write-дії блокуються одразу
• read-дії можуть лишатися доступними
• у логах є who/when/why для кожного блокування

Kill switch зупиняє інцидент прямо в runtime loop, а не чекає нового релізу.

У коді це виглядає так

У спрощеній схемі показано основний flow. На практиці kill state читається централізовано і кешується на секунди. Критично: kill-check має бути O(1) і працювати з коротким кешем (1-2 секунди), інакше аварійна зупинка спрацьовує із запізненням. У production той самий kill-check зазвичай дублюють у tool gateway, щоб жоден виклик не міг обійти runtime-контроль.

Приклад kill-switch конфігурації:

kill_switch:
  global_flag: agent_kill_global
  tenant_flag_prefix: "agent_kill_tenant:"
  writes_disabled_default: false
  disabled_tools_key: agent_disabled_tools
  cache_ttl_seconds: 2

while True:
    action = planner.next(state)
    action_key = make_action_key(action.name, action.args)  # стабільний ключ для dedupe/audit

    kill_state = kill_store.read(tenant_id=state.tenant_id)
    decision = kill_policy.check(kill_state, action)

    if decision.outcome == "stop":
        audit.log(
            run_id,
            decision=decision.outcome,
            reason=decision.reason,
            scope=decision.scope,
            action=action.name,
            action_key=action_key,
            actor=kill_state.last_updated_by,
        )
        return stop(decision.reason)

    result = tool.execute(action.args)

    audit.log(
        run_id,
        decision=decision.outcome,
        reason=decision.reason,
        scope=decision.scope,
        action=action.name,
        action_key=action_key,
        result=result.status,
    )

    if result.final:
        return result

Kill switch зупиняє нові дії. Для in-flight дій зазвичай потрібен окремий best-effort cancel механізм.

Як це виглядає під час виконання

Сценарій 1: global stop

1. Оператор активує global_kill=true.
2. Runtime формує наступну дію і читає kill state.
3. Policy повертає stop (reason=killed_global).
4. Нові дії не виконуються.
5. У логах є scope=global і actor.

Сценарій 2: tenant stop

1. Для tenant t_42 активують tenant_kill=true.
2. Run-и цього tenant отримують stop (reason=killed_tenant).
3. Інші tenant продовжують працювати.
4. Інцидент локалізовано без глобальної зупинки.

Сценарій 3: writes disabled

1. Активовано writes_disabled=true.
2. Read-дія проходить з allow.
3. Write-дія отримує stop (reason=writes_disabled).
4. Система переходить у read-only degrade mode.

Типові помилки

• kill switch тільки в UI, але не в runtime/tool gateway
• один глобальний stop без per-tenant режиму
• відсутній writes-disabled режим
• довгий cache TTL (хвилини замість секунд)
• відсутній audit trail для operator actions
• відсутній перевірений incident runbook

У результаті команда має "кнопку", але не має реального аварійного керування.

Самоперевірка

Швидка перевірка kill switch перед запуском у production:

FAQ

Q: Що вмикати першим: global stop чи writes disabled?
A: Почни з writes_disabled, якщо інцидент у write-діях. global_kill використовуй, коли ризик широкого збою і потрібна миттєва повна зупинка.

Q: Де саме перевіряти kill switch?
A: Мінімум у двох місцях: у runtime loop перед наступною дією і в tool gateway перед виконанням інструмента.

Q: Чи можна кешувати kill state?
A: Так, але коротко (секунди). Під час інциденту хвилинний кеш робить kill switch майже марним.

Q: Як технічно реалізувати kill flags?
A: Зазвичай це глобальні й tenant-scoped прапорці в Redis/конфіг-сховищі, які policy layer читає перед кожною дією.

Q: Kill switch скасовує вже запущені дії?
A: Не завжди. Він надійно блокує нові дії. Для in-flight задач потрібен окремий best-effort cancel механізм.

Q: Чи може kill switch замінити RBAC і бюджети?
A: Ні. Kill switch — аварійний stop-механізм. RBAC, ліміти й бюджети потрібні як постійний контроль.

Де Kill Switch у загальній системі

Kill switch — це аварійний рівень Agent Governance. Разом із RBAC, бюджетами, approval і audit він формує повну production-систему контролю.

Пов'язані сторінки

Далі за темою:

• Огляд Agent Governance — загальна модель контролю агентів у production.
• Контроль доступу (RBAC) — як обмежити, хто і що може виконувати.
• Контроль бюджетів — як обмежувати витрати і runaway run-и.
• Step limits — як зупиняти цикли на рівні runtime loop.
• Human approval — де потрібне ручне підтвердження перед ризиковою дією.