Qué significan los términos
Toda comprobación que forma parte de una ruta de solicitud puede no llegar a producir una respuesta: una dependencia agota el tiempo de espera, falta una señal, no se puede recuperar una clave. Fail open significa que la solicitud continúa como si la comprobación no existiera. Fail closed significa que la solicitud toma la ruta más estricta: se deniega, se desafía o se envía a un control más fuerte ya existente.
Ninguno es correcto en general. La elección adecuada depende de qué hace la ruta y de cuánto cuesta una decisión incorrecta.
Por qué importa en las comprobaciones de actor
Las comprobaciones de actor añaden contexto a las solicitudes: si la interacción parece humana, asistida por IA, dirigida por un agente o desconocida. Cuando ese contexto no está disponible, la aplicación aun así tiene que responder. Son comunes dos patrones de fallo:
- Fail closed accidental. Un timeout o una señal faltante se trata como sospechoso, y los usuarios reales quedan bloqueados durante una incidencia.
- Fail open accidental en acciones sensibles. Un resultado faltante se trata en silencio como humano, y una acción de alto impacto continúa con menos revisión de la prevista.
Ambos surgen de dejar la decisión implícita. La solución es decidirla explícitamente, por ruta. Nuestro artículo sobre diseñar políticas a nivel de aplicación para humanos y agentes de IA muestra cómo el comportamiento ante fallos encaja en una política por ruta.
Cómo elegir
Un enfoque práctico es agrupar las rutas por niveles de riesgo:
- Bajo impacto (páginas públicas, documentación, rutas de catálogo de solo lectura): fail open. Un resultado de actor faltante no debería cambiar nada.
- Impacto medio (registros, envíos de formularios, búsquedas con coste): normalmente fail open con registro, o aplicar una adaptación suave como un límite de tasa estándar.
- Alto impacto (cambios de cuenta, exportaciones de datos, acciones irreversibles): fail closed hacia tu control más fuerte ya existente, como reautenticación o confirmación. La idea no es bloquear, sino recurrir a la comprobación que usarías de todos modos.
Después define el mismo comportamiento para casos relacionados:
- Timeout: la comprobación no respondió a tiempo.
- Telemetría faltante: la integración no se ejecutó o faltó una señal.
- Unknown: la comprobación se ejecutó, pero la evidencia no permitió una determinación.
- Evidencia obsoleta: el resultado es anterior y no debe reutilizarse para una acción más sensible.
Ideas equivocadas comunes
- "Fail closed es más seguro." Traslada el coste a los usuarios legítimos. En rutas de bajo impacto, fallar cerrado durante una incidencia puede causar más daño que el riesgo que evita.
- "Unknown es un fallo." Unknown es un resultado válido. Merece su propio manejo explícito, que puede coincidir o no con tu manejo de timeout.
- "Un resultado faltante significa humano." Nunca infieras una clase de actor por la ausencia de evidencia.
Cómo lo trata Proof of Actor
Proof of Actor nunca asigna Human a un timeout ni a un resultado Unknown, e instalarlo no bloquea nada: los equipos empiezan en modo de observación. El comportamiento fail-open o fail-closed para cada ruta y nivel de riesgo es una decisión del propietario de la aplicación, aplicada en tu propio código mediante Route. Eso mantiene la aplicación de políticas predecible y te permite comprobar resultados antes de que cualquier política entre en vigor.
Lee cómo encajan las decisiones de routing, o solicita acceso anticipado.