Контроль
без Approve

Суть выпуска

В отраслевых разговорах 2025–2026 уже не спорят, «нужен ли человек в петле». Спорят, где именно он стоит: на каждом tool call, по эскалации, по уровню риска — или вообще только в политике доступа. Классический HITL (human-in-the-loop: человек утверждает шаг за шагом) плохо масштабируется: агенты делают всё больше рутины, а ревьюер, который жмёт Approve, не видя данных, tool calls и причины, подписывает ритуал, а не контролирует.

На практике у меня на сервере картина жёстче и проще одновременно. Coding-агент в CLI всегда в YOLO (режим «не спрашивай разрешение на каждый tool call»: флаги вроде --dangerously-skip-permissions / yolo). Без этого headless-фон, длинный план и нормальная скорость мертвы: процесс встаёт на Enter, которого никто не нажмёт. Контроль при этом не исчезает — он переезжает: в правила, крючки (hooks — скрипты до/после действия), запрет веток, изоляцию изменений и явные пороги, где без человека нельзя.

Этот выпуск — не обзор модных терминов (embedded oversight, human-on-the-loop, risk-tiered autonomy). Это карта, как это собрано в бою: где автомат, где checkpoint, где запрет; почему «approve на каждый шаг» в CLI — ложный контроль; и чем эта схема отличается на coding, рекламном API, разборе доступов и выкате в прод.

Связано, но не дублирует: обвязка вокруг модели (№021), «агент ≠ чат» (№022), фронт vs тыл (№024), CLI в фоне (№020), plan/work (№005). Здесь — только ось контроля.

Что унесёте

1. Почему YOLO в CLI — не «отсутствие дисциплины», а осознанный отказ от ритуального approve.
2. Таблицу порогов: авто / черновик / checkpoint / запрет — по reversibility и blast radius.
3. Четыре живых контура с разной глубиной HITL на одной площадке.
4. Что смотреть вместо количества кнопок: diff, ветка, лог tool calls, кто жмёт irreversible.
5. Три копипаст-промпта: аудит порогов, черновик политики агента, стартовый guard.

Три иллюзии контроля

Задача

Понять, от чего именно отказываемся, прежде чем хвалить YOLO. Иначе «убрали approve» читается как «пустили агента без ремней».

Почему это важно

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

• Иллюзия 01

  Approve на каждый tool

  Диалог «Allow?» после чтения файла, grep, линта.

  Через 20 кликов жмут Yes вслепую. Скорость падает, смысла нет.
• Иллюзия 02

  Второй агент-судья

  «Один пишет, второй проверяет».

  Модели одной семьи прощают гладкий, но кривой вывод. На деньгах — не замена человеку (№024).
• Иллюзия 03

  Человек «где-то рядом»

  Агент в проде: «если что — посмотрим логи».

  Без порога и fail-closed «если что» = уже после инцидента. Разбор — не контроль.

Как закрываем

Не «больше кнопок», а осмысленный oversight: правила заданы заранее; рутина без кликов; человек — там, где действие необратимо или цена ошибки выше минуты его внимания; видимость (diff, трейс, контекст) достаточна, чтобы решение было judgment, а не штамп.

Итог

Три рыночные формулировки переводятся на рабочий язык так:

• Embedded oversight — правила, skills, hooks, лимиты прав до сессии, а не модалка в конце.
• Human-on-the-loop — агент идёт сам; человек входит по эскалации и на checkpoint.
• Risk-tiered autonomy — автономия зависит от обратимости и радиуса поражения, не от «доверяем модели в целом».

YOLO в CLI — зачем так

Задача

Агент должен править код, гонять команды, читать логи, собирать черновик — часами, иногда в фоне, без человека у монитора.

Почему classic HITL здесь мёртв

