Esta página es una traducción de la documentación en inglés. Los comandos, identificadores y ejemplos no cambian. Runtime 7.24.4 · SDK 2.6.7. Original en inglés

Política de seguridad

Versiones admitidas

Solo la línea menor más reciente recibe parches de seguridad. Actualiza a la menor actual antes de informar de una vulnerabilidad contra una línea más antigua.

Informar de una vulnerabilidad

Nos tomamos la seguridad en serio. Si descubres una vulnerabilidad, infórmala de forma responsable:

1. Contacto privado: usa el canal de contacto de AutomatosX para pedir una vía confidencial de informe de seguridad. No incluyas detalles del exploit ni credenciales en mensajes públicos de la comunidad.
2. Discord: infórmalo en nuestro Discord: https://discord.gg/gf9UyPxaN2

Acusaremos tu informe en un plazo de 6 días laborables y te mantendremos al tanto del avance hacia una corrección.

Nota: no aceptamos informes de seguridad generados por IA. Enviar uno supone la expulsión del proyecto. Asegúrate de que tu informe incluya pasos de reproducción concretos y demuestre un impacto real.

Modelo de amenazas

Visión general

AX Code es un asistente de programación con IA que se ejecuta de forma local en tu equipo. Ofrece un sistema de agente con acceso a herramientas potentes, incluidas la ejecución de shell, las operaciones de archivos y el acceso a la web.

El valor predeterminado de aislamiento del entorno es full-access (sandbox desactivado), con escrituras en el sistema de archivos y acceso a la red sin restricciones. Es una postura de comodidad para proyectos locales de confianza, no un límite de seguridad. Elige workspace-write o read-only antes de usar AX Code con repositorios no confiables o cargas sin supervisión.

Sandbox de aislamiento de la ejecución

AX Code incluye un sandbox de aislamiento de la ejecución que restringe a qué puede acceder el agente de IA. Hay tres modos:

Propiedades clave:

• Comportamiento predeterminado: AX Code arranca en full-access salvo que --sandbox, AX_CODE_ISOLATION_MODE o la configuración definan otro modo
• Modo restringido recomendado: usa workspace-write para repositorios no confiables o de equipo; confina las escrituras al espacio de trabajo y desactiva la red de forma predeterminada
• Aplicación a nivel de herramienta: todas las herramientas de mutación (bash, edit, write, apply_patch) y las de red (webfetch, websearch, codesearch) comprueban la política de aislamiento antes de ejecutarse
• Rutas protegidas: los directorios .git y .ax-code están siempre protegidos contra escritura, incluso en el modo de escritura del espacio de trabajo
• Avisos de elevación: en los modos restringidos, las infracciones de aislamiento presentan un diálogo de aprobación en lugar de fallar en silencio; los usuarios pueden permitir una operación bloqueada una vez sin cambiar su configuración
• Control de la CLI: --sandbox read-only, --sandbox workspace-write, --sandbox full-access
• Variable de entorno: AX_CODE_ISOLATION_MODE

Backends de aislamiento

{
  "isolation": {
    "mode": "workspace-write",
    "network": false,
    "backend": "auto"
  }
}

O define AX_CODE_ISOLATION_BACKEND=os|auto|app.

El aislamiento del sistema para bash deniega las escrituras fuera de las raíces del espacio de trabajo y deniega la red cuando network: false. Las comprobaciones de la capa de aplicación siguen ejecutándose siempre. En plataformas sin Seatbelt ni bubblewrap, usa backend: "app" o un contenedor o una máquina virtual.

Seguridad del servidor

• Solo localhost de forma predeterminada: el servidor se enlaza a 127.0.0.1, inaccesible desde la red
• Contraseña exigida para el acceso de red: enlazar a 0.0.0.0 o a cualquier dirección que no sea localhost exige que AX_CODE_SERVER_PASSWORD esté definido; el servidor se niega a arrancar sin ello
• Autenticación básica aplicada: cuando AX_CODE_SERVER_PASSWORD está definido, se exige HTTP Basic Auth en todos los endpoints de la API
• CORS configurable: se pueden indicar orígenes adicionales permitidos mediante --cors

Almacenamiento de credenciales

Las claves de API de los proveedores se cifran en reposo con AES-256-GCM y derivación de clave PBKDF2, y se guardan en el directorio de datos local de AX Code (~/.local/share/ax-code/) con permisos de archivo solo del usuario (0600).

