Arquitectura y seguridad¶
Guía de aplicación vigente basada en ASILO 0.1. No fija tecnología, número de anillos ni garantía de seguridad.
Documenta dónde se propone una acción, dónde se autoriza y dónde produce un efecto. Una regla en Markdown orienta; el control efectivo necesita evidencia en el sistema que ejecuta.
Dibuja las fronteras antes que los anillos¶
Identifica entradas no confiables, lógica interna, permisos, datos y puntos de efecto. Declara qué módulo depende de cuál y quién posee cada frontera. Después elige el modelo de capas apropiado, con su perfil de origen.
ASILO-R-002 pide declarar ese modelo y su dirección de dependencias; no exige un número ni una numeración universal. Según ASILO-R-002, la comprobación automática de la regla de dependencia es una recomendación cuando el perfil lo permite. El perfil ASILO para TypeScript sigue en preparación y su numeración de anillos sigue abierta. No lo conviertas en el único modelo de arquitectura.
Distingue cuatro preguntas¶
| Pregunta | Qué se comprueba | Regla |
|---|---|---|
| ¿La propuesta tiene una forma válida? | Contrato de entrada/salida versionado. | ASILO-R-001. |
| ¿Se permite esa acción? | Autorización en el punto de efecto. | ASILO-R-001 y ASILO-R-004. |
| ¿Quién puede detenerla o revocar al agente? | Alcance, revocación y parada probada. | ASILO-R-004 y ASILO-R-007. |
| ¿Requiere decisión humana previa? | Catálogo de efectos críticos y aprobación específica. | ASILO-R-005. |
Una salida válida no prueba veracidad ni autorización. Un identificador no demuestra identidad verificada. Un diagrama no demuestra que exista el control dibujado.
Declara el alcance de cada agente¶
Registra identidad, operaciones y datos permitidos, límite de acciones y profundidad de delegación antes de operar. El alcance no supera al de quien lo invoca ni se amplía en ejecución. ASILO-R-004 exige poder revocar y recomienda comprobar la revocación antes de cada acción. Dentro de un alcance legítimo puede seguir ocurriendo daño.
La identidad humana, sus permisos de aplicación y la identidad de un agente no son lo mismo. La metodología no prescribe cuentas, directorios, protocolos de firma ni algoritmos criptográficos. Documenta qué persona tiene autoridad sobre el objeto concreto; el mecanismo de verificación pertenece al perfil y a la implementación que se evalúan.
Revisión humana donde importa¶
El catálogo mínimo de ASILO-R-005 considera pagos, borrados, cambios de permisos, publicación o envío a terceros y decisiones que afectan a personas. La revisión muestra el objeto exacto antes del efecto y registra identidad, fecha y aprobación no reutilizable. No implica pedir confirmación para toda lectura o cada respuesta. La excepción de emergencia necesita definición previa del owner y revisión posterior registrada.
Cuando las reglas no decidan, ASILO-R-005 recomienda que el caso vaya a revisión humana en vez de resolverse con un valor por defecto. No convierte toda incertidumbre en una pausa universal independiente del alcance del requisito.
Límites y continuidad¶
ASILO-R-007 pide límites de costo o tokens, acciones y tiempo, y un mecanismo de parada con responsable definido y probado en el entorno donde se afirma que funciona. La prueba corresponde al mecanismo, no a la persona. Agotar un límite lleva a detener o revisar, no a continuar en silencio. Según ASILO-R-007, al detenerse se conserva el registro de lo ejecutado; permitir reanudar sin repetir efectos ya aplicados es una recomendación.
Cambiar de proveedor, reiniciar o reintentar no elimina el límite ni prueba que una acción no ocurrió. La edición no prescribe fallback automático ni un formato de kill switch. Describe esos mecanismos cuando existan y evalúa sus fallos; no atribuyas al método su implementación.
Siguiente: evaluación y revisión · Artefactos de control
Un plano y sus cerraduras¶
El plano explica cómo se relacionan las zonas; las cerraduras controlan accesos. En software, la arquitectura y la autorización también se comprueban por separado. La guía de seguridad por capas desarrolla esa distinción.