Каждый «Allow read file?» — не security, а latency. В headless (фон без интерактива) процесс просто зависает на первом вопросе: Enter некому нажать. В интерактиве — та же усталость, что у любого «подтвердите 40 раз». В выпуске про CLI в фоне это уже разложено: без skip-permissions / yolo фоновый конвейер не живёт; рядом обязательна клетка.

Как

Coding-сессии на сервере стартуют с полным tool access без пошагового approve. Это относится и к основному CLI, и к внешнему агенту с флагом вроде --dangerously-skip-permissions. Параллельно:

• агент не коммитит и не пушит без явного запроса — оставляет working tree, показывает diff;
• ветка не main/develop — иначе pre-commit режет коммит;
• деплой скриптом выката — только человек, автономный агент не запускает его сам;
• деструктив (force-push, hard reset, DROP, stop nginx/postgres, rm по системным путям) — блок хуком или явное «спроси владельца».

# Идея запуска, не дословный прод-скрипт
agy --print --dangerously-skip-permissions --add-dir /opt/<project> "..."
# YOLO снимает модалки. AGENTS.md + hooks + git policy остаются.

Итог

YOLO отвечает на вопрос «можно ли tool call без клика». Он не отвечает на «можно ли влить в прод» и «можно ли DROP TABLE». Смешивать эти уровни — главная ошибка внедрения.

Контроль слева: правила, крючки, ветки

Задача

Раз агент не спрашивает на каждый шаг — ограничения должны сработать до опасного действия, автоматически и одинаково для всех CLI на машине.

Почему

Политика «в голове оператора» не масштабируется на несколько агентов и ночные прогоны. Политика в файле + хук, который режет команду до shell, — масштабируется.

Как устроено (экспонаты)

1. Инструкции проекта — единый файл для агентов (часто AGENTS.md + ops-гайд). Жёсткий stop: если ветка production — сначала feature-ветка, потом правки. Прямой edit в production-ветке = инцидент pipeline. Deploy только через штатный скрипт; «просто npm build» ломает blue/green-слоты — это тоже записано, не «все знают».

# Фрагмент политики (схема, имена обобщены)
HARD STOP — Branch check
  main | develop → создать <agent>/<scope>-<slug> ДО первого edit
Deploy — только человеком, bash deploy.sh (не «из головы»)
Автономный агент: не commit/push без явного запроса
Destructive: rm -rf / DROP / force-push / reset --hard —
  только с явного согласия на этот вызов

2. Git pre-commit — не стиль, а стоп на production-ветках:

# Смысл хука (укороченно)
branch=$(git branch --show-current)
case "$branch" in
  main|develop)
    echo "HARD STOP: direct commits to '$branch' are blocked."
    exit 1
    ;;
esac

3. Bash-guard до выполнения — перехватчик команд агента. Exit 2 = блок. Типичный стартовый набор (ставится до первого инцидента, не после):

• git push --force, git reset --hard, git clean -f
• rm -rf по системным корням (/, /opt, /etc, /var…)
• systemctl stop/disable на nginx и PostgreSQL
• DROP DATABASE/TABLE, TRUNCATE, DELETE FROM без WHERE
• опасный docker stop/rm на боевых контейнерах
• запись в .env через redirect (секреты не через shell-костыль)

# Идея guard (фрагмент логики)
case "$CMD" in
  *"git push --force"*|*"git reset --hard"*)
    echo "BLOCK: подтверди с пользователем." >&2; exit 2;;
  *"DROP DATABASE"*|*"DROP TABLE"*|*"TRUNCATE "*)
    echo "BLOCK: деструктивный SQL." >&2; exit 2;;
esac

4. Секреты и чувствительные правки — отдельные хуки (скан секретов, запрет «тихой» записи env). 5. Skills — job description на типовые работы (деплой-инварианты, контент-гард), чтобы агент не изобретал процедуру заново.

Итог

Это и есть embedded oversight на сервере: человек один раз (и постоянно уточняя) задаёт клетку; YOLO только убирает шум approve. Обвязка модели подробнее — в №021; здесь важен сдвиг: контроль = политика + enforcement, не диалог «можно?».

