Las maneras en que contenemos a Claude entre productos
La publicación de Anthropic sobre cómo “contener” sus agentes de IA Claude provoca un examen más amplio de cómo limitar el daño que pueden hacer los modelos muy capaces, especialmente en torno a la exfiltración de datos, la prompt injection y el acceso excesivamente amplio a herramientas/API. Los comentaristas describen sus propias estrategias de contención —desde VMs, “home agents” aislados de la red y controles estrictos de salida hasta sandboxes basados en SQL—, al tiempo que enfatizan que la esteganografía, los ataques a la cadena de suministro y la ingeniería social siguen siendo difíciles de eliminar. A muchos les incomoda el marco riesgo–recompensa de Anthropic, y argumentan que los guardarraíles actuales tienen fugas, que los beneficios reales no están demostrados y que los usuarios pueden estar asumiendo un riesgo desproporcionado a medida que las herramientas de IA se introducen en flujos de trabajo más críticos.
Amenazas de seguridad y riesgos de exfiltración
- Los comentaristas destacan muchos vectores de exfiltración más allá de lo que describe el artículo: fronting de dominios, codificación esteganográfica en commits o texto, canales laterales de temporización/orden, e inyecciones de prompts ocultas en repos, documentación, informes de errores o dependencias.
- Varios sostienen que impedir la exfiltración basada en prompt injection es, en la práctica, imposible sin sistemas de clasificación de datos muy sólidos y multinivel, y diseños seguros frente a canales laterales.
- Algunos predicen que la industria desplegará agentes en modo “YOLO” y tratará la exfiltración y la corrupción como un costo aceptado, similar al fraude.
Arquitecturas de contención (VMs, esclusas de aire, máquinas separadas)
- Varios usuarios describen ejecutar agentes en VMs (qemu, contenedores de macOS, VMs de Linux) con controles estrictos de salida, tokens específicos por proyecto y revisión manual de commits.
- Se discute un patrón de “esclusa de aire”: un agente local, sin conexión, con acceso al sistema de archivos; un agente en línea, sin FS; los datos solo se mueven entre ambos mediante texto mediado por el usuario, nunca automáticamente de vuelta a internet.
- Otros sugieren una separación aún más estricta: hardware totalmente separado (portátiles baratos/VPS), canales unidireccionales o conceptos inspirados en Qubes y “Tin Foil Chat.”
- Hay debate sobre contenedores frente a VMs: algunos ven Docker como un límite de seguridad demasiado débil; otros lo aceptan con herramientas adicionales como bubblewrap.
Limitaciones de los guardarraíles actuales
- Los comentaristas enfatizan que los controles a nivel de entorno importan más que los modelos “bien portados”; los modelos siguen siendo probabilísticos y pueden ser engañados.
- La nota del artículo de que la aprobación automática bloquea solo ~83% de las acciones riesgosas alarma a algunos lectores, que lo ven inconsistente con la documentación del producto, la cual sugiere garantías más sólidas.
- Los errores pasados informados en el sandboxing de Claude Code y en el alcance de tokens sugieren que la contención sigue siendo frágil y sufre regresiones.
Marco riesgo–recompensa y escepticismo
- Varios participantes critican el marco explícito de riesgo–recompensa del artículo: lo ven normal en seguridad, pero les preocupa que las empresas optimicen su recompensa mientras externalizan el riesgo a los usuarios.
- Otros argumentan que todos los sistemas del mundo real aceptan un riesgo distinto de cero; la clave es minimizar el daño esperado, no eliminarlo.
- Hay un escepticismo notable hacia las comunicaciones del proveedor, y algunos ven las narrativas de “peligro del modelo” como marketing, incluso reconociendo al mismo tiempo un trabajo de seguridad genuino.