Seguridad

La seguridad es el núcleo del producto, no una función más. El objetivo de diseño es concreto: el agente, la pieza en la que menos se confía, hace trabajo útil sin tener nunca un secreto, sin salir de su copia de trabajo y sin tocar la red directamente. Esta página resume las garantías que necesitas evaluar antes de aprobar Chronos en tu organización.

Las cinco garantías

Garantía	Qué significa
Credenciales aisladas	El agente nunca ve un secreto ni un endpoint real
Sandbox por sesión	Sistema de ficheros y red acotados a cada sesión
Catálogo firmado	Solo corre lo que la organización aprobó, verificado con Ed25519
Puertas de aprobación	Las operaciones destructivas y el merge exigen aprobación
Auditoría inmutable	Registro append-only de todo, sin secretos

Credenciales: el agente nunca las ve

Todas las conexiones aprobadas pasan por un proxy local en la máquina del desarrollador. El agente solo conoce una dirección 127.0.0.1 y un token propio de su sesión; el proxy valida ese token en cada llamada, pide al panel una credencial de corta duración, la inyecta y reenvía la petición al servicio real.

• El secreto nunca entra en el entorno, la configuración, los prompts ni la salida del agente.
• Nunca se escribe en el repositorio ni en los logs: los valores se redactan antes de escribir nada.
• Los secretos que viven en la máquina van al llavero del sistema operativo, nunca en claro en disco.
• El proxy escucha solo en loopback y valida el token en cada llamada: ningún otro proceso local puede usarlo.

El detalle por conector (Figma, Replicate, AWS con rol cross-account) está en Conectores y credenciales.

Sandbox por sesión

Cada sesión corre aislada con los mecanismos nativos de cada sistema operativo:

• Ficheros: el agente solo ve su propia copia de trabajo. Ni otras sesiones, ni el resto del disco.
• Red: la salida sigue una lista de permitidos. Los endpoints reales solo los alcanza la plataforma; el agente no llega a ellos aunque conozca la URL.
• Terminal: la terminal de sesión corre dentro del mismo sandbox y cada comando queda auditado.

Catálogo firmado: se verifica antes de confiar

El panel de empresa es la única fuente de qué herramientas, contexto y capacidades existen. Cada paquete va firmado con Ed25519: el panel firma con una clave privada que nunca sale del servidor y cada equipo verifica con la clave pública fijada al aprobar el dispositivo. Quien puede verificar no puede falsificar.

• Un paquete sin firma, con firma inválida o de una clave desconocida se rechaza. Nunca se degrada en silencio y el fallo queda auditado.
• Nadie puede añadir conexiones en local: fuera del catálogo no hay nada alcanzable.
• La rotación de claves no rompe las sesiones vivas: las claves anteriores se conservan en el conjunto de confianza.
• Una conexión que requiere credencial y no la tiene se descarta en cerrado. No se materializa a medias.
• La política se resuelve dos veces, en el panel y en el cliente, sobre el mismo paquete firmado: defensa en profundidad.

Puertas de aprobación

Las operaciones destructivas (push forzado, borrado masivo, instalaciones de red, scripts arbitrarios) exigen aprobación explícita. El merge final lo aprueba siempre una persona o un agente certificador y solo procede por política: checks en verde, aprobaciones requeridas presentes y un actor con permiso pr.merge.

La app nunca es la única barrera

Chronos es la fuente de verdad de los roles, pero asume la protección de ramas de tu proveedor de git como respaldo. La política de merge se apoya en ambas capas, nunca solo en la aplicación.

Auditoría inmutable

Cada prompt, llamada a herramienta, comando, cambio, uso de conexión y aprobación queda registrado de forma inmutable, con su autor. Las entradas no se editan ni se borran. Los fallos también entran: un paquete rechazado por firma inválida queda registrado. Y el registro nunca contiene secretos: dice qué herramienta se usó, no el token. Detalle en Auditoría.

Fronteras de equipo y memoria

La memoria de sesión se queda en local y entra en la auditoría. Lo que sobrevive a una sesión (skills destiladas, aprendizajes) se escribe solo con aprobación explícita, nunca de forma silenciosa. Y respeta las fronteras de equipo: el contexto y las skills de un equipo nunca se materializan para otro.

Transporte y postura ante errores

Todo el tráfico con el panel va sobre TLS. Y una regla transversal: los errores de firma, sandbox o auditoría nunca se silencian para que algo "siga funcionando". Internamente una violación de estas reglas se trata como un bug de severidad alta.

Para evaluar el despliegue en tu infraestructura: Despliegue. Para el modelo de control central: Qué gobierna el panel.