Карта порогов

Задача

Один агент, разные действия — разная автономия. Без таблицы команда спорит ощущениями.

Цифры выката и разборов доступов — с той же площадки, что в выпусках про деплой-инварианты и про фронт/тыл (№024): не «рыночный слайд», а журнал.

Итог

Risk-tiered autonomy — это не framework с рынка. Это таблица, которую можно распечатать и сверить за час. Если действие нельзя однозначно положить в корзину — по умолчанию строже (черновик или checkpoint), не «пусть модель решит».

Четыре контура — разный HITL

Одна площадка, один владелец, четыре разных глубины человека в процессе. Это важнее, чем общий лозунг «мы за / против HITL».

• Контур A

  Coding CLI

  YOLO toolsdeploy

  YOLO на tool calls; правки в ветке. Commit/push по запросу; deploy — только человек. Скорость разработки; irreversible отдельно.

• Контур B

  Фоновый CLI

  yoloread-mostly

  Yolo + лимит ходов + read-mostly. В прод-список агент не пишет. Без Enter процесс жив; клетка уже.

• Контур C

  Рекламный builder

  черновик×2 approve

  Сбор данных, критики, план. Два approve: до create и до launch. Деньги; 9-состоянийная машина статусов.

• Контур D

  Доступ / бан

  ясный кейсспорное

  Ясный кейс — авто-вердикт. Спорное + сбой движка — человек. 110/114 снятий без ручных заявок; 4 оставили.

Почему не «везде одинаково»

Цена ошибки разная. Ошибочный grep — ноль. Ошибочный launch кампании — деньги и репутация кабинета. Ошибочный «атака, бан навсегда» без fail-open — живой человек без сервиса. Ошибочный deploy — все пользователи сайта. Поэтому аргумент о скорости разработки (velocity) (Amazon-style: жёсткий HITL убивает скорость) верен для coding-рутины и неверен как универсальный закон для денег и доступов.

Обратная крайность — «после rogue-агента только approve на всё» — возвращает иллюзию из раздела 01. Meaningful human judgment нужен на критических точках, с контекстом. Не на каждом ls.

Видимость важнее числа кнопок

Задача

Даже правильный checkpoint бесполезен, если ревьюер видит только «Approve / Reject» без следа.

Что реально нужно на checkpoint

• Diffчто изменилось в файлах, не «агент говорит, что починил».
• Ветка и scopeне main; один агент — одна ветка (конвенция <agent>/<scope>-<slug>).
• Намерениеplan/задача: зачем правка, что не трогали.
• Граница blast radius«только контент» vs «схема БД» vs «nginx».
• Что агент не сделалdeploy, push, launch: если сделал без права — это уже инцидент политики.

В plan/work-цикле (№005) после фазы — пауза на ручную проверку: не потому что «так принято в agile», а потому что intent и product-логика не закрываются зелёным lint'ом. Авто-проверки — build-grade; человек — на смысле.

Structured human contact (человек как tool call, а не plaintext «пожалуйста, одобри») — полезен в продуктовых агентах: статус awaiting_approve_1 / awaiting_approve_2 в state machine рекламного контура нельзя «заболтать» свободным текстом. В coding CLI достаточно явного запроса владельца в сессии + git-истории.

Observability — не дашборд ради дашборда. Это условие, при котором checkpoint = oversight. Без трейса кнопка Approve — подпись под пустым бланком.

«Цифровой сотрудник» — без HR-сказки

Рынок любит говорить, что агентам нужны job description, identity, менеджер, offboarding. На сервере это переводится без романтики:

Это стыкуется с №018 (операционный слой: skills vs rules, гниение без ухода) и с №025 (публичный API: fail-closed, модель угроз). Новый слой в этом выпуске один: YOLO без job description — это не сотрудник, а случайный root с LLM.

Промпты: забрать к себе

