Johann Rehberger publicó un análisis sobre prompt injection en el modo automático de Claude Code con Opus 5, y Simon Willison lo levantó pocos días después. El material que tengo a mano no reproduce el mecanismo exacto del bypass —para eso hay que leer el post original, y te recomiendo que lo hagas—, así que no voy a describir pasos que no verifiqué. Lo que sí se puede discutir sin conocer cada detalle es la categoría del problema.

Por qué importa

La señal no es "apareció un bug en Opus 5". La señal es que el modo automático es, por definición, la decisión de sacar al humano del punto donde se otorgan permisos. Prompt injection no es una vulnerabilidad puntual que se parchea y se cierra: es una propiedad estructural de cualquier sistema donde el mismo contexto mezcla instrucciones tuyas con texto que vos no escribiste. Un README de una dependencia, un issue de GitHub, el HTML de una página que el agente fue a leer, la salida de un comando. Todo eso entra como texto y el modelo no tiene un canal separado para distinguir "esto es una orden legítima" de "esto es contenido que estoy analizando".

Mientras la aprobación manual estaba en el medio, esa ambigüedad tenía un amortiguador: vos veías el comando antes de que corriera. Auto mode remueve el amortiguador. No lo digo como reproche —lo uso, es enormemente productivo—, lo digo porque conviene llamarlo por su nombre: es una decisión de arquitectura de seguridad disfrazada de casilla de comodidad.

Y el contexto de esta semana empuja en la misma dirección. Vercel anunció que ya se pueden correr Claude Managed Agents con el Chat SDK, con el loop del agente manejado del lado del servidor: modelo, herramientas, estado de sesión e investigación web en sandbox. GitHub, por su parte, extendió Copilot code review a pull requests creados por bots y eliminó el límite de 300 archivos o 20.000 líneas. Son buenas noticias de producto. También significan más agentes leyendo contenido de terceros, más agentes revisando output de otros agentes y menos ojos humanos por unidad de acción ejecutada.

Qué cambia en la práctica

Lo primero que cambié en mi flujo hace rato: el output de un agente es input no confiable. Si un agente redacta un PR y otro agente lo revisa y aprueba, la cadena entera no tiene ningún punto donde alguien haya validado el contenido contra intención humana. Eso no es automatización, es un ciclo cerrado.

Lo segundo es dejar de pensar en "¿apruebo este comando?" y empezar a pensar en "¿qué es lo peor que puede hacer este proceso si el modelo hace exactamente lo que le pidió el texto malicioso?". La respuesta se acota con configuración, no con confianza:

// .claude/settings.json
// el agente lee y escribe en el repo, pero no llega
// ni a la red ni a las variables de entorno
{
  "permissions": {
    "allow": ["Read", "Edit", "Bash(npm run test:*)"],
    "deny": ["Bash(curl:*)", "Bash(env)", "Read(./.env)"]
  }
}

Una allowlist explícita vale más que una denylist larga: la denylist enumera lo que se te ocurrió, la allowlist enumera lo que la tarea necesita. Y si la tarea necesita red, que la necesite en un contenedor sin credenciales montadas, no en tu sesión con el token de producción en el ambiente.

Tercero, y es el que más gente saltea: separar el rol de lectura del rol de escritura. Un agente que investiga —que abre páginas, lee issues, resume documentación— es el que más expuesto está a contenido hostil, y justamente es el que menos necesita permisos de ejecución. Correrlo con capacidad de escribir en el repo y de hacer requests salientes es combinar la superficie de entrada más grande con el radio de daño más grande.

Cuarto: nada de auto-merge en PRs generados por agentes, por más que otro agente los haya revisado. La revisión automática sirve para bajar el ruido antes de que llegue el humano, no para reemplazarlo.

Cuándo NO usarlo

Voy a ser honesto en las dos direcciones, porque el consejo de "nunca uses auto mode" es tan inútil como el de "activalo y listo".

Dónde el modo automático me parece razonable: repositorios sin secretos, en un contenedor descartable, con el trabajo acotado a archivos que ya conocés, sin acceso a red saliente y con el diff revisado antes de commitear. Ahí el peor caso es perder tiempo, y el ahorro es real.

Dónde no lo activaría hoy:

  • Cuando el agente va a leer contenido que no controlás: issues públicos, PRs de terceros, páginas web, dependencias nuevas. Esa es literalmente la vía de entrada.
  • Cuando hay servidores MCP conectados que tocan sistemas reales: base de datos de producción, tracker de tickets, correo, deploy. La combinación "lee cualquier cosa" + "puede escribir en producción" no tiene mitigación razonable del lado del prompt.
  • Cuando el repositorio tiene credenciales en el ambiente, aunque sean de staging. Un token filtrado es un token filtrado.
  • Cuando el pipeline hace deploy automático al merge. El radio de daño deja de ser tu working tree.

Y el tradeoff inverso, que también es honesto: aprobar cada permiso a mano no escala y termina en aprobación por reflejo, que es peor que no tener el prompt. Si tu única defensa es tu atención sostenida en la tecla Enter, no tenés defensa. El objetivo no es más fricción, es menos radio de daño.

Un límite del propio análisis: con el material que tengo no puedo decirte si lo reportado ya está mitigado, ni en qué versiones aplica. No lo afirmo en ningún sentido.

Qué haría hoy

Leería el post de Rehberger completo antes que cualquier resumen —incluido este—, y después revisaría dos cosas concretas: qué servidores MCP tengo conectados en las sesiones donde uso modo automático, y si mis reglas de permisos están escritas como allowlist o como una denylist que fui parchando. Después movería el trabajo de investigación a un contenedor sin credenciales. No porque haya un exploit específico que me asuste, sino porque la clase de problema no se va a ir: cada release que corre más loop sin supervisión hace que la pregunta importante sea siempre la misma, cuánto puede romper esto si obedece a la persona equivocada.