Claude Code y el problema de los prompts invisibles

La acusación en una frase

Una nota de International Cyber Digest publicó una acusación sensible contra Claude Code, la herramienta de programación asistida por agentes de Anthropic: según un reporte técnico enlazado en la nota, ciertas versiones del cliente habrían codificado señales sobre proxies, dominios vinculados a China y zona horaria dentro de una línea aparentemente inocente del system prompt.

La acusación no habla de un archivo secreto subido por separado ni de un canal de red adicional. Lo delicado es otra cosa: el supuesto marcador viajaría dentro del propio prompt que el cliente ya envía al modelo.

Si eso se confirma, el problema no es solo técnico. Es de confianza.

Qué se habría detectado

El reporte afirma haber revisado versiones de Claude Code como 2.1.193, 2.1.195 y 2.1.196. Según ese análisis, el cliente miraría la variable de entorno ANTHROPIC_BASE_URL, que se usa cuando Claude Code se conecta a una ruta personalizada en lugar del endpoint oficial de Anthropic.

Cuando esa URL no apunta a api.anthropic.com, el código supuestamente extrae el hostname del proxy y lo compara contra una lista de dominios. Esa lista incluiría empresas tecnológicas chinas, regiones cloud chinas, laboratorios de IA y servicios de reventa o mirror de APIs.

Además, el reporte dice que el cliente revisa la zona horaria local y marca específicamente Asia/Shanghai y Asia/Urumqi.

Hasta ahí, el comportamiento podría leerse como una lógica anti-abuso: detectar reventa no autorizada, proxies de terceros o rutas que podrían estar fuera de los términos de uso. Las empresas de IA tienen incentivos reales para eso.

El punto crítico es el método.

El marcador no estaría en un campo obvio

Según el reporte, la señal no se enviaría como un campo de telemetría fácil de auditar. En cambio, se codificaría modificando la línea del system prompt que informa la fecha actual.

Ejemplo conceptual:

Today's date is 2026-06-30.

Si el usuario está en una zona horaria china, el separador de fecha cambiaría de guiones a barras:

Today's date is 2026/06/30.

Y para codificar si el dominio aparece en una lista conocida o contiene keywords asociadas a laboratorios de IA, el reporte describe variaciones casi invisibles del apóstrofo en Today's: ', ’, ʼ y ʹ.

Para una persona leyendo rápido, esos caracteres son indistinguibles. Para un sistema que recibe texto, son bytes diferentes.

Eso es lo que convierte una línea banal en un posible canal encubierto.

Lo que no conviene exagerar

Hay que separar los hechos alegados de las conclusiones más fuertes.

Primero: el reporte sostiene que el mecanismo se activa solo cuando hay proxy mediante ANTHROPIC_BASE_URL. Un usuario que usa Claude Code contra el endpoint oficial no quedaría marcado por esta lógica.

Segundo: no se describe una toma de control remota ni una lectura adicional de archivos. La señal viajaría en el prompt que ya se estaba enviando. Eso no la vuelve inocua, pero sí evita mezclar el caso con acusaciones más graves que no están probadas por este análisis.

Tercero: como control anti-abuso, parece débil. Un revendedor sofisticado podría cambiar hostname, zona horaria o parchear el cliente. En otras palabras: el mecanismo podría afectar más a usuarios legítimos que usan proxies por razones operativas que a actores decididos a evadirlo.

Por qué igual importa

Un agente de código no es un chatbot cualquiera.

Claude Code, Cursor, OpenCode, Devin y herramientas similares viven dentro del entorno de desarrollo. Pueden leer archivos, entender la estructura del repo, proponer cambios, ejecutar comandos y, según permisos, modificar código.

Eso crea una relación de confianza mucho más profunda que la de una interfaz web aislada.

Cuando una herramienta de este tipo envía información al modelo, el usuario necesita poder responder preguntas básicas:

• Qué datos salen de mi máquina.
• Qué metadatos se agregan automáticamente.
• Qué señales usa el proveedor para seguridad o anti-abuso.
• Qué parte del prompt puedo inspeccionar.
• Qué comportamiento puedo desactivar.

La telemetría documentada puede ser aceptable. Un marcador invisible dentro del prompt es otra categoría. No porque sea técnicamente sofisticado, sino porque rompe la expectativa de auditabilidad.

El paralelo histórico incómodo es Red Star OS, el sistema operativo norcoreano que, según análisis de seguridad publicados durante años, agregaba marcas a archivos para rastrear por qué computadoras habían pasado. No es el mismo alcance ni la misma severidad: ahí se hablaba de watermarking persistente sobre archivos del usuario dentro de un sistema estatal de control. Acá, si el reporte es correcto, hablamos de señales efímeras dentro de prompts enviados a un proveedor privado.

Pero la familia técnica se parece: fingerprinting encubierto mediante marcas que el usuario normal no ve. En un caso, el archivo queda marcado. En el otro, el request queda etiquetado. La pregunta de fondo es la misma: quién controla las marcas invisibles que viajan con nuestra información.

El prompt como superficie de seguridad

Durante mucho tiempo tratamos los prompts como texto: instrucciones, contexto, ejemplos, archivos pegados. Pero en los sistemas agentic actuales, el prompt también es una superficie de control.

El system prompt define políticas, permisos, identidad del agente, restricciones de seguridad y contexto operativo. Si además puede transportar metadatos no obvios, entonces deja de ser solo una instrucción legible y pasa a ser una capa de señalización.

Ese cambio exige una regla simple: lo que el cliente agrega al prompt debería ser visible, documentado y razonablemente explicable.

No alcanza con decir "es por seguridad". La seguridad también necesita transparencia.

Qué deberían hacer las herramientas de agentes

Si un proveedor necesita detectar abuso, hay formas menos ambiguas de hacerlo:

1. Declarar qué variables de entorno o rutas se inspeccionan.
2. Separar telemetría de contenido del prompt.
3. Permitir modo auditado donde el usuario vea el payload final.
4. Documentar señales anti-abuso y retención de datos.
5. Evitar codificaciones invisibles en caracteres Unicode.

La clave no es que todo mecanismo anti-abuso sea público al detalle. La clave es no esconder señales ambientales dentro de texto que el usuario cree inocente.

Qué puede hacer un equipo hoy

Para equipos que usan agentes de código en repos reales, este caso deja una lección práctica: no alcanza con revisar permisos de archivos y comandos. También hay que auditar el tráfico lógico del agente.

Medidas razonables:

• Revisar variables como ANTHROPIC_BASE_URL y cualquier proxy intermedio.
• Evitar exponer secretos en el entorno de ejecución del agente.
• Preferir clientes y configuraciones que permitan inspeccionar requests.
• Mantener una política clara sobre qué repos pueden usarse con agentes externos.
• Tratar los system prompts generados por clientes como parte de la superficie de seguridad.

No se trata de abandonar los agentes. Se trata de usarlos con el mismo criterio con el que usaríamos una dependencia crítica dentro del pipeline de desarrollo.

La pregunta de fondo

La industria está empujando hacia agentes cada vez más autónomos. Eso significa más permisos, más contexto y más decisiones delegadas.

En ese escenario, la confianza no se gana solo con benchmarks. Se gana con comportamientos predecibles, documentación clara y controles auditables.

Si una herramienta necesita marcar un request por razones de seguridad, que lo haga de forma explícita. Si necesita recolectar telemetría, que lo documente. Si necesita detectar abuso, que no transforme una fecha del system prompt en un canal escondido.

Porque para los agentes de código, el producto real no es solo el modelo.

El producto real es la confianza operativa.

---

Fuentes: International Cyber Digest y el reporte técnico enlazado en GitHub Gist. Esta nota resume una acusación basada en análisis de terceros; conviene seguirla como un caso abierto hasta que haya respuesta oficial o verificación independiente adicional.