Ниже — три текста для своего агента. В копируемых блоках длинные тире заменены на запятые/двоеточия (удобнее в рабочих markdown-файлах). В самом выпуске тире обычные.

Ты аудируешь контроль AI-агентов в этом проекте (и соседних, если указаны пути).

Задача: построить таблицу risk-tiered autonomy. Не общие советы, только то, что видно в файлах, скриптах, CI, hooks, runbooks.

Корзины:
1) АВТО: обратимо, blast radius низкий
2) ЧЕРНОВИК: агент готовит, человек вливает
3) CHECKPOINT: нужен явный approve человека
4) ЗАПРЕТ: только с отдельного согласия или технически заблокировано

Найди и заполни:
- правила агента (AGENTS.md, CLAUDE.md, .cursor, skills)
- git hooks / pre-commit / branch protection
- bash/command guards
- deploy path: кто может выкатить
- деньги/внешние API: create, launch, charge
- destructive: rm, DROP, force-push, stop shared services
- фоновые job'ы и headless CLI (yolo / skip-permissions)

Выход (markdown):
| Действие | Корзина сейчас | Где зафиксировано (path) | Дыра / риск | Предлагаемая корзина |

В конце: топ-5 дыр, где агент фактически может irreversible, а политика молчит.
Числа и пути: только из репо. Не выдумывай. Не уверен: «не найдено».

Напиши раздел политики для AGENTS.md (русский, коротко, без воды).

Контекст:
- coding CLI работает в YOLO / skip-permissions (не спрашивать approve на каждый tool)
- автономный агент НЕ commit/push без явного запроса владельца
- deploy только человек
- main/develop: запрет прямых коммитов, только feature-ветки <agent>/<scope>-<slug>
- destructive (force-push, reset --hard, DROP, stop nginx/postgres, rm системных путей): блок или явное согласие на этот вызов
- деньги и внешний launch API: минимум один human checkpoint, лучше два (create и launch)

Формат:
## Project invariants (agent control)
- маркированный список, каждый пункт: правило + зачем (одна строка)
## Risk tiers (краткая таблица markdown)
## Do not (5-8 запретов)

Без маркетинга. Без «революционный». Готово вставить в файл.

Спроектируй стартовый bash-guard для AI coding agent на shared production server.

Требования:
- вход: команда shell, которую агент хочет выполнить
- выход: allow или block с короткой причиной в stderr
- стартовый блок (обязательно до первого инцидента):
  force-push, reset --hard, git clean -f,
  rm -rf по системным корням,
  systemctl stop/disable nginx и postgresql,
  DROP DATABASE/TABLE, TRUNCATE, DELETE FROM без WHERE,
  опасный docker stop/rm на shared контейнерах,
  запись в .env через shell redirect
- не блокировать обычный dev: git status, test, lint, edit в рабочей копии
- список «расширение по инцидентам»: 5 примеров, которые добавляют ПОСЛЕ реального сбоя, не заранее раздувая

Выход:
1) псевдокод case/grep логики
2) таблица: паттерн -> block message -> false positive risk
3) как логировать block, не светя секреты

Не привязывай к конкретному вендору CLI. Контракт: pre-tool hook.

Развязка

Вопрос «нужен ли человек в процессе» для работающей агентной площадки устарел. Рабочий вопрос: где порог, какая видимость, кто отвечает за irreversible.

На coding CLI у меня человек убран с каждого tool call (YOLO) и оставлен на commit/push по запросу, на deploy, на destructive и на всём, что жжёт деньги снаружи. Правила и hooks — oversight до сессии. Diff и ветки — oversight в момент решения. Accountability — на владельце, не на «модели».

Если внедряете агентов и первым делом рисуете Approve на каждый шаг — вы покупаете спокойствие, а не контроль. Если включаете YOLO без таблицы корзин — вы покупаете скорость в кредит под проценты инцидента. Нормальная схема скучнее маркетинга: клетка слева, скорость в середине, человек на краю обрыва.