AN-05 L1 Nivel de conformidad: Authority Grupo: Autoridad

Human Gate compuerta humana

Aparece solo antes de acciones irreversibles, hacia el exterior o que elevan privilegios, y muestra el diff real.

Definición

Una Human Gate es un punto de control activado por la política: antes de que surta efecto una acción irreversible, hacia el exterior o que eleve privilegios, una persona (o un aprobador designado) aprueba una acción concreta, totalmente representada. Está pensada para ser infrecuente, específica y difícil de aprobar por inercia.

v0.2 Borrador de especificación Actualizado

El problema

El actual “humano en el bucle” es o un torrente interminable de avisos o nada en absoluto. Anthropic informa de que los usuarios de Claude Code aprueban entre el 93 % y el 97 % de las solicitudes de permiso; en su experimento controlado, las personas detectaron solo el 13,6 % de los comandos peligrosos introducidos a propósito, y lo hicieron peor cuanto más largas eran las sesiones. Es una investigación del proveedor para promover el modo automático, y mide la detección de avisos introducidos a propósito y no las tasas de incidentes en producción, pero la dirección es clara.

Los mismos datos contienen otra cifra: los usuarios rechazan el 39 % de los planes pero solo el 3 % de las solicitudes de permiso individuales. Lo que las personas juzgan en serio son los planes y las fusiones, no cada llamada a una herramienta.

Cómo funciona

  • Aparece en pocos lugares: fusionar en un árbol protegido, borrar de un árbol protegido, compartir o publicar hacia el exterior, enviar datos al exterior (egress), ampliar una concesión y bajar una etiqueta. Las escrituras en una rama no necesitan aprobación.
  • La granularidad es un plan o una fusión. Se revisa un PR, no cincuenta avisos.
  • La Gate Card la genera el NAS: el diff real, un resumen del manifiesto de lectura, la concesión y la contaminación de la sesión, nunca el relato del propio agente. Opciones: aprobar, aprobar acotado, denegar; si se agota el tiempo, se deniega por defecto.
  • Una aprobación queda ligada al digest de la acción: liga el hash del diff y la concesión y no se puede reutilizar.
  • Entrega: push, chat, correo o CLI; se puede delegar; las passkeys son una autenticación fuerte opcional.
  • Solo escalar. Un clasificador de riesgo opcional (incluido un LLM) solo puede escalar una acción a una compuerta y nunca aprobarla. Un modelo solo puede endurecer, nunca aflojar.
  • La fatiga se mide: tasa de aprobación y tiempo hasta aprobar; cuando la tasa de aprobación es inusualmente alta, conviene fusionar compuertas o endurecer la política.

Empezar en pequeño

  • Un main protegido más revisión de PR (vale cualquier plataforma Git) y una notificación push.
  • O una CLI: nas gate approve <gate_id>.
  • Haz que la Gate Card muestre primero el “diff real”; no te apresures con interfaces vistosas.

Esbozo de la interfaz

Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3.

gate-card.json
{
  "gate_id": "gt_2Mx4",
  "run": "run_91ab",
  "action": {
    "op": "merge",
    "from": "cleo/run_91ab",
    "into": "main",
    "files_changed": 4,
    "diff_sha256": "7d2a..."
  },
  "why": "Release notes are ready for review",
  "risk": {
    "session_taint": ["external"],
    "sources": ["web:example.com/changelog"],
    "destructive": false,
    "egress": false
  },
  "options": ["approve", "approve_narrowed", "deny"],
  "default": "deny",
  "expires_at": "2026-11-12T12:00:00Z"
}

Lo que pide la especificación

  • Una Gate Card DEBE mostrar el diff real calculado por el NAS, no la descripción que hace el agente.
  • Una aprobación DEBE quedar ligada al digest de la acción y a la concesión y NO DEBE poder reutilizarse.
  • El resultado por defecto al agotarse el tiempo DEBE ser la denegación.
  • Un clasificador o un LLM NO DEBE conceder la aprobación; PUEDE escalar una acción a una compuerta.
  • Fusionar en un árbol protegido, borrar de un árbol protegido, compartir hacia el exterior, enviar datos al exterior, ampliar una concesión y bajar una etiqueta DEBEN pasar por una compuerta.
  • El NAS DEBERÍA informar de la tasa de aprobación y del tiempo hasta aprobar.

Lo prestado y lo nuevo

Lo que sigue es todo práctica establecida. Lo nuevo: anclar la aprobación en la fusión en la capa de almacenamiento y hacer que el NAS (no el agente) genere el contenido. La aprobación y los PR en sí no son nuevos.

Límites honestos

  • Una persona aún puede aprobar la acción equivocada; la revisión por lotes también causa fatiga.
  • Los canales de notificación pueden ser objeto de phishing.
  • Una aprobación no puede detener algo fuera de lo aprobado; eso es tarea de la concesión.

Preguntas abiertas

  • ¿Cuál es la mejor interfaz para la revisión por lotes y por niveles?
  • ¿Cómo se miden y se ajustan los umbrales de la fusión automática?

Preguntas

¿No es solo otro cuadro de diálogo de “confirmar”?

Deliberadamente no. Un cuadro de diálogo salta en cada llamada a una herramienta y pronto la gente pulsa “aprobar”. Una compuerta aparece solo antes de unas pocas acciones irreversibles o hacia el exterior, muestra el diff real calculado por el NAS, y la aprobación liga el hash del diff: si el diff cambia, la aprobación queda anulada.

¿Puede un LLM decidir si dejar pasar algo?

Puede sugerir que “una persona debería mirar este paso”; no puede aprobar. La decisión de dejar pasar algo debe ser una regla determinista o la aprobación de una persona. Así la seguridad no depende del criterio de ningún modelo.

¿Qué pasa al agotarse el tiempo?

Se deniega por defecto. La ejecución recibe una negativa clara y puede tomar otro camino, o dejar la propuesta en su rama para que una persona se ocupe.

Citar esta página

Direcciones estables y una cita sugerida para personas, buscadores y agentes.

Cita sugerida
Agent NAS project. “Human Gate (compuerta humana).” agentnas.com, 2026-11-11. https://agentnas.com/es/concepts/human-gate/