El 17 de octubre de 2026, un grupo de desarrolladores recibió un correo que nadie quiere abrir. El asunto era más o menos el de siempre —un aviso de seguridad—, pero el cuerpo tenía una instrucción que no admite interpretación: revocá tus llaves de OpenAI, Anthropic y Google. No las cambies. No las reordenes. Revocalas, emití nuevas y revisá tu facturación.

Lo primero que uno piensa es lo obvio: otro modelo que se escapó. Otro agente que hizo algo raro. Otra historia de ciencia ficción con mal timing.

No fue eso. Y la diferencia importa muchísimo, porque es la diferencia entre culpar a la IA y arreglar la arquitectura.

Lo que se comprometió fue OpenCode Console: la capa hospedada donde los equipos guardan las llaves de sus proveedores de modelos para compartirlas entre developers, poner presupuestos y cambiar de modelo sin que cada uno cargue la suya. Un sistema legacy que estaban dando de baja. Un ataque que la empresa describió como «large scale distillation attack». Y un alcance que, según su propio comunicado, llegó al 1,4% de los usuarios de Console.

El agente no filtró nada. El lugar donde estaban guardadas las llaves, sí.

🔴 LA TESIS

1. El riesgo de un agente no escala con su capacidad. Escala con la superficie de credenciales que su arquitectura le entrega. Un modelo brillante con una llave de producción es más peligroso que un modelo mediocre sin llaves.

2. El breach de OpenCode no fue un fallo del agente: fue un fallo del plano de control. La capa hosted que centraliza llaves para dar comodidad es, por construcción, un punto único de fallo multi-proveedor.

3. El sandbox no es un accesorio de seguridad: es parte del producto. Si el agente ejecuta comandos con tus credenciales y sin aislamiento, tu ~/.ssh, tu .env y tu ~/.aws son parte del alcance.

4. El harness —no el modelo— decide si te expones. Perímetro, llaves locales, verificación adversarial y trazabilidad no son features premium: son la arquitectura mínima de un agente que trabaja con dinero y credenciales.

5. La comodidad de un plano de control hosted es exactamente el activo que te expone. Centralizar llaves te ahorra configuración y te cobra en superficie de ataque. Es un trade-off, no un default inocente.

El aviso de rigor, antes de seguir: esto es un incidente en investigación. OpenCode confirmó el breach y notificó a los afectados, pero no publicó cuántas llaves se expusieron, cómo entraron los atacantes ni si hubo uso malicioso. Todo lo que sigue separa explícitamente lo que está confirmado de lo que reportan terceros. Y hay una distinción que casi nadie va a hacer en la cobertura: la aplicación OpenCode instalada localmente no está señalada; el problema fue la capa hosted.

1. Qué pasó, exactamente

OpenCode es un agente de programación open source que corre en la terminal, como app de escritorio y dentro de IDEs. Es agnóstico de modelo: le enchufás llaves de Anthropic, OpenAI, Google u otros proveedores y vas cambiando según la tarea. Su Console es la capa hospedada para equipos: ahí se comparten modelos desde un workspace, se definen presupuestos y se conectan los proveedores externos.

El 17 de octubre, OpenCode confirmó que un acceso no autorizado a un sistema legacy que estaban retirando derivó en la exposición potencial de las llaves de proveedores externos guardadas en los workspaces afectados. La empresa envió correos a los usuarios que identificó como impactados y está trabajando con OpenAI, Anthropic y Google en la remediación. Su mensaje fue explícito en un punto: si no recibiste un correo, no estás afectado.

Hasta ahí, lo confirmado. Ahora la parte que importa para decidir qué hacer:

Dato Estado Qué significa para vos
Divulgación el 17-oct-2026 ✅ Confirmado por OpenCode Si usás Console con proveedores externos, la ventana de exposición ya ocurrió
1,4% de usuarios de Console afectados ✅ Comunicado oficial Es un porcentaje, no un número absoluto: la empresa no publicó cuántas cuentas son
Llaves de OpenAI, Anthropic y Google en riesgo ✅ Confirmado Rotación en el dashboard de cada proveedor, no dentro de OpenCode
Vector: distillation attack sobre sistema legacy en retiro ✅ Comunicado oficial No fue el modelo ni la app local: fue infraestructura hospedada
Aplicación local señalada ❌ No Análisis independientes distinguen el Console hosted de la app instalada
≈ 22 horas de exposición antes del primer aviso ⚠️ Fuente secundaria (timeline aportado por un developer) Útil como orden de magnitud, no como dato oficial
≈ US$100 en cargos no autorizados, 2 usuarios ⚠️ Reporte secundario El daño reportado es chico; el potencial no lo es
Cómo entraron, cuántas llaves, si hubo uso masivo ❓ No divulgado Asumí lo peor y rotá: el costo de rotar es una tarde
🟡 LO QUE NO SABEMOS (Y NO VAMOS A INVENTAR)

