El 25 de mayo, Anthropic publicó la frase más honesta del debate actual sobre seguridad de agentes: la primera arquitectura de escritorio de Claude Cowork corría dentro de “una máquina virtual completa” usando el framework Virtualization de Apple en macOS y HCS en Windows, con su propio kernel Linux, sistema de archivos y tabla de procesos (Anthropic). Dos semanas después, Hacker News discutía por qué Claude Desktop en Windows podía lanzar una VM de Hyper-V de 1,8 GB incluso cuando el usuario solo quería chatear (Hacker News).
No es casualidad. Es la factura del producto llegando.
La versión cómoda es que Anthropic lanzó un bug, y sí, hay un informe de bug. La lectura más afilada es que los agentes de escritorio seguros están obligando a las empresas de modelos a convertirse en proveedores de runtime. En cuanto un agente puede leer archivos locales, ejecutar código, llamar herramientas y mantener estado entre sesiones, la “seguridad de IA” deja de ser un problema de ficha de modelo. Se convierte en un problema de sistema de archivos, kernel, hipervisor, política de red, identidad, auditoría y monitorización de endpoints.
La VM No Es Accidental
La arquitectura pública de Anthropic es clara. Claude Cowork no es solo una caja de chat con subida de archivos. El Centro de ayuda dice que Cowork usa dos entornos de ejecución: el bucle del agente corre de forma nativa en el dispositivo, mientras que los comandos de shell y el código generado se ejecutan en una VM Linux dedicada, aislada por Apple Virtualization.framework en macOS y Hyper-V en Windows (Claude Help Center).
Ese diseño es defendible. De hecho, es la parte en la que más confío.
El post técnico de Anthropic explica por qué Claude Code puede apoyarse en un bucle de aprobación humana mientras Cowork no puede. Los usuarios de Claude Code son desarrolladores. A menudo pueden inspeccionar un comando bash antes de aprobarlo. Cowork apunta a un trabajo de conocimiento más amplio, donde pedirle a un usuario que juzgue find . -name "*.tmp" -exec rm {} \; es puro teatro. El límite correcto para ese usuario no es un aviso intimidante. Es un sandbox siempre activo.
Anthropic también da cifras útiles. Los usuarios aprobaron aproximadamente el 93% de los avisos de permiso de Claude Code. Añadir un sandbox a nivel de sistema operativo redujo los avisos de permiso en un 84%. El modo automático de Claude Code detecta alrededor del 83% de los comportamientos “excesivamente entusiastas”, con una nota de Anthropic que dice que cerca del 17% aún se cuela (Anthropic). La lección es directa: los avisos son pistas de política. Los sandboxes son aplicación de política.
Este es el intercambio de contención que Anthropic está haciendo en realidad:
| Superficie de producto | Límite de runtime | Principal coste de seguridad |
|---|---|---|
| ejecución de código en claude.ai | Contenedor gVisor del lado del servidor | Menos capacidad local |
| Claude Code | Sandbox del sistema operativo más aprobaciones | El usuario debe entender el riesgo |
| Claude Cowork | VM Linux local | Arranque, memoria, disco, visibilidad para TI |
La VM existe porque Anthropic se está tomando en serio el radio de explosión local. Se montan el espacio de trabajo seleccionado y la carpeta .claude. Las credenciales permanecen en el llavero del host. La salida de red está restringida. Anthropic incluso menciona la validación de symlinks y los modos de montaje: solo lectura, lectura-escritura y lectura-escritura-sin-borrado.
Eso es ingeniería real. También tiene costes reales.
La Comunidad Está Enfadada Por La Factura, No Por El Límite
El issue de GitHub que llegó a HN se abrió el 26 de febrero de 2026. La persona que lo reportó describe Windows 11 Pro 25H2 en un portátil Razer Blade de 16 GB, con VirtualMachinePlatform activado y Hyper-V, WSL, Docker y Windows Sandbox desactivados. Después de usar Cowork o el modo agente una vez, Claude Desktop supuestamente lanzaba una VM de Hyper-V en cada inicio, mostrando Vmmem en torno a 1.796 a 1.846 MB (GitHub).
Eso importa porque 1,8 GB no es una abstracción. En un portátil de 16 GB es más del 11% de la RAM antes de que el usuario le haya pedido al agente hacer trabajo de agente. El mismo issue dice que la memoria en reposo subió de alrededor del 50% al 62%, y luego al 70–75% con carga normal de aplicaciones. La persona que reportó el problema también encontró 2.689 archivos de sesión obsoletos bajo %APPDATA%\Claude\local-agent-mode-sessions\.
La solución temporal no era bonita:
Disable-WindowsOptionalFeature -Online -FeatureName "VirtualMachinePlatform" -NoRestart
Stop-Process -Name vmwp -Force
Stop-Process -Name vmcompute -ForceEso no es una solución para consumidores. Es un ticket de TI.
El hilo de HN hizo lo que hace HN: algunos culparon a la chapuza, otros defendieron la necesidad de un sandbox, y varios plantearon la pregunta de producto que Anthropic debería responder directamente: ¿por qué Cowork no es simplemente opcional? Un comentarista formuló el punto medio útil: hay un espectro entre darle todo a un agente y no darle nada (Hacker News). Ese es el marco correcto.
La frustración en Linux viene del mismo sitio. La página oficial de instalación de Anthropic enumera solo macOS 11+ y Windows 10+, con opciones de instalación para “macOS” y “Windows” (Claude Help Center). Mientras tanto, los hilos de Reddit siguen preguntando por qué no hay una app de escritorio para Linux, especialmente porque Claude Desktop ya está enviando una VM Linux para la ejecución local de agentes (Reddit). La queja común no es solo “soportad mi OS”. Es: si el runtime seguro es Linux, ¿por qué los usuarios de Linux reciben el peor soporte oficial de escritorio?
La respuesta puede ser empaquetado, despliegue empresarial, integración con el llavero, sandboxing de apps, carga de soporte o la falta de una única API de seguridad de escritorio en Linux. Son razones serias. Pero la óptica de producto es mala. Los desarrolladores pueden ver la VM. Pueden ver Hyper-V. Pueden ver carpetas de sesión obsoletas. Pueden ver proyectos no oficiales de reempaquetado para Linux. Saben cuándo la abstracción tiene fugas.
La Seguridad Se Ha Convertido En Un Problema De Runtime
La parte más importante del post de Anthropic no es la VM. Es el modo de fallo.
Anthropic describe una divulgación de un tercero en la que la allowlist de salida de Cowork hizo exactamente lo que estaba configurada para hacer. Permitió tráfico a api.anthropic.com, porque el producto necesita esa API. Un archivo malicioso en el espacio de trabajo montado incluía instrucciones ocultas y una API key controlada por el atacante. Claude leyó archivos y los subió mediante la Files API de Anthropic a la cuenta del atacante. El resumen de Anthropic es demoledor: el sandbox funcionó, y aun así los datos salieron (Anthropic).
Ese es el problema de seguridad de agentes en un solo incidente. Las allowlists de dominios no bastan porque un dominio no es un permiso. Es un paquete de capacidades. Permitir api.anthropic.com significa permitir toda operación alcanzable detrás de esa API, salvo que el runtime entienda procedencia, alcance de tokens, headers e intención.
La solución de Anthropic fue un proxy defensivo de tipo man-in-the-middle dentro de la VM que solo deja pasar solicitudes que llevan el token de sesión provisionado de la propia VM y rechaza claves incrustadas por atacantes. Está bien. También es una señal para cualquiera que esté construyendo agentes de escritorio: el sandbox necesita entender identidad y capacidad, no solo direcciones IP y rutas.
Las apps de escritorio tradicionales no necesitaban tanta maquinaria porque no decidían autónomamente abrir archivos, sintetizar comandos, encadenar herramientas y rodear permisos ausentes. Un sandbox de navegador aísla páginas web no confiables. Un contenedor aísla un servicio. Un sandbox de agente de escritorio tiene que aislar a un operador semiautónomo que puede leer instrucciones de documentos hostiles y luego usar herramientas legítimas para hacer lo incorrecto.
Por eso esto se está convirtiendo en una capa de OS/runtime.
El sistema operativo ya posee la mayoría de las primitivas: aislamiento de procesos, permisos de sistema de archivos, almacenamiento seguro de credenciales, filtrado de red, logs de auditoría, notarización, hooks de EDR, gestión de dispositivos. La empresa del modelo posee el bucle del agente y la intención de política. El producto que falta es el contrato entre ambos.
TI Empresarial Paga Dos Veces
La VM le da a Anthropic un límite duro de contención. También oculta actividad a las mismas herramientas de seguridad en las que confían las empresas.
Anthropic lo dice directamente. En las FAQ de arquitectura de Cowork, la pregunta “¿Pueden las herramientas de detección de endpoints (EDR) inspeccionar la actividad dentro de la VM?” se responde con “No”. La VM está aislada de las herramientas de seguridad basadas en el host por diseño (Claude Help Center). El post técnico añade que la mitigación actual son exportaciones OTLP por consulta para administradores, que no es lo mismo que monitorización en vivo (Anthropic).
Eso significa que TI paga dos veces.
Primero, paga el coste de recursos: paquetes de disco, arranque de VM, presión de RAM, conflictos de virtualización, problemas de red y scripts de helpdesk. Segundo, paga el coste de visibilidad: lo que hace al agente más seguro frente al host también lo vuelve más opaco para la monitorización basada en el host.
Esto no es una razón para rechazar las VM. Es una razón para dejar de fingir que “corre en una VM” es el final de la historia de seguridad. Para un despliegue empresarial, una VM sellada sin telemetría de primera clase es una caja negra con un perímetro bonito.
La brecha de auditoría es aún más aguda porque el Centro de ayuda dice que la actividad de Cowork “actualmente no” se captura en logs de auditoría, la Compliance API ni exportaciones de datos, y remite a los administradores a OpenTelemetry para orientación de monitorización (Claude Help Center). Si un empleado humano usara una shell, copiara archivos o llamara a una API, las empresas esperarían logs. Si lo hace un agente dentro de una VM, “confía en nosotros, está contenido” no sobrevivirá a compras.
Qué Deberían Exigir Los Desarrolladores
El debate de la comunidad está demasiado centrado en si 1,8 GB es “demasiado”. Eso depende de la máquina y de la tarea. La demanda real debería ser control.
Los proveedores de agentes de escritorio deberían exponer el estado del sandbox como una superficie de producto, no enterrarlo en AppData y el Administrador de tareas. Desarrolladores y administradores deberían pedir cinco cosas.
Primero: arranque perezoso. El chat no debería iniciar una VM. Cowork sí. Las tareas programadas podrían justificar un runtime caliente, pero eso debería ser visible y configurable.
Segundo: un panel del sandbox. Mostrar estado de la VM, memoria, uso de disco, carpetas montadas, sesiones activas, política de salida y última limpieza. Si Docker Desktop puede mostrar contenedores, Claude Desktop puede mostrar su runtime de agente.
Tercero: opciones explícitas de instalación. Si Cowork necesita un paquete de clase 10 GB en algunos sistemas, dilo antes de la descarga. Deja que los usuarios elijan ubicación. Déjales eliminarlo sin romper el chat.
Cuarto: política como código. Los desarrolladores deberían poder inspeccionar y versionar la política efectiva del sandbox: montajes, destinos de red, permisos locales de MCP, alcances de tokens y reglas de borrado. Un panel vago de “ajustes de salida” no basta para equipos que entregan trabajo real.
Quinto: hooks de observabilidad en vivo. La exportación OTLP es un comienzo. El listón debería ser logs por llamada de herramienta, eventos de acceso a archivos, acciones denegadas, decisiones de red, identidad de sesión y códigos de razón legibles por administradores. La ceguera del EDR no puede despacharse con un gesto como el coste inevitable del aislamiento.
La petición de Linux también pertenece aquí. Una app de escritorio para Linux no es solo un detalle amable para la comunidad. Es una oportunidad de construir sobre la plataforma donde muchas primitivas de sandboxing, flujos de trabajo de desarrollo y modelos mentales de contenedores ya son nativos. Si lo difícil es la integración de escritorio, decidlo. Si lo difícil es el soporte empresarial entre distros, decidlo. El silencio deja que los usuarios infieran abandono.
La Lectura Correcta
Anthropic merece crédito por publicar detalles incómodos. El post incluye cifras reales, riesgos reales que se pasaron por alto y trade-offs reales. La mayoría de proveedores se habría quedado en “sandbox seguro”. Anthropic explicó dónde falló el sandbox, dónde falló la aprobación del usuario y dónde el aislamiento por VM empeoró la monitorización empresarial.
Pero el enfado en HN también está justificado. Los costes de seguridad no desaparecen porque el diagrama de arquitectura sea sólido. Se trasladan al portátil del usuario, al plan de despliegue del administrador y al flujo diario del desarrollador.
La VM de Claude Cowork es el futuro llegando antes de tiempo: los agentes locales necesitarán límites duros de runtime, identidad acotada, mediación de red y ejecución de herramientas auditable. Los ganadores no serán los proveedores que oculten esa maquinaria. Los ganadores harán que la maquinaria sea legible, ajustable, observable y aburrida.
Un agente de escritorio que puede operar tus archivos y herramientas ya no es solo una app. Es un pequeño entorno operativo. Trátalo como tal.
Los lectores que quieran probar Claude Fable 5 por su cuenta pueden usarlo mediante Claude Fable 5 on OneHop, un endpoint drop-in con un precio alrededor de un 30% por debajo de lista. Las cuentas nuevas pueden empezar con $10 gratis, sin tarjeta.
Lectura adicional: Primeros pasos con Claude Fable 5.
