Un agente que puede instalar cualquier cosa, llamar a cualquier servicio y escribir en cualquier lugar solo es seguro si las barreras son reales. En Kortix están por debajo del agente, en la plataforma, donde un prompt no puede convencerlas de abrirse.
Una sesión no es una pestaña en un entorno compartido. Es una máquina propia, y la base de datos no permite que dos sesiones tengan la misma. Separar dos sesiones tuyas usa el mismo mecanismo que separar las sesiones de dos clientes distintos.
dentro de una sesión
nunca entra
Una herramienta necesita una credencial real para hacer trabajo real, así que la pregunta honesta no es si la máquina llega a tener una. Es qué máquina contiene cada clave, quién lo decidió y qué cosas nunca entran.
01
Cifrado con AES-256-GCM mediante una clave derivada por proyecto.
02
Tanto el rol de la persona como el permiso declarado del agente deben autorizarlo.
03
Colocado en la sesión al iniciarse, por nombre, en tmpfs con modo 0600.
04
La herramienta lo lee del entorno. No se escribe en el prompt.
05
El archivo se borra al apagarse y la máquina se destruye con él.
La mayoría de las herramientas de IA dan al agente acceso a todo lo que puede alcanzar la persona que lo inició. Kortix no. La identidad de un agente tiene sus propias políticas, evaluadas de forma independiente, por lo que no puede heredar acceso a algo que nunca le concediste.
principal
tipo de recurso
Los permisos se asignan a un principal, para una acción y sobre un tipo de recurso.
Roles integrados: en todos los planes
account
project
Enterprise
Available on Enterprise, and on a self-hosted instance with an Enterprise license. The built-in roles above are free on every plan.
Una cuenta de servicio es una identidad de máquina de primera clase propiedad de la cuenta, no un token humano disfrazado. Las políticas se le asignan directamente y cada solicitud se evalúa solo contra sus propias políticas: nunca hereda el alcance de quien la creó.
Una persona o un grupo puede limitarse a agentes y skills concretos dentro de un proyecto: marketing puede usar este agente y aquella skill, y nada más. Lo que dejes sin limitar permanece disponible en todo el proyecto, así que restringir es algo que eliges activar.
La aprobación no es un ajuste escondido en un panel de administración. Es un bloque en kortix.yaml, versionado con todo lo demás, que indica qué llamadas de herramientas se ejecutan, cuáles se detienen para que intervenga una persona y cuáles se rechazan directamente.
# reads run; writes and destructive calls stop for a humanpolicy: default_mode: risk policies: # a name-only rule cannot gate the target — conditions can - match: gmail.send_email action: require_approval conditions: - arg: to match: /@example\.com$/ # anything else through this tool is refused outright - match: gmail.send_email action: block # whole connectors can be gated with one glob - match: stripe.* action: require_approvalTres acciones
always_run, require_approval, block. Una regla coincide con un glob sobre rutas de herramientas completamente cualificadas, de modo que una línea puede cubrir una llamada o un conector entero.
Controla el objetivo, no solo la herramienta
“¿Puede el agente enviar emails?” no es una barrera. Las condiciones coinciden con los argumentos, así que la regla puede ser “solo a estas direcciones”. Si un argumento no se puede evaluar, se deniega por defecto.
No existe un “permitir siempre” general
Cada llamada controlada se aprueba por separado, con sus argumentos delante. No hay un permiso para toda la sesión tras el que pueda ocultarse una llamada posterior con argumentos distintos: eliminamos ese atajo en el punto de aplicación, no solo de la interfaz.
Configura el valor predeterminado que quieras
default_mode: risk hace que las lecturas se ejecuten y que los envíos, escrituras y llamadas destructivas requieran una persona. Un proyecto sin bloque de políticas conserva el valor permisivo heredado, así que configúralo explícitamente.
Un agente puede escribir todo lo que quiera en su propia rama. Llevar ese trabajo a main es una capacidad independiente que no tiene a menos que se le conceda deliberadamente; y concederla también es un cambio que alguien debe aprobar.
Cada edición llega a la rama creada para esa sesión. Nada de lo que hace el agente es visible para otra sesión ni para main.
Cuando el agente quiere que algo sobreviva a la máquina, hace commit y abre una solicitud de cambios dirigida a main. Esa es la única puerta.
Una solicitud de cambios es un diff. Un agente que reescribe su propio prompt se revisa igual que un cambio de código, porque lo es. Una solicitud cuyo manifiesto no valida no puede fusionarse.
Fusionar es una capacidad propia, denegada a todos los agentes salvo que un administrador la conceda. Ese permiso vive en kortix.yaml, así que un agente no puede ampliar su alcance sin una solicitud de cambios aprobada por otra persona.
Cada acción de cuenta y cada acción de agente se registra en todos los planes. El plan decide quién puede leer, exportar o transmitir ese registro, no si existe.
El mismo producto se ofrece como cloud gestionado, como stack dentro de tu propia red y como despliegue aislado. Es open source, así que en última instancia confías en código que puedes leer.
El servicio gestionado. Nosotros ejecutamos el plano de control y el cómputo; tú diriges la empresa.
Un stack de Docker Compose en tu equipo, con las mismas imágenes que ejecuta el cloud gestionado. Tu base de datos y tus archivos están en discos que controlas.
A single-tenant deployment inside your own network. Isolated topologies are scoped with us rather than self-served.
Dónde estamos realmente
No contamos con ISO 27001 ni HIPAA, y no insinuamos lo contrario. Cuando llegue un informe, esta línea cambiará ese mismo día y no antes.
No abras un issue público sobre una vulnerabilidad. Escribe al contacto de seguridad con la versión o el commit afectado, la reproducción y el impacto.
contacto de seguridad
security@kortix.comDamos crédito a los informantes que lo desean, una vez publicado el arreglo.
Empieza con una tarea y crece desde ahí.