No se sabe cómo obtuvieron acceso, ni cómo estaban almacenadas las llaves, ni cuántas se expusieron, ni si fueron usadas. OpenCode tampoco publicó el número absoluto de cuentas detrás del 1,4%. Cualquier artículo que te diga «miles de llaves filtradas» está completando con imaginación un dato que la empresa no dio. Acá no hacemos eso: la ausencia de dato también es un dato, y en seguridad la respuesta correcta a la incertidumbre es rotar, no esperar el comunicado final.

2. El detalle que cambia el titular: no fue el agente, fue el Console

Imaginate la arquitectura típica de un equipo que adopta un agente de código. Cada developer tiene su máquina, su terminal, su agente. Hasta ahí, el perímetro es relativamente simple: cada uno con sus llaves, cada uno con su responsabilidad.

Después llega la comodidad. Alguien propone centralizar: «así compartimos los modelos, ponemos un presupuesto común y no estamos cargando llaves en cada laptop». Se crea un workspace. Se conectan los proveedores. Se guardan las llaves ahí, en un plano de control que ahora representa a todo el equipo frente a tres o cuatro proveedores distintos.

Ese movimiento tiene un nombre técnico y una consecuencia que casi nunca se explicita: acabás de construir un agregador de credenciales. Un solo lugar donde, si algo sale mal, el atacante no obtiene la llave de un developer: obtiene la del equipo entero, en todos los proveedores que hayas conectado.

Y eso es exactamente lo que hace valioso un ataque de destilación. En septiembre, Anthropic documentó campañas que extrajeron del orden de 190 millones de intercambios de Claude para entrenar modelos propios, en parte usando API keys cosechadas ilegalmente de empresas y personas reales. Una llave no es solo una factura: es capacidad de cómputo y de datos a nombre de otro. Por eso se roban, y por eso se usan rápido.

El Console no fue un error de diseño. Fue una decisión de producto razonable —y justamente por eso es peligrosa: nadie la cuestiona hasta que la cuestiona un incidente. — La trampa de la comodidad centralizada

Hay dos detalles operativos que confirman el punto y que conviene tener claros antes de cualquier incidente:

Primero: borrar la llave en la aplicación no la mata. Si alguien ya copió el valor, la llave sigue viva hasta que la revocás en el dashboard del proveedor. La rotación real ocurre en OpenAI, Anthropic o Google —no en el panel del agente—. Suena obvio; en la práctica, es el paso que la gente salta cuando está apurada.

Segundo: los presupuestos del Console no son un límite de daño. Cubren el gasto que pasa por el Console. Una llave robada usada directamente contra el proveedor no pasa por ahí. El tope que te protege es el spend limit del proveedor, configurado en el proveedor. Todo lo demás es un tablero, no un candado.

3. La segunda capa: el agente sin jaula

Hasta acá hablamos del plano de control. Ahora la otra mitad del problema, que es la que queda cuando el Console no existe: el agente corriendo en tu máquina.

La documentación de OpenCode advierte que el agente no tiene sandbox por defecto: ejecuta comandos con tus credenciales de usuario, sin aislamiento, y recomienda usar Docker o una VM para obtenerlo. No es una negligencia: es una decisión de diseño común en la categoría. El agente tiene que poder correr git, npm, pytest, ssh. Si le das una jaula demasiado ajustada, deja de servir para lo que lo contrataste.

El problema es qué incluye «tu usuario» en una laptop de developer en 2026:

Un agente con shell y sin aislamiento no necesita «escaparse» de nada. Ya está adentro. Y no hace falta un ataque sofisticado: alcanza con una inyección de prompt en un archivo que el agente lea —un README, un issue, una dependencia— para que ejecute algo que vos no pediste. De eso escribimos en detalle en el artículo sobre envenenamiento de memoria y procedencia: el vector no es el modelo, es el contenido que el agente trata como instrucción.

Hay un matiz que evita el pánico innecesario: no todos los agentes necesitan shell. Si el tuyo solo edita archivos de un repositorio, no le des ejecución de comandos. Si solo lee documentación, no le des red. Si solo consulta una API interna, no le des tus credenciales de nube. La regla de menor privilegio no es burocracia: es la diferencia entre un incidente contenido y uno que se propaga. Cada permiso que agregás «porque en algún momento lo voy a necesitar» es una puerta que queda abierta cuando el agente ya no está mirando lo que vos querés.

