# La seguridad acompaña cada operación.

> Cómo RunMyDay convierte una intención del modelo en una operación identificada, autorizada, validada y verificable.

Fuente: https://runmyday.ai/docs/technical/security/

Una respuesta del modelo no obtiene autoridad por estar bien redactada. Identidad, capacidad, datos, credenciales y efectos se comprueban fuera del razonamiento antes de producir una acción.

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](https://runmyday.ai/docs/technical/isolation-and-permissions/) explica esos límites; [Datos, identidad y secretos](https://runmyday.ai/docs/technical/data-and-secrets/) documenta cómo se separan información y credenciales; e [Infraestructura y deployment](https://runmyday.ai/docs/technical/infrastructure-and-delivery/) 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.

_Diagrama: Seguridad en capas. Siete capas complementarias protegen identidad, red, sesiones, ejecución, herramientas, datos y cambios._

La defensa en profundidad acumula límites complementarios alrededor de una operación.

## 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.

_Diagrama: Flujo de autorización de una operación. Una solicitud atraviesa siete decisiones: origen e identidad, contexto mínimo, capacidad habilitada, entrada válida, autorización efectiva, aprobación cuando corresponde y resultado confirmado._

La autorización avanza por decisiones independientes. Si una condición falla, la operación no continúa hacia el siguiente efecto.

**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.

1. **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.
2. **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.
3. **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.
4. **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.