El modelo sigue el principio de defensa en profundidad: la seguridad no descansa en una sola barrera, sino en controles independientes que se aplican en distintos puntos de la operación. Identidad, sesión, contexto, ejecución, herramienta, credencial y sistema externo limitan aspectos diferentes; superar una comprobación no desactiva las siguientes.
Este enfoque reduce el impacto de un error aislado. Si una instrucción es ambigua, una entrada supera una primera validación o una integración está configurada con más alcance del necesario, los demás límites todavía pueden rechazar la operación o contener su efecto. El valor no está en prometer que una capa nunca fallará, sino en evitar que un único fallo sea suficiente para cruzar todos los límites.
Aislamiento y permisos explica esos límites; Datos, identidad y secretos documenta cómo se separan información y credenciales; e Infraestructura y deployment describe cómo se controlan los cambios. Esta sección reúne esas piezas para mostrar cómo se toma y se verifica una decisión sensible de extremo a extremo.
De una intención a una operación autorizada
Una solicitud comienza como una intención expresada en lenguaje natural, no como una orden con permisos implícitos. El modelo interpreta qué quiere lograr la persona y puede proponer una operación; a partir de ahí, la plataforma transforma esa propuesta en una secuencia verificable. Primero establece quién origina la solicitud y qué contexto puede usar. Después comprueba que exista una capacidad habilitada, que los parámetros cumplan su contrato y que la cuenta externa tenga el alcance necesario. Finalmente exige aprobación cuando corresponde y solo comunica éxito si el sistema de destino confirma el efecto.
Cada etapa responde una pregunta distinta y puede detener el flujo sin depender del criterio del modelo. Así, una intención útil puede convertirse en una acción segura, mientras una solicitud inválida, fuera de alcance o incompleta termina en un rechazo explícito antes de producir un cambio.
Ejemplo. Una persona solicita por Slack exportar todos los contactos del CRM. El agente puede entender la intención, pero la operación se detiene si esa identidad solo tiene acceso a su cartera, si la herramienta no admite exportación masiva o si falta una aprobación. Escribir “soy administrador” en el mensaje no cambia la cuenta, el alcance ni las capacidades disponibles.
Del riesgo al control
En lugar de repetir cada capa de la plataforma, agrupamos los controles por el riesgo concreto que reducen y por el punto en que detienen una operación.
| Riesgo | Control decisivo | Resultado |
|---|---|---|
| Cruce entre clientes, agentes o sesiones | VPS dedicada por cliente, identidad derivada del enrutamiento, sesiones y workspaces separados. | La solicitud solo puede recuperar contexto y capacidades del destino resuelto. |
| Contenido externo que intenta dar instrucciones | Mensajes, documentos y resultados se tratan como datos; las políticas y permisos viven fuera del contenido procesado. | El contenido no puede cambiar identidad, habilitar herramientas ni ampliar permisos. |
| Acción ambigua o no autorizada | Herramientas explícitas, esquemas cerrados, separación entre lectura y escritura y aprobaciones. | La operación se rechaza antes de producir un efecto externo. |
| Exposición o uso indebido de credenciales | Secretos por referencia, autorización separada, acceso acotado y registros sin valores sensibles. | El modelo recibe resultados de la operación, no credenciales durables. |
| Cambio defectuoso o versión inesperada | Control de versiones, revisión, validación, deployment identificable y comprobaciones de salud. | La versión activa puede verificarse y, si falla, existe una ruta de rollback. |
Cómo verificamos los controles
No verificamos la seguridad solamente con el caso exitoso. Cada familia de controles incluye comprobaciones positivas, denegaciones esperadas y evidencia suficiente para distinguir una política activa de una afirmación escrita.
- Configuración y contratos
El build valida la estructura de la configuración, las referencias requeridas y los contratos de herramientas. Las pruebas comprueban campos obligatorios, tipos, operaciones admitidas y combinaciones que deben rechazarse antes de llamar a una integración.
- Identidad y aislamiento
Probamos que una ruta válida llegue al agente y la sesión correctos, y que identidades, workspaces o recursos fuera del límite esperado no puedan recuperarse. Los casos negativos importan tanto como el acceso permitido: una denegación correcta demuestra que el límite está activo.
- Permisos y operaciones sensibles
Ejecutamos escenarios de lectura, escritura, falta de alcance y aprobación pendiente. Verificamos que la herramienta derive la cuenta autorizada, valide los parámetros, preserve la separación entre lectura y escritura y devuelva un estado explícito sin ampliar permisos.
- Verificación posterior al deployment
Comprobamos que la revisión prevista esté activa, que los servicios respondan a sus señales de salud y que un recorrido representativo atraviese el camino crítico. Si una comprobación falla, el deployment no se considera terminado y conserva una ruta definida hacia la versión anterior.