Seguridad

Última actualización: 6 de agosto de 2026

La seguridad de Mycel se apoya en una idea simple: cuanto menos sepa la plataforma, menos puede perderse. Esta página documenta las medidas concretas, verificables en el código.

Arquitectura: el código nunca viaja

La plataforma orquesta (JSON y WebSockets); tu Nodo ejecuta. Tus archivos no se suben a ningún servidor.
El Nodo se conecta hacia fuera, como un runner de CI: no abres puertos ni expones tu red doméstica.
Por defecto la inferencia es 100 % local (Ollama) y ningún prompt va a APIs de terceros. Si configuras tu Nodo con la clave de un proveedor (OpenAI, Anthropic, DeepSeek, Groq, OpenRouter, Mistral o Together), esos prompts van de tu Nodo al proveedor que tú elijas: nunca pasan por nuestros servidores, y la clave nunca se guarda en la plataforma.

Cuentas y sesiones

Contraseñas con scrypt + sal única por usuario y comparación en tiempo constante.
Sesión en cookie HttpOnly + SameSite=Lax (y Secure en producción); tokens de 256 bits con caducidad de 30 días.
Cambiar la contraseña invalida todas las sesiones abiertas.
Límite de intentos de login/registro por IP (anti fuerza bruta).
Cabeceras X-Frame-Options, nosniff y Referrer-Policy en toda la API.

Nodos y sandbox

Cada Nodo se autentica con un token mcl_… de 144 bits de entropía, ligado a tu cuenta. En la plataforma vive solo su hash (sha-256): el token se muestra una única vez al crearlo o regenerarlo. Puedes borrarlo o regenerarlo desde el panel: el token anterior deja de funcionar al instante y el equipo se desconecta. Además, el token rota solo en cada conexión: el que hay en el equipo del usuario deja de valer en cuanto el Nodo vuelve a emparejarse, así que una copia antigua caduca sola. Si las dos cosas coinciden, manda tu decisión: regenerar aborta la rotación en vuelo, para que un token que acabas de revocar no pueda volver a valer. Y a quien lo intente se le dice el motivo verdadero («se regeneró desde el Panel»), en vez de mandarlo a rehacer el Nodo.
Borrar un Nodo PARA esa máquina. La papelera «Eliminar» de la ficha del Nodo (Panel → Nodos) no solo quita su fila: cierra su conexión al instante, y es lo primero que ocurre tras darlo de baja. Esa máquina deja de recibir órdenes y de ejecutar sus automatizaciones en ese mismo momento, en vez de seguir trabajando hasta que alguien la apagara. Con el Nodo caen sus accesos compartidos, las carpetas concedidas, las asignaciones y el enrutado de los chatbots que servía, para que ningún identificador público quede apuntando a un Nodo fantasma.
Borrar una sesión la borra donde vive. El servidor no guarda el contenido, así que no puede borrarlo: manda la orden a tu Nodo y este elimina en su disco el historial de la sesión y el metadato de su artefacto, y con ellos el acceso a sus ficheros. El apunte del servidor solo cae si el Nodo confirma. Si el Nodo está apagado, desactualizado o la tarea sigue en curso, no se borra nada y se dice el motivo: un borrado fingido es peor que un borrado que no se ha hecho.
Un Nodo solo puede escribir en sesiones de su propietario, y nadie usa tu Nodo salvo que TÚ lo compartas con miembros de tu equipo, con un rol concreto (operador, supervisor o admin) y, si quieres, limitado a carpetas concretas; la plataforma lo verifica en cada mensaje y puedes revocar cada acceso cuando quieras. Ejecutar comandos del sistema es una capacidad separada del rol y viene apagada: quien no la tiene trabaja con las herramientas de archivos, datos, web y ofimática, y su tarea ni siquiera se despacha a un Nodo que no sepa aplicar ese límite. Las cuentas de correo no se reparten con permisos: cada persona conecta las suyas con la contraseña que le hayan dado, y ni la pantalla ni el agente de un compañero las abren. El dueño del Nodo es la excepción declarada, porque la máquina es suya (ver más abajo).
El canal de Nodos limita por IP el número de conexiones y de intentos con token inválido (anti-DoS y anti-fuerza-bruta), aunque adivinar un token de 144 bits ya es inviable.
Las herramientas de archivos del agente están confinadas a su workspace: las rutas se resuelven con protección anti-escape (../ rechazado) y se comprueba además la ruta real, así que un acceso directo (enlace simbólico o junction) creado dentro del área concedida y apuntando fuera no saca ficheros de ella. Los comandos de shell corren con timeout de 120 s, salida limitada y terminación del árbol completo de procesos, con los permisos de tu usuario (ver «El perímetro real»).
Las herramientas de red del agente llevan un guard anti-SSRF: no pueden alcanzar direcciones privadas, localhost ni el metadata endpoint de un proveedor cloud (relevante si tu Nodo corre en un servidor), salvo que tú lo permitas explícitamente al arrancarlo.
Las credenciales que el agente lee de un fichero para usar un conector (p. ej. el token de tu bot de Telegram) se «vaultean»: no aparecen en el timeline ni viajan al proveedor del modelo.
La ejecución de comandos detecta y verifica el intérprete real de cada sistema (cmd.exe/PowerShell en Windows, bash/sh en Unix) y evita lanzadores rotos (p. ej. el «relay» de WSL): si no hay shell utilizable lo explica con un mensaje accionable, sin errores crípticos.
Por defecto las tareas usan un sandbox aislado; tocar un proyecto real requiere que registres su ruta explícitamente.

