Что означают эти термины
Любая проверка, стоящая в пути request, может не дать ответа: зависимая система не отвечает вовремя, signal отсутствует, key невозможно получить. Fail open означает, что request продолжает выполняться так, как если бы проверки не было. Fail closed означает, что request идет по более строгому пути: его отклоняют, challenge или отправляют на уже существующий более строгий control.
Ни один из вариантов не является правильным всегда. Верный выбор зависит от того, что делает route и какова цена ошибочного решения.
Почему это важно для проверок actor
Проверки actor добавляют к request контекст: выглядит ли interaction как human, с поддержкой AI, управляемый agent или unknown. Когда этот контекст недоступен, application все равно должна ответить. Обычно встречаются две модели сбоя:
- Случайный fail closed. Таймаут или отсутствующий signal воспринимается как подозрительный, и реальные users блокируются во время сбоя.
- Случайный fail open на чувствительных действиях. Отсутствующий result молча считается human, и действие с высоким impact выполняется с меньшей проверкой, чем предполагалось.
Обе проблемы возникают из-за того, что выбор не задан явно. Исправление состоит в том, чтобы определить его явно, для каждого route. Наша статья о проектировании policy на уровне app для human и AI agents показывает, как поведение при сбоях вписывается в policy по route.
Как выбирать
Практичный подход - разделить routes по уровням риска:
- Низкий impact (public pages, documentation, routes каталога только для чтения): fail open. Отсутствие результата actor не должно ничего менять.
- Средний impact (signups, отправка forms, searches с затратой ресурсов): обычно fail open с logging, либо применять мягкую адаптацию, например стандартный rate-limit.
- Высокий impact (изменения account, exports data, необратимые действия): fail closed на ваш уже существующий более строгий control, например повторную authentication или confirmation. Смысл не в том, чтобы блокировать, а в том, чтобы откатиться к проверке, которую вы все равно использовали бы.
Затем задайте одинаковое поведение для связанных случаев:
- Timeout: проверка не ответила вовремя.
- Missing telemetry: интеграция не сработала или signal отсутствовал.
- Unknown: проверка выполнилась, но evidence не хватило для определения.
- Stale evidence: result получен ранее и не должен повторно использоваться для более чувствительного действия.
Распространенные заблуждения
- "Fail closed безопаснее." Он перекладывает cost на legitimate users. Для routes с низким impact fail closed во время incident может нанести больший ущерб, чем риск, который он предотвращает.
- "Unknown - это failure." Unknown - это допустимый result. Ему нужна собственная явная обработка, которая может совпадать с обработкой timeout, а может и не совпадать.
- "Отсутствие result означает human." Никогда не делайте вывод об actor class только на основании отсутствия evidence.
Как Proof of Actor это учитывает
Proof of Actor никогда не назначает Human для timeout или результата Unknown, а установка не блокирует ничего: команды начинают в режиме наблюдения. Поведение fail open или fail closed для каждого route и уровня риска - это выбор владельца application, который применяется в вашем собственном code через Route. Это делает enforcement предсказуемым и позволяет проверить outcome до того, как policy будет включена в работу.
Читайте как вписываются решения маршрутизации или подайте заявку на ранний доступ.