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

Approval Packet Expiry в 2026: когда человеческое согласование уже устарело

Approval packet expiry в 2026: как задавать срок жизни approval packet, чтобы старое согласование не открывало путь для уже изменившегося risky action.

Approval packet expiry в 2026 нужен потому, что человеческое согласование стареет так же, как стареет evidence. Reviewer мог одобрить refund, письмо или policy exception пять минут назад, но за это время изменились customer state, сумма, вложение, получатель или supporting evidence. Если approval packet не имеет срока жизни, система воспринимает старое approve как универсальное разрешение и начинает коммитить действие в уже изменившемся контексте.

Expiry означает, что approval действует не бесконечно. Через какое-то время или после изменения payload его нужно запросить заново.
Самый вредный anti-pattern - считать, что раз человек уже нажал Approve, это разрешение можно использовать до конца сессии. Для risky actions approval должен жить ровно столько, сколько остаётся валиден сам reviewed state.

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

Хорошая approval expiry policy в 2026 обычно задаёт:

  1. Сколько живёт approval packet
  2. Какие изменения payload его инвалидируют
  3. Какие evidence changes требуют re-approval
  4. Какие action classes живут дольше или короче
  5. Как UI показывает expired approval

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

  • expiry должен зависеть от risk class;
  • payload change важнее простого времени;
  • stale approval нельзя quietly переиспользовать;
  • approval packet и reviewed state должны быть связаны явно.
Без техники
Reviewer одобрил отправку письма, а агент через 20 минут поменял recipient и всё равно отправил его по старому approve.
С техникой
Payload hash изменился, packet стал invalid, и система запросила новое согласование вместо silent reuse.
ПромптExpiry intuition
Почему approval packet не должен жить бесконечно?
Ответ модели

Потому что reviewed state меняется. Старое согласование начинает относиться не к тому действию, которое система хочет выполнить сейчас.

1. Approval стареет вместе с reviewed state

Особенно быстро устаревают:

  • money movement packets;
  • external communication drafts;
  • browser action confirmations;
  • policy exceptions;
  • evidence-dependent commits.

Чем динамичнее контекст, тем короче должен быть valid window.

2. Time-based expiry недостаточен без payload binding

Даже в пределах одной минуты approval уже может быть невалиден, если изменились:

  • amount;
  • recipient;
  • attachment;
  • target entity;
  • evidence pack;
  • risk flags.
Если packet нельзя однозначно связать с payload hash и reviewed evidence, у него почти всегда слишком широкий срок жизни.

3. Expiry должен быть route-aware

Например:

  • low-risk content publish может жить дольше;
  • external send — заметно меньше;
  • browser submit — почти мгновенно;
  • stale evidence action — только one-shot.

Одна TTL на все approvals обычно слишком груба.

4. Expired approval должен менять orchestration

Полезные варианты:

  • request fresh review;
  • rebuild evidence pack;
  • downgrade action to draft;
  • route into manual mode;
  • hard-block execution.

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

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

No expiry at all

Approval живёт почти бесконечно.

Time-only expiry

Payload drift не учитывается.

Invisible expiration

UI не показывает, что approval уже stale.

Re-using packet across actions

Одно согласование начинает покрывать слишком много.

No evidence revalidation

Packet жив, хотя support path уже изменился.

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

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

  • expired-packet execution attempts;
  • re-approval rate by action class;
  • approvals invalidated by payload drift;
  • average approval age at execution;
  • blocked risky actions due to stale packet;
  • incidents caused by reused approvals.

Плюсы

  • Expiry снижает риск коммита на устаревшем human approval
  • Payload-bound approval делает gate точнее
  • Route-aware TTL лучше отражает реальную динамику risk classes
  • Помогает ловить slow-review и stale-evidence проблемы

Минусы

  • Нужно поддерживать payload hashes и invalidation logic
  • Слишком короткий TTL может раздражать reviewers
  • Частые re-approvals увеличивают friction
  • Без хорошего UI expiry выглядит как случайная блокировка

Пример approval packet с expiry

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

Простой expiry check

def approval_valid(packet, action, now):
    if now > packet["expires_at"]:
        return False
    if packet["payload_hash"] != action["payload_hash"]:
        return False
    return True

Практический совет: approval packet должен стареть не "по ощущениям", а по чёткой связке между временем, payload и reviewed evidence.

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

1. Почему approval packet не должен жить слишком долго?

2. Что особенно важно проверять помимо времени?

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. OpenAI API Docs - Evaluation best practices
Предыдущая
Approval Fatigue Management в 2026: как не превратить human-in-the-loop в конвейер без внимания
Следующая
Approval Packets в 2026: что именно показывать человеку перед risky action