Lo que aprende el agente no sale de tu cuenta

Los skills (los procedimientos que el agente se escribe para reutilizarlos) son ficheros locales de tu Nodo y privados por persona: en un equipo compartido, cada miembro lee y escribe en su propio cajón. La etiqueta que separa esos cajones la compone el servidor a partir de tu sesión y es opaca (el Nodo separa sin saber quién es quién); el navegador no puede elegirla, así que no hay forma de pedir el cajón de otra persona. Hasta esta versión se publicaban a toda la instancia; esa publicación se retiró y las filas publicadas se borraron.
Las recetas se reducen a su forma abstracta en tu propio equipo (dominios en lugar de texto literal, sin rutas ni nombres de archivo) y se sirven solo a la cuenta que las aprendió. Lo único que se sirve a todo el mundo es nuestro libro de recetas curado.
Ya no hay valoraciones 👍/👎 de recetas: la única señal que ajusta la confianza de una receta es el resultado medido de la tarea, que nadie teclea y nadie puede repetir a voluntad.
No queda ningún canal de compartición entre cuentas. Ni skills, ni recetas, ni listas de «lo último de la red»: lo que se sirve a todo el mundo es nuestro libro curado, y lo aprendido vuelve solo a su dueño. Lo único que se enseña de forma agregada es el grafo de conceptos (dominios abstractos como «Python» o «Testing» y su co-ocurrencia, nunca texto de tareas) y un contador de tareas completadas y Nodos en línea.

Los informes del agente

El markdown generado por el modelo se sanea con DOMPurify antes de renderizarse: sin scripts ni HTML peligroso en el navegador.

Reportar una vulnerabilidad

Si encuentras un problema de seguridad, escríbenos antes de hacerlo público y te responderemos lo antes posible. Divulgación responsable: sin represalias contra investigación de buena fe.

El perímetro real: hasta dónde llega cada defensa

Una medida de seguridad sirve para lo que sirve, y saber dónde acaba es parte de la medida. Esto es el perímetro de Mycel dicho con precisión, que es lo que hay que leer antes de repartir accesos en un equipo.