La clave de cifrado se deriva de atributos de la máquina local (nombre de host, plataforma, arquitectura). Esto protege frente a una revelación casual sin conexión (por ejemplo, compartir un archivo por accidente), pero no protege frente a un atacante decidido con acceso al host. No equivale al llavero del sistema ni a un almacén de secretos respaldado por hardware.

Los tokens OAuth de MCP, los secretos de cliente y los tokens de acceso y de refresco de la cuenta también se cifran en reposo con el mismo mecanismo. Los metadatos no sensibles (URL de servidor, marcas de caducidad, correo y ID de cuenta) permanecen en texto claro.

Verificación de artefactos de versión

Tanto el instalador Bash (install) como el instalador PowerShell de Windows (install.ps1) verifican los archivos de versión de GitHub descargados con minisign antes de extraerlos. Los archivos de versión y el propio script del instalador PowerShell llevan firmas separadas. La clave pública fijada de versión de AX Code es:

RWSlDu++afxCz01OqhYWhfo8+L8pVbSYXJBEb2zoWBuK0WACIzbGVZRO

Cada instalador descarga el activo .minisig correspondiente al archivo elegido y falla cerrado cuando la verificación falla. Si minisign no está ya en PATH, los instaladores descargan los archivos oficiales fijados de minisign 0.12 desde https://download.ax-code.com/vendor/minisign/0.12/, comprueban el SHA-256 del archivo y vuelven a comprobar el ejecutable extraído antes de guardarlo en caché. Un binario minisign que ya esté en PATH es la herramienta del operador y no se vuelve a hashear. Define AX_CODE_SKIP_MINISIGN_VERIFY=1 solo cuando aceptes a propósito una descarga de versión que no se pueda verificar.

El atajo de una línea irm …/install.ps1 | iex no verifica el script del instalador antes de la ejecución. Para instalaciones sensibles a la seguridad, descarga install.ps1 y install.ps1.minisig, verifica el script con minisign y luego ejecútalo en local (consulta Canales de instalación y del entorno de ejecución).

Los mantenedores deben mantener cifrada la clave secreta de minisign. Para firmar versiones en local en macOS, guarda la frase de paso en Keychain en lugar de en un archivo de texto claro:

security add-generic-password -U -a ax-release -s ax-minisign -w

Las herramientas de versión leen ese elemento de Keychain de forma automática cuando AX_CODE_MINISIGN_PASSWORD no está definido.

El flujo de versión de GitHub dirigido por etiquetas firma los archivos antes de subirlos. Exige estos secretos del repositorio:

AX_CODE_MINISIGN_SECRET_KEY_B64
AX_CODE_MINISIGN_PASSWORD

AX_CODE_MINISIGN_SECRET_KEY_B64 debe ser el contenido codificado en base64 de la clave secreta de minisign cifrada ax.minisign.key (la ruta local puede ser un enlace simbólico a ax.sec). El flujo la escribe en un archivo de clave temporal 0600, verifica la clave pública fijada, firma cada archivo de versión y sube los activos .minisig correspondientes junto con los archivos.

Para los archivos de CLI de macOS, el flujo exige e importa el certificado Apple Developer ID usando estos secretos del repositorio:

APPLE_CERTIFICATE
APPLE_CERTIFICATE_PASSWORD
APPLE_TEAM_ID
APPLE_API_KEY_B64
APPLE_API_KEY_ID
APPLE_API_ISSUER

En ese camino, las bibliotecas nativas incluidas se firman con la identidad importada Developer ID Application, el ZIP de macOS se envía al servicio de notarización de Apple y el ZIP sin cambios queda después protegido por la firma minisign separada. Los archivos ZIP no se pueden grapar, así que la notarización debe ocurrir antes de subir el artefacto y antes de generar .minisig. Las compilaciones de versión fallan cerrado cuando falta cualquier credencial de firma o de notarización de Apple.

Historial de la clave de firma de versiones

La clave de firma de versiones se rotó por última vez el 2026-07-19. El instalador y el flujo de versión fijan solo la clave actual, así que los archivos firmados con una clave retirada fallan la verificación de firma. Después de una rotación, los mantenedores deben volver a firmar los archivos históricos de versión con script/resign-release-assets.ts para que cada versión publicada se verifique contra la clave fijada sin confiar en claves retiradas.

