Approval Path

Два разных подтверждения

Путать их дорого в конкретную сторону: если долговечное решение реализовано как быстрое, перезапуск рантайма теряет ожидающий запрос, и агент либо зависает навсегда, либо — что хуже — продолжает без подтверждения (Durable Execution).

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

Что обязана хранить запись подтверждения

Шесть полей, без которых после инцидента нечего предъявить:

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

Последнее поле — то, которое обычно забывают, и именно оно отвечает на самый неприятный вопрос разбора: действие прошло штатно или кто-то продавил его в обход правила (Agent Audit Log).

Граница подтверждения ставится там, где живёт побочный эффект

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

Отсюда несколько разных форм в одной системе — подтверждение в долговечном процессе, подтверждение инструмента на стороне клиента, запрос структурированного ввода вместо «да/нет». Последняя форма стоит отдельного внимания: иногда системе нужно не разрешение, а недостающий параметр, и тогда подтверждение выглядит как запрос со своей схемой, а не как кнопка.

Подтверждение — состояние, а не вывод из разговора

Признак «подтверждено» устанавливается путём подтверждения и хранится как поле запуска. Он не выводится моделью из того, что пользователь написал что-то похожее на согласие: это ровно тот механизм, который порождает галлюцинацию действия (Action Hallucination).

Проверка на исполнении делается заново, по состоянию, а не по контексту диалога (Tool Gateway).

Одобряется точный артефакт, а не намерение

Для команды исполнения запись связывается как минимум с cwd, каноническим argv, релевантным env, разрешённым executable и, где возможно, байтами запускаемого скрипта. Для изменения skill та же идея принимает форму target + base_hash + proposal_revision + diff (Skill Change Control). Если любой связанный компонент изменился после показа человеку, старое одобрение недействительно.

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

Чего у нас не было: класс обратимости и правило цепочки

Сверка с OWASP AISVS C9.2 подтвердила основное — подтверждение как проверяемое состояние рантайма, а не как флаг в диалоге, — и добавила четыре требования, которых здесь не хватало.

Класс обратимости как первичное свойство действия. Каждое действие с высоким влиянием получает доверенную классификацию: только чтение, обратимое, обратимое внешними средствами, необратимое. Дальше рантайм применяет классификацию — блокирует, требует подтверждения или ограничивает. Это переворачивает постановку: не «на какие действия ставим подтверждение», а «какой класс обратимости у этого действия и что из него следует».

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

Полные параметры без усечения. Запрос подтверждения показывает человеку канонизированные и полные параметры действия — различия, команды, получателей, суммы, ресурсы, области — без обрезки и без небезопасных преобразований. Интерфейс, показывающий «списание средств» вместо суммы и получателя, превращает подтверждение в штамп, а не в решение.

Проверка моделью дополняет детерминированные ворота, но не заменяет их. Проверка планируемого рискованного действия моделью допустима как дополнительный слой; она не может быть единственным барьером и обязана быть защищена от манипуляции через инъекцию (Deterministic Veto, Prompt Injection).

Уровня 3 в стандарте, но назвать стоит: одобрение криптографически связывается с параметрами действия, личностью запросившего, контекстом исполнения и одноразовым значением, а ключевой материал держится вне рантайма агента.

Связано с

• Human in the Loop — когда звать человека и как не создать узкое место
• Tool Gateway — где проверяется состояние подтверждения
• Agent Control Plane — что решает, требуется ли подтверждение
• Action Hallucination — отказ, который случается при выводе согласия из текста
• Agent Audit Log — где живёт запись подтверждения
• Durable Execution — механика переживания перезапуска
• LangGraph HITL — реализация паузы и возобновления в графе
• Capability Containment — что ограничивает ущерб, если подтверждение дали зря