Gobernanza sobre Claude Code, Codex, OpenCode y Hermes
El control de seguridad y gobierno de tus agentes de IA
Safent se sitúa sobre tus runtimes sin sustituirlos. Gobierna lo que pasa a través de él con una sola autoridad, permisos vigentes por acción y evidencia escrita antes del efecto. Lo que cada runtime hace con sus herramientas propias sigue siendo del runtime: se observa, no se frena. Hablamos claro porque lo prometido es exactamente lo que ocurre.
- Evidencia antes del efecto
- Una sola autoridad
- Cero credenciales ajenas en la pila
Tus agentes ya trabajan con acceso real
Ese acceso no se ha convertido en control. Los tres problemas que Safent resuelve no son nuevos: son los que cualquier auditoría señala.
Accesos sin mapa
La misma cuenta de correo, la misma terminal y el mismo expediente, repartidos entre cinco herramientas con permisos heredados. Nadie puede responder hoy qué agente puede hacer qué, y desde dónde.
Autoridad prestada
Un correo o una página que el agente lee no debería poder ordenarle nada. Sin una frontera que sepaje dato y mandato, una inyección remite a una acción real.
Sin reconstrucción
Cuando algo sale mal no hay registro fiable: qué pasó, con qué versión, bajo qué permiso, y qué quedó pendiente. La evidencia llega cuando ya no sirve.
Cómo funciona
1
Gobierna, no reemplaza
Una consola central es la única autoridad: identidad, permisos, sesiones y tareas. Los CLI conectan por MCP remoto como conectarían cualquier MCP; su configuración, su modelo y sus claves siguen donde siempre están: en su host. Ninguna línea de seguridad reescribe sus funciones.
Abrir mapa de confianza →2
Evidencia antes del efecto
Nada que Safent gobierna ocurre sin dejar prueba. Primero se escribe el registro con el hash exacto de la acción y el permiso vigente; después, si algo falla en el camino, el efecto no se ejecuta. La aprobación vale una vez, para esa acción, con esa caducidad.
Ver la secuencia completa →3
Conectores: solo si tú quieres
Cada empleado puede conectar Gmail o su calendario desde una app aislada, fuera del núcleo. El empleado hace el OAuth, la cuenta queda ligada a su empresa y a su conversación, y el token no pasa jamás por el hub ni por los perfiles del CLI. Sin configurar, se dice que no hay conexión: estado real, sin ficciones.
Ver el flujo del empleado →Lo prometido, en voz baja
Todo lo que pasa por Safent tiene sus garantías: aprobaciones exactas, evidencia encadenada, fallo cerrado. Lo que un runtime hace con sus propias herramientas se observa, no se impide. Si quieres impedirlo existe una capa aparte, el suelo de sistema safent-cage, que solo habla con el kernel y jamás toca la configuración del runtime. Dos productos, una verdad.
Seguridad, escrita en condiciones, no en promesas
Estas no son características del producto: son invariantes del sistema, con prueba automática detrás.
Cero credenciales ajenas
Nada en la pila de Safent guarda una clave de proveedor, un token ni una API: ni la consola, ni el hub, ni la puerta. La credencial del modelo vive donde siempre vivió: en el host del runtime. La única excepción es optativa y está aislada (D25).
Lo aprobado es exacto
Cada aprobación queda atada al hash canónico de la acción. Se ejecuta tal cual, una sola vez, antes de que caduque. Si cambia un solo byte, hace falta otra aprobación. No existe el "más o menos parecido".
Evidencia antes del efecto
Sin evidencia, no hay efecto. El registro se escribe primero, es una cadena verificable y no puede borrarse sin romperse. La auditoría no es un informe posterior: es el orden del sistema.
El contenido no manda
Un correo, una web o un archivo leído son datos, nunca autoridad. Un efecto ordenado desde contenido externo se retiene; un runtime con sesión ligada no puede elegir su procedencia. La inyección por lectura no llega a consecuencia.
Conectores en un broker aislado
Los conectores viven en un servicio aparte, habilitado tú, donde solo hay una credencial del proyecto. Ni central, ni hub, ni perfiles del CLI la reciben. Cada OAuth, cuenta y herramienta queda ligada a empresa, trabajador y conversación, con listas positivas explícitas.
El suelo es opcional y honesto
Si se ejecuta sin Cage, el sistema lo declara: sin protección de kernel, sin excusas. Si se ejecuta con Cage, este solo aplica política del sistema operativo, nunca la configuración ni el login del runtime. La política kernel no interfiere con la de negocio, y viceversa.
Enterprise en una sola VM. Un clic.
El piloto cabe en una máquina: Caddy con TLS firmado, la consola atada a loopback y ejecutores locales con perfiles por trabajador. El instalador del empleado lleva dentro su código de alta y nadie tiene que abrir una terminal. El mismo código, el mismo contrato y la misma autoridad que en el piloto, con la puerta cerrada por contrato hacia afuera.
- TLS con Let's Encrypt, sin puertos innecesarios
- Instalador con código de alta, sin terminal para el empleado
- Ejecución nativa sin requisito de Cage, declarada como tal
- SSH siempre de lectura, sin excepciones para administradores
El provisionador está en preparación. Mientras tanto, el despliegue del piloto se documenta en deploy/enterprise-public.
Dónde encaja hoy
Safent no pide cambiar el equipo: pide gobernarlo.
Runtimes admitidos, por MCP nativo
- Claude Code
- Codex
- OpenCode
- Hermes
Aplicaciones por broker aislado, con OAuth del empleado
- Gmail
- Google Calendar
SSH es siempre lectura: sin shell remoto, sin escritura, sin canal de ejecución. Ninguna capacidad se anuncia si no está probada en la versión instalada.
Del piloto de una VM a la escala, sin cambiar el modelo
Piloto · una VM
- Caddy + TLS, una empresa, una VM, verificable
- Runtimes locales con perfiles SO aislados por trabajador
- Sin SSO en v1; bootstrap una sola vez, luego administración normal
Escala · clientes, broker y autoridad
- La misma autoridad, ahora con Postgres como verdad
- Los ejecutores pasan a las máquinas del cliente: conexión de salida, jamás de entrada
- El broker pasa a SaaS aislado; ni por eso tiene más permisos
Preguntas honestas
¿Safent le pregunta al agente por cada acción?
No. Safent nunca interrumpe al runtime pidiendo permiso para sus decisiones propias. Solo se retiene lo que pasa por su autoridad, lo que toca el mundo físico o lo irreversible. Es gobernar, no vigilar microgestualmente.
¿Se van mis claves por algún sitio?
No. Las credenciales del modelo y de las apps de cada runtime no entran en el hub ni en la consola. El único token que vive fuera es el del broker de conectores, y solo si lo activas, en un servicio aislado del núcleo.
¿Qué llega a la consola desde mi máquina, en local?
Solo la lista cerrada de Actividad: identificadores, códigos, recuentos, horas y enlaces de cadena con clave local. Nada permite a quien no tenga tu ordenador comprobar una suposición sobre su contenido. La consola no puede leer, ejecutar, traer ni abrir nada en tu ordenador.
¿Cage tiene algo que ver con la parte de negocio?
No, y esa es la idea. MCP y Cage son productos independientes que nunca se comunican. Cage solo permite o deniega a nivel de kernel. La autoridad de negocio autoriza cada herramienta. La seguridad no depende de un solo lado.
¿Qué pasa si Safent no responde?
Fallo cerrado: lo que Safent gobierna no se ejecuta. Tus agentes no dependen de Safent para funcionar, así que sus tareas propias siguen. Esa separación es la que hace que la capa sea aceptable, no el heroico uptime.
¿Todo esto vale igual en modo alojado?
El modo alojado solo cambia qué contenido entra: el que el trabajador envía a su espacio, más el conocimiento de empresa. I1, I3, I5, I7, el broker aislado y el SSH de lectura no cambian. El modo local con su lista cerrada de salida, tampoco.