Para volver a firmar y volver a subir los activos .minisig de una versión existente con la clave actual:

tsx script/resign-release-assets.ts --tag v5.5.0 --key-dir ~/signkey

Alcance

Dentro del alcance

Fuera del alcance

Capacidades de seguridad de empresa

AX Code está diseñado para uso de empresa con estas funciones de endurecimiento:

• Permisos de grano fino: conjuntos de reglas específicos del agente y basados en patrones (allow/deny/ask). El agente de seguridad usa solo lectura de forma predeterminada. Las reglas se evalúan entre el proyecto, el agente y las listas aprobadas.
• Rastros de auditoría de sesión: cada llamada a herramienta, decisión de permiso y cambio de archivo se registra en SQLite con instantáneas. Admite reproducción, bifurcación y exportación para revisiones de cumplimiento.
• Refactorización determinista (DRE): impact_analyze, refactor_plan y refactor_apply (worktree sombra más lint, comprobación de tipos y pruebas) aportan cambios auditables y reversibles.
• Gestión de credenciales: cifrado AES-256-GCM para todas las claves y tokens. Aislamiento por directorio mediante InstanceState.
• Aplicación optativa del sandbox: aislamiento a nivel de aplicación con análisis de comandos bash (tree-sitter). Elige workspace-write o read-only para aplicar los límites del sandbox; las rutas protegidas (.git, .ax-code) se aplican en los modos con sandbox.
• Endurecimiento del servidor: solo localhost de forma predeterminada; acceso remoto protegido con contraseña y Basic Auth.
• Inteligencia de código y exploración: detección integrada de secretos y de valores fijos, y análisis de impacto de dependencias.

Retroalimentación de programación asistida por CodeQL

El repositorio ejecuta CodeQL como capa de análisis de seguridad en segundo plano para solicitudes de extracción, envíos a dev, exploraciones programadas y despachos manuales. CodeQL no forma parte del LSP en vivo ni del camino de inteligencia de código; es una fuente de evidencia más lenta y profunda para hallazgos de flujo de datos, de contaminación y de calidad de seguridad que se tratan mejor después de que los cambios de código se hayan estabilizado.

El flujo actual analiza:

• Código de entorno de ejecución, TUI, SDK, integración y scripts en JavaScript y TypeScript.
• Flujos de GitHub Actions y acciones compuestas locales.
• Crates de Rust bajo crates/ con una compilación manual de Cargo para que el código del complemento nativo y de la TUI se extraiga de forma coherente.

La experiencia prevista para quien desarrolla es:

1. Quienes abren la solicitud de extracción reciben alertas de CodeQL en el análisis de código de GitHub, junto a la comprobación de tipos, las pruebas deterministas, la exploración de dependencias OSV y las guardas de estructura del repositorio ya existentes.
2. Los mantenedores clasifican los resultados iniciales antes de tratar CodeQL como una compuerta dura de fusión, para que los hallazgos nuevos sean útiles y no ruido.
3. Los flujos futuros de revisión y depuración de AX Code pueden ingerir SARIF de CodeQL o alertas de análisis de código de GitHub como evidencia de seguridad explícita, con campos de procedencia como source: "codeql", id de regla, gravedad, archivo, línea, traza de flujo de datos y SHA del commit analizado.
4. La evidencia de CodeQL debe mostrarse junto a security_scan local, hardcode_scan, los diagnósticos del LSP y el análisis de impacto respaldado por el grafo, no como un sustituto oculto de ninguno de ellos.

Al añadir consultas personalizadas de CodeQL, prefiere límites de seguridad específicos del repositorio frente a comprobaciones amplias al estilo de un linter. Los objetivos de alto valor incluyen caminos de escape del sandbox, ejecución de comandos con argumentos no saneados, salto de ruta alrededor de la contención del espacio de trabajo, propagación de secretos o del entorno a procesos hijos y validación ausente de rutas del servidor.

Para un gobierno de empresa completo (RBAC, política como código, exportación a SIEM, auditoría criptográfica), integra con AX Trust (elemento de la hoja de ruta).

Consulta docs/guides/sandbox.md para la configuración del aislamiento y el comportamiento del entorno de ejecución.