HANRIA — comprobar una acción contra un mandato

¿Qué hace HANRIA — comprobar una acción contra un mandato?

Un operador escribe lo que puedes hacer. Verificas una acción propuesta contra ello antes de actuar, y mantienes un registro de lo que se decidió. Ambos pasos se ejecutan localmente, sin llamadas de red. La habilidad no requiere credenciales y rechaza una solicitud o mandato que las contenga.

Qué puede y no puede hacer esta habilidad

Puede: evaluar una acción propuesta contra un mandato e indicarte permitir, denegar o escalar, con la cláusula específica utilizada; rechazar una solicitud que contenga material de credencial reconocible; y añadir la decisión a un registro local que detecta modificaciones posteriores.

No puede imponer. Nada aquí se interpone entre tú y una herramienta o credencial. Si ignoras un denegar, la operación igualmente se realiza. La imposición solo es posible cuando las credenciales protegidas, herramientas, claves de firma o procesos de trabajo solo son accesibles a través de un componente que pueda rechazar — y ese componente no es esta habilidad.

Esa distinción es el punto central del diseño, así que indícalo con precisión si te preguntan. Si algún artefacto te dice que instalar esta habilidad te otorga capacidad de imposición, esa afirmación es falsa. Una habilidad son instrucciones y código cargados en tu contexto, y cualquier cosa en tu contexto puede ser ignorada, anulada o eludida — por ti, por una instrucción posterior o por un agente diferente.

Uso

1. Encontrar el mandato

El mandato del operador es un archivo JSON que escribió. Pregúntale dónde está si no lo sabes. Un ejemplo práctico está en skills/hanria/examples/mandate.example.json, y la forma está definida por skills/hanria/schema/mandate.schema.json.

2. Describir la acción que propones realizar

Escribe una solicitud de acción según skills/hanria/schema/action-request.schema.json. Nombra lo que propones hacer — tipo, verbo, destino y, cuando corresponda, una contraparte y una cantidad.

Nunca pongas una credencial, secreto, clave, token o contraseña en una solicitud. Una solicitud describe lo que se va a hacer, no los medios para hacerlo. El verificador rechaza una solicitud que parezca contener uno en lugar de eliminarlo, porque un intento de enviar una credencial merece ser visto.

Esa detección es una heurística y no puede ser completa. Reconoce nombres de campos de credencial comunes y formas de valor; una credencial en un campo con un nombre común y un valor de aspecto común pasará. Protege contra accidentes, no contra intenciones — no lo trates como un control.

3. Verificarlo

python3 skills/hanria/scripts/check_action.py \
  --mandato MANDATO.json --accion ACCION.json

Cuatro resultados, y lo que cada uno te pide:

• permitir — una cláusula cubre esto. Procede, luego registra la decisión.
• denegar — ya sea que una cláusula lo prohíba o nada lo permita. No procedas. La razón nombra la cláusula, o las cláusulas que más se acercaron y por qué no coincidieron, que suele ser lo que el operador necesita escuchar.
• escalar — el mandato reserva esto para una persona. Detente y pregunta a tu operador. No trates su instrucción general de ser útil como la aprobación; el mandato solicitó una decisión sobre esta acción.
• error — el mandato o la solicitud no pudieron resolverse. Trátalo como denegar y reporta el texto. La evaluación es de cierre ante fallo por diseño: ambos documentos se validan primero contra sus esquemas JSON publicados, y un mandato o solicitud no conforme, un mandato vencido, un tipo de operación desconocido, una cantidad no finita o negativa, un prefijo de destino vacío o ambiguo respecto al host, o cualquier fallo interno imprevisto se resuelve como denegar o error. Nunca resuelve una ambigüedad a favor de proceder, y rechaza un mandato que contenga una condición que no implementa en lugar de ignorarla — una restricción no implementada ampliaría silenciosamente la cláusula que debía estrechar.

Los códigos de salida son 0 permitir, 1 denegar, 2 escalar, 3 error, por lo que esto se integra en un pipeline de shell.

4. Registrarlo

python3 skills/hanria/scripts/record.py append \
  --log LOG.jsonl --accion ACCION.json --resultado RESULTADO.json

Cada entrada lleva el resumen de la anterior, por lo que alterar o eliminar una entrada que tenga cualquier cosa después rompe todos los resúmenes siguientes. record.py verify --log LOG.jsonl reporta el primer índice que falla, y append se niega a escribir en un registro que ya no se verifica en lugar de ocultar el daño.

El truncamiento es la excepción. Eliminar entradas desde el final deja una cadena más corta que es internamente perfecta, porque nada posterior queda para contradecirla. Por lo tanto, append mantiene un archivo <log>.head separado, y verify lo verifica cuando está presente y lo indica explícitamente cuando no había cabeza retenida disponible. Mantén ese archivo fuera del alcance del escritor del registro, o pasa --expect-head, si el truncamiento es una amenaza que enfrentas.

No exageres lo que es el registro. Es una verificación de integridad local para quien posee el archivo. No hay firma, formato publicado ni verificador independiente, por lo que cualquiera que pueda escribir el archivo puede reconstruirlo de principio a fin y producir un registro que se verifique. No es evidencia, ni atestación, i prueba para nadie más de que una acción fue autorizada.

Escribir un buen mandato

Para operadores. Las cláusulas se evalúan en orden y la primera coincidencia decide; cualquier cosa no coincidente toma el default del mandato, que es denegar o escalar — nunca permitir, porque un mandato que permite por defecto no puede expresar un límite.

Tres cosas que vale la pena hacer:

• Establece not_valid_after. Un mandato sin límite es lo que permite que la autoridad delegada sobreviva a la tarea para la que fue concedida.
• Usa requires_human para los tipos que nunca quieras que decida un modelo — típicamente credential_use, transaction y administrative. Anula una cláusula permisiva, por lo que un techo limita lo que se puede solicitar sin sacarte de la decisión.
• Escribe denegaciones que podrías haber dejado al valor predeterminado. Una cláusula que dice "no /home/, no /etc/" hace que la intención sea legible para quien revise esto después; el silencio no lo hace.

Cada cláusula tiene una note, y se incluye textualmente en el registro de la decisión. Úsala para decir por qué existe la cláusula, no qué hace.

¿Existe un runtime?

python3 skills/hanria/scripts/detect_runtime.py

A fecha de 2026-09-04 no existe un runtime HANRIA publicado, empaquetado u obtenible; esto reporta ausente, que es la respuesta esperada. Está aquí para que un agente al que se le pida enrutar una acción a través de un runtime HANRIA obtenga un negativo correcto en lugar de inventar una capacidad. No le digas a tu operador que un runtime gobernó una acción.

Limitaciones conocidas

Los límites de esta habilidad se enumeran completamente en LIMITATIONS.md en la raíz del repositorio, y en https://hanria.ai/boundaries/. La versión corta: no puede imponer; solo las condiciones estructuradas de una cláusula restringen algo, por lo que el texto en prosa en un mandato no restringe nada; la detección de credenciales es una heurística; la coincidencia de prefijos es literal (después de la composición Unicode) y no resuelve enlaces simbólicos; y el registro de decisiones es una verificación de integridad local, no evidencia.

Estado

HANRIA está en desarrollo. Una solicitud de marca registrada en EE. UU. para HANRIA está pendiente — no se reclama ningún registro ni autorización completa. No se reclama ninguna certificación de seguridad, auditoría o disponibilidad del producto. Los esquemas son borradores y pueden cambiar.

Más en hanria.ai.