El sandbox del Nodo confina el acceso de FICHEROS del asistente a las carpetas concedidas, pero run_shell ejecuta comandos con los permisos de tu usuario: no es un contenedor, y eso no ha cambiado. Conceder la ejecución de comandos a un miembro le da acceso efectivo a esa máquina y a lo que esa cuenta pueda leer, incluidas las carpetas de otros miembros y las credenciales guardadas (Conexiones). Lo que sí ha cambiado: ya no se concede por defecto. Ejecutar comandos es ahora una capacidad aparte del rol, apagada de origen para Operador y Admin, que el dueño enciende miembro a miembro en Equipo. Un operario que analiza documentos y redacta informes trabaja sin ella. Cuando está apagada, el Nodo no expone esa herramienta al modelo y el servidor se niega a despachar la tarea a un Nodo demasiado antiguo para aplicarlo, en vez de degradar en silencio. Para supervisión de solo lectura sigue estando el rol Supervisor.
La comprobación de una ruta y el uso del fichero son dos momentos distintos. Un enlace creado en el intervalo exacto entre uno y otro no lo detiene ninguna comprobación de ruta: eso solo lo cierra el sistema operativo. Requiere ya poder escribir en la carpeta concedida y acertar con la ventana, así que no cambia el reparto recomendado, pero se dice.
El agente no envía correo DESDE TUS BUZONES, y es una decisión, no una carencia. Lee tu bandeja y redacta la respuesta; de una cuenta IMAP/SMTP conectada el correo sale cuando una persona pulsa «Aprobar y enviar» en la pantalla Correo, después de leer el borrador. No hay modo automático ni permiso que lo active: las únicas herramientas de correo que el agente tiene son mail_list y mail_read, y ninguna de las dos escribe. El motivo, sin adornos: el agente lee correo, y un correo lo escribe cualquiera. Si además pudiera enviar, bastaría con escribiros para intentar que la respuesta se llevara datos vuestros (una inyección de prompt), y eso saldría con vuestro dominio, vuestra firma y vuestra reputación, hacia una persona que se lo va a creer. Hubo una herramienta que enviaba dentro de una tarea y se retiró.
Dónde acaba ese cierre, y son dos sitios. El primero: si le concedéis una conexión de un proveedor de envío (Brevo, Mailgun, SendGrid, o la API de Gmail o Microsoft Graph), el agente sí puede enviar por esa API con connection_call, sin que nadie apruebe nada. Es la misma herramienta con la que llama a vuestro CRM o a vuestra facturación, y por eso el reparto de conexiones se hace persona a persona: conceder una conexión de envío es conceder envío autónomo. Si eso no es lo que queréis, no la repartáis. El segundo: la retirada de la herramienta vive en el binario del Nodo, así que un Nodo con una versión anterior sigue teniéndola y el servidor ya no manda el permiso que la apagaba. Mantened los Nodos actualizados: es lo que hace efectiva esta garantía.
Y hasta dónde llega esa protección, sin redondear. Retirar el envío cierra el canal más grave, no el problema. El agente sigue leyendo texto escrito por desconocidos y sigue teniendo herramientas que salen a internet (peticiones HTTP, lectura de páginas, descargas). Nuestro guard de red bloquea las direcciones privadas (tu red interna, localhost, el metadata de un proveedor cloud), no internet público. Un correo malicioso que consiga que el agente pida una URL sigue siendo posible. Por eso: si el trabajo es leer correo de remitentes desconocidos, revisad la traza de las sesiones, que registra cada acción del agente. No os vendemos que esto esté cerrado.
Cada buzón es de quien lo conecta. Las cuentas de correo se dan de alta con su contraseña y quedan a nombre de quien las puso: un compañero no las ve, no las abre y no puede pedírselas al agente, ni siquiera siendo administrador del Nodo. Si dos personas trabajan con la misma cuenta, cada una la conecta por su lado con las credenciales que la empresa les haya dado. No hay interruptor de «compartir»: quien reparte el acceso a un buzón es quien reparte su contraseña, y eso ocurre en vuestro proveedor de correo, no aquí.
Dónde acaba esa separación: en el dueño de la máquina. Los buzones conectados en su Nodo los lee, tanto desde la pantalla de Correo como desde su agente, y se le dice a quien conecta la cuenta antes de teclear la contraseña. Responder desde ellos, no: firmar con la dirección de otra persona se queda para su dueño. Y por debajo de cualquier permiso, el almacén cifrado es uno para todo el equipo, así que quien tenga shell o acceso al disco alcanza el vault entero. Por eso la regla para el correo es: un Nodo por persona, o al menos que el Nodo sea de quien puede ver ese correo.
El token de emparejamiento del Nodo sigue guardándose en claro en su~/.mycel/config.json, porque el Nodo lo necesita para reconectar solo. Lo que ya no es: un secreto reutilizable para siempre. Ahora rota en cada conexión (el servidor solo invalida el anterior cuando el Nodo confirma que ha guardado el nuevo, para no dejarlo fuera nunca), y una segunda conexión simultánea del mismo Nodo se rechaza y queda registrada como evento de seguridad. Una copia robada del fichero deja de valer en cuanto el Nodo legítimo vuelve a conectar; si el ladrón se adelanta, el Nodo legítimo pierde la conexión y lo notarás, en lugar de convivir con una suplantación indefinida y silenciosa.