Y hay una asimetría que conviene tener presente: el costo de restringir de más es una tarde de configuración; el costo de restringir de menos se descubre en la factura, semanas después, cuando ya no sabés qué pasó.

🔴 LA PREGUNTA QUE HAY QUE HACERSE ANTES DE INSTALAR CUALQUIER AGENTE

No es «¿qué tan bueno es el modelo?». Es «¿con qué credenciales corre, sobre qué archivos puede leer y escribir, y qué pasa si un archivo malicioso le dice que haga algo?». Si no podés responder esas tres preguntas en una frase cada una, no tenés un agente: tenés un usuario nuevo con tus llaves y sin contrato.

4. Anatomía del riesgo: cuatro superficies, cuatro controles

La discusión pública sobre seguridad de agentes suele quedarse en «el modelo alucina» o «el agente se descontrola». Son las superficies menos frecuentes. Estas son las cuatro que realmente se explotan, ordenadas por facilidad de monetización:

Superficie Qué se pierde Por qué es atractiva Control real
1. Llaves Dinero directo y capacidad a tu nombre Se monetiza en minutos; no requiere interacción tuya Rotación + una llave por proyecto + spend cap en el proveedor
2. Plano de control Todas las llaves del equipo, en todos los proveedores Un solo punto de fallo; alto retorno por intento No centralizar credenciales de producción; o autohospedar
3. Shell Archivos, repos, credenciales cloud, datos de clientes Movimiento lateral; el agente ya tiene permisos Sandbox o VM, usuario sin privilegios, sin llaves de producción
4. Presupuesto Daño máximo antes de que alguien note algo Sin tope, el atacante decide cuándo parar Límites duros por proveedor + alertas de uso anómalo

Mirá el orden. Las tres primeras superficies son de arquitectura. La cuarta es de configuración. Ninguna de las cuatro se arregla con un modelo mejor. Y tres de las cuatro dependen de una sola decisión: dónde viven las llaves y quién puede alcanzarlas.

Ahí es donde el debate «¿qué agente uso?» se vuelve una distracción. La pregunta que define tu exposición es otra: ¿qué harness lo rodea?

5. El harness custom: la respuesta que no depende de que un tercero tenga cuidado

Un harness es todo lo que rodea al modelo y decide qué puede hacer, con qué herramientas, con qué credenciales y quién revisa lo que produce. No es el modelo. No es el prompt. Es la arquitectura de ejecución: el perímetro, los permisos, el loop de verificación y el registro de lo que pasó.

La diferencia entre un harness hosted y uno propio no es ideológica: es de superficie. En un hosted, alguien más guarda tus llaves. En uno propio, las llaves no salen de tu máquina. Eso es todo —y es enorme—.

Estos son los seis controles que, en nuestra experiencia, separan un agente que podés poner a trabajar de uno que solo podés demostrar:

Control Qué resuelve Cómo se ve en la práctica
1. Perímetro local Elimina el plano de control multi-tenant El agente corre en tu máquina; no hay un Console de un tercero guardando credenciales del equipo
2. Llaves en tu disco La rotación es tuya y de nadie más .env con permisos restringidos, una llave por proyecto, sin llaves de producción en el entorno del agente
3. Verificación adversarial Evita que el agente apruebe su propio trabajo Un segundo rol (verifier) con contexto distinto que revisa y puede rechazar: tests, tipos, contratos, casos borde
4. Gates humanos Lo irreversible no se automatiza por accidente Lo reversible corre solo; publicar, borrar, pagar o tocar producción requiere confirmación explícita
5. Trazabilidad Se puede reconstruir qué pasó y por qué Nota de sesión, registro de decisiones, backups antes de cada cambio, diff revisable
6. Proveedor intercambiable El modelo es una dependencia, no la plataforma Cambiar de proveedor es una línea de configuración, no una migración

También conviene decir qué no es un harness, porque la palabra se está usando para todo:

El dogfooding: lo que medimos en casa

Esto no es teoría de blog. En septiembre corrimos el mismo modelo con dos versiones de nuestro harness, sobre la misma tarea de corrección de código. Los números, sin maquillaje:

Versión Resultado Qué cambió
v2 (5-sep) 0 archivos modificados en 16 minutos Worker sin verificación adversarial: el agente exploró, dudó y no escribió nada
v3 (6-sep) Fix completo verificado — tsc -b con EXIT 0 en ~10 minutos · 3 archivos · 495+/194− Loop worker → verifier: el worker propone, el verifier rechaza y devuelve con evidencia

El detalle que más nos importa no es la velocidad: es que el verifier encontró un bug que ni el worker ni el compilador veían —una API usada solo en Chromium, invisible para tsc—. Eso es exactamente lo que un harness aporta y un modelo no: una segunda mirada con incentivos distintos. El mismo modelo que no escribió una línea en 16 minutos produjo un fix verificado cuando cambió el sistema alrededor. No cambió el modelo. Cambió el harness.

