AI-порталAI-портал

Approval Bypass Prevention в 2026: как не дать агенту обойти human gate косвенным путём

Approval bypass prevention в 2026: как проектировать policy, tool graph и state transitions так, чтобы risky action не мог пройти мимо human review через обходной маршрут.

Approval bypass prevention в 2026 нужен потому, что risky action чаще обходят не прямым нарушением policy, а косвенным путём. Команда вроде бы поставила human gate на send_email или issue_refund, но рядом остались другие маршруты: draft становится auto-send, CRM update триггерит внешний webhook, browser flow коммитит действие через другой инструмент. Формально правило "approval required" существует, а practically side effect всё равно уходит без человека.

Approval bypass — это ситуация, когда действие, которое должно было пройти через человека, всё равно выполняется через другой маршрут. Не обязательно злонамеренно. Иногда это просто плохо спроектированный tool graph.
Самый вредный anti-pattern - ставить approval только на один obvious tool call и считать, что этого достаточно. В production gate должен покрывать не имя инструмента, а весь class risky outcome.

Короткая версия

Хорошая anti-bypass policy в 2026 обычно определяет:

  1. Какие outcomes требуют approval
  2. Какие tools и маршруты могут к ним привести
  3. Какие state transitions без approval запрещены
  4. Как проверяется approval token
  5. Какие обходные пути считаются invalid

Что особенно важно

  • gate нужно ставить на outcome class, а не только на один API call;
  • draft, queue, webhook и browser routes часто становятся обходными путями;
  • approval должен быть привязан к конкретному action payload, а не быть общим флагом;
  • orchestration layer важнее, чем prompt-level запрет.
Без техники
Approval стоит только на `send_email`, но агент может обновить CRM поле, которое запускает автоматическую рассылку.
С техникой
Policy видит класс outcome `external_communication`, требует approval token для всех маршрутов и блокирует side effects без валидного gate.
ПромптBypass intuition
Почему approval gate на одном tool name часто недостаточен?
Ответ модели

Потому что тот же risky outcome может быть достигнут через другой tool, webhook или state transition. Контролировать нужно outcome class, а не только одну точку вызова.

1. Approvals должны покрывать outcome, а не интерфейс

Полезно думать не в терминах:

  • tool_x requires approval;

а в терминах:

  • external communication;
  • money movement;
  • data deletion;
  • policy exception;
  • customer-visible publication.

Именно outcome определяет риск, а не конкретное имя функции.

2. Обходные пути часто прячутся в непрямых side effects

Особенно опасны:

  • auto-send after draft;
  • webhook-triggered downstream action;
  • browser submit через generic browser tool;
  • state mutation, после которой другая система коммитит действие;
  • chained tools, где второй шаг уже outside review boundary.
Если один risky outcome можно достигнуть более чем одним маршрутом, gate должен проверяться на уровне общего action class.

3. Approval token должен быть action-bound

Плохо:

  • один глобальный флаг approved=true;
  • reusable approval for whole session;
  • approval without payload hash or packet id.

Лучше:

  • approval packet id;
  • payload digest;
  • expiry;
  • allowed outcome class;
  • one-time use semantics.

Так approval нельзя легко переиспользовать для другого действия.

4. Gate полезно проверять в нескольких местах

Сильная схема обычно включает:

  • pre-execution policy check;
  • tool wrapper validation;
  • state transition validation;
  • audit trail after execution.

Один единственный guardrail часто оказывается слишком узким.

5. Что особенно часто ломают команды

Approval on one tool only

Другие routes остаются открыты.

Reusable approval state

Один approve открывает слишком широкий коридор действий.

No outcome taxonomy

Непонятно, какие side effects считаются эквивалентными.

Hidden automation after draft

Draft path quietly превращается в execute path.

No bypass testing

Команда проверяет happy path approval, но не пытается обойти gate.

6. Какие метрики полезны

Минимальный dashboard обычно включает:

  • risky actions blocked for missing approval;
  • approval token reuse attempts;
  • side effects executed outside intended gate;
  • bypass findings in red-team tests;
  • routes mapped to each approval class;
  • post-incident cases caused by hidden execution path.

Плюсы

  • Outcome-level gating снижает риск косвенного обхода approval
  • Action-bound approvals лучше защищают от token reuse
  • Многоуровневая проверка делает human gate реальным control point
  • Bypass testing помогает увидеть скрытые side effects до инцидента

Минусы

  • Нужно поддерживать taxonomy risky outcomes и route mapping
  • Система становится строже и сложнее для orchestration
  • Legacy integrations часто содержат скрытые side effects
  • Без хорошего audit trail трудно доказать, где gate был обойдён

Пример approval-bound action

{
  "packet_id": "pkt_182",
  "outcome_class": "external_communication",
  "payload_hash": "sha256:abc123",
  "expires_at": "2026-04-09T12:05:00Z"
}

Простой bypass check

def may_execute(action, approval):
    if action["outcome_class"] != approval["outcome_class"]:
        return False
    if action["payload_hash"] != approval["payload_hash"]:
        return False
    return True

Практический совет: если approval gate не защищает outcome class целиком, а охраняет только один удобный API call, это почти всегда не gate, а иллюзия контроля.

Проверьте себя

1. Почему approval нельзя привязывать только к одному tool name?

2. Что особенно полезно хранить в approval token?

3. Какой anti-pattern особенно опасен?

Источники

  1. OpenAI Agents SDK - Human in the loop
  2. OpenAI Agents JS - Human in the loop
  3. LangGraph Docs - Human in the loop
  4. OWASP Top 10 for LLM Applications
Предыдущая
Agent Policy Exception Audits в 2026: как разбирать не только сами исключения, но и качество их обработки
Следующая
Approval Fatigue Management в 2026: как не превратить human-in-the-loop в конвейер без внимания