🟢 HONESTIDAD RADICAL: LO QUE NUESTRO HARNESS NO HACE

No tenemos un sandbox perfecto. No te vamos a vender invulnerabilidad. Tenemos perímetro (las llaves no salen de la máquina), verificación (alguien con incentivos distintos revisa) y trazabilidad (todo queda registrado y es reconstruible). Eso no elimina el riesgo: lo hace conocido, acotado y auditable. La diferencia entre un incidente que se investiga y uno que se descubre por la factura.

Y hay un argumento de negocio, no solo técnico. Para una pyme latinoamericana que pone un agente a trabajar con datos de clientes, la pregunta relevante no es «¿cuál es el agente más avanzado?». Es «¿dónde viven mis llaves, quién puede leerlas y quién revisa lo que el agente hace?». Un harness propio cuesta configuración. Un plano de control ajeno cuesta superficie de ataque. Elegir cuál de los dos costos podés pagar es la decisión real.

6. Qué hacer mañana (sin cambiar tu vida)

Si usás cualquier agente de código —OpenCode, Claude Code, Cursor, el que sea—, este es el checklist que aplica hoy. Está ordenado por relación entre esfuerzo y reducción de daño:

  1. Rotá las llaves en el dashboard del proveedor. No en la aplicación. Borrar una llave en el agente no invalida una copia que ya se llevaron. Empezá por OpenAI, Anthropic y Google si estaban conectados a un Console.
  2. Una llave por proyecto y por entorno. Si todas tus herramientas comparten una llave de producción, un incidente en cualquiera es un incidente en todas. El scoping no evita el robo: evita que el robo sea total.
  3. Poné un spend cap duro en cada proveedor. No es una medida de seguridad: es un límite de daño. Un tope de USD 50 en una llave de desarrollo convierte un ataque de USD 50.000 en un mal rato.
  4. Sacá las llaves de producción del entorno del agente. El agente no necesita tu llave de producción para programar. Si la necesita, el problema es el proceso, no el agente.
  5. Corré el agente en una VM o contenedor para tareas no confiables. La propia documentación de OpenCode recomienda Docker o VM para aislar. Hacelo para repos de terceros, scripts descargados y cualquier cosa que el agente vaya a leer de internet.
  6. Revisá el uso, no solo la factura. Picos en horarios raros, modelos que no usás, volúmenes que no corresponden. El cargo es el último aviso, no el primero.
  7. Poné un gate humano antes de lo irreversible. Publicar, borrar, pagar, tocar producción. Lo reversible puede ir solo; lo que no se deshace, se confirma.
💡 LA REGLA QUE RESUME TODO

Tratá cada llave de IA como tratarías una llave de AWS: con dueño, con alcance mínimo, con rotación y con un tope de gasto. La industria ya aprendió esta lección con la nube hace quince años. La está reaprendiendo con los agentes, y el precio de reaprenderla son facturas ajenas.

7. El agente corría con tus llaves

La cobertura de este incidente va a tomar dos caminos predecibles. Uno va a decir que los agentes son peligrosos. El otro, que fue un problema de infraestructura menor y que no pasa nada.

Los dos se pierden lo único que importa: el riesgo no estaba en el agente, estaba en la arquitectura que le entregó las llaves. Y esa arquitectura es una decisión, no un destino. Se puede diseñar distinto. Se puede poner el perímetro en tu máquina. Se puede verificar con alguien que tenga incentivos para rechazar. Se puede saber qué pasó después.

En Wagner Solutions trabajamos con un harness propio, y no porque seamos puristas: porque vendemos implementación a empresas donde el error se paga. Si el agente que corre en nuestra máquina tiene nuestras llaves, el peor escenario es nuestro. Si las tiene un Console de un tercero, el peor escenario es de todos.

El 17 de octubre, alguien recibió un correo y tuvo que rotar tres llaves. La lección no es «no uses agentes». La lección es la que venimos escribiendo hace meses: el modelo es la parte fácil; el harness es donde se gana o se pierde. Y la pregunta que deberías poder responder hoy, en una frase, es esta:

¿Quién más tiene una copia de tus llaves?

Tu agente no necesita ser más inteligente. Necesita un perímetro.

Si estás poniendo agentes a trabajar con datos de clientes, credenciales o dinero, conversemos 30 minutos. Te decimos dónde viven tus llaves hoy, qué superficie de ataque tenés sin saberlo y cómo se diseña un harness con verificación y trazabilidad —sin frenar al equipo—.

Hablemos 30 minutos →