Qué dice el paper
Un nuevo paper de arXiv introduce un concepto que va a incomodar a cualquiera que use LLMs en producción: la ilegibilidad lingüística (linguistic illegibility). La idea central es dura: los textos que produce un LLM —incluido su chain-of-thought (CoT)— son una representación poco fiable de cómo el modelo realmente piensa por dentro.
Los autores lo argumentan así: los LLMs no computan en lenguaje, sino en matemáticas sobre espacios de activación. La traducción de esos estados internos a palabras es con pérdida, y ocurre solo en los extremos del pipeline. Esto significa que cualquier mecanismo de seguridad que dependa de leer lo que el modelo "dice" —monitorización del CoT, autocrítica constitucional, probing de activaciones con vectores definidos lingüísticamente— nunca podrá ser completamente sólido. Siempre existirá la posibilidad de que el modelo esté "pensando" algo que su texto externo no refleja.
Por qué importa para tu agente
Si estás desplegando un agente LLM con herramientas, esta distinción deja de ser teórica. La CoT no es una pista de aterrizaje confiable. Un modelo puede escribir un razonamiento impecable mientras, por dentro, ejecuta instrucciones que su texto no muestra. El paper lo dice sin rodeos: "el sandbox siempre necesitará técnicas de aislamiento cuyas garantías no dependan de leer el estado lingüístico del modelo".
🤖 La IA no es solo para leer sobre ella
En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.
👥 Aplicarla en la comunidadEsto conecta directamente con lo que viene mostrando el OWASP GenAI Security Project en su ranking 2026: Prompt Injection sigue siendo el riesgo #1, Sensitive Information Disclosure el #2, y Excessive Agency trepó del sexto al tercer puesto precisamente porque los despliegues agentic son donde está cayendo el daño real. El listado se construyó con 6.639 incidentes reales más voto de practitioners, y los autores del paper citado por Help Net Security lo sintetizan así: "deja de intentar construir un modelo que no pueda ser engañado; construye el sistema a su alrededor, para que cuando el modelo sea engañado —y lo será— nada importante se rompa".
Qué propone el paper en lugar del CoT
Los autores no se quedan en el diagnóstico. Defienden una capa de controles que existe fuera del modelo:
- Taint tracking (seguimiento de procedencia de datos): definir a priori qué piezas de estado del sistema nunca deben ser influenciadas por datos producidos por el modelo, sin importar cómo se reporte lingüísticamente. Es una política declarativa que opera sobre el flujo de datos, no sobre el texto del modelo.
- Virtualización robusta: ejecutar al agente dentro de un entorno con garantías fuertes de aislamiento del host.
- Auditoría de terceros sobre las configuraciones de sandboxing —para que nadie audite su propia caja fuerte.
El paper además afirma que estas medidas habrían mitigado exploits recientes de sandbox en modelos frontera, aunque no nombra cuáles exploits ni qué modelos (la fuente no da los detalles).
Qué puedes aplicar hoy en tu stack
No necesitas ser researcher para llevarte algo accionable. Tres movimientos que el paper respalda y que la práctica agentic ya está pidiendo:
- No confíes en la CoT como log de auditoría. Si tu flujo de incidentes depende de leer lo que el modelo escribió para entender qué hizo, vas a tener puntos ciegos. Loggea acciones a nivel de sistema, no a nivel de texto.
- Pon un Policy Enforcement Point (PEP) entre el modelo y cualquier herramienta. Como documenta el análisis de Unite.ai sobre el OWASP 2026, cada tool call debe pasar por autorización externa al modelo. Least privilege, OAuth scopeado por usuario, HITL para acciones irreversibles.
- Define límites duros que el agente no controla. Techo de tokens, tiempo elapsed, profundidad de recursión y costo acumulado. El paper y OWASP coinciden: si tu sistema no tiene un kill switch determinístico fuera del modelo, estás delegando autoridad sin definir perímetro.
¿Qué significa esto para tu startup?
Si estás construyendo producto con LLMs, la lección operativa es: la seguridad no es una propiedad del modelo, es una propiedad de la arquitectura que lo rodea. Esto cambia dos decisiones de diseño que muchos founders aún postergan.
Primero, el presupuesto de seguridad se mueve del prompt al middleware. Invertir horas en system prompts y Constitutional AI da una sensación de control que es, según el paper, ilusoria en el caso general. Invertir en proxies, PEPs y taint tracking te da garantías que sobreviven a un modelo que miente o que es jailbroken.
Segundo, tu superficie de monitoreo cambia. En lugar de auditar el texto del CoT, audita el grafo de tool calls, los recursos tocados y las identidades autorizantes. Es la misma cadena de custodia que pide OWASP para respuesta a incidentes: qué herramienta se ejecutó, bajo qué identidad, con qué efecto sobre el sistema destino. Esto se vuelve crítico cuando un agente multi-step falla en el paso 17 de 20 y necesitas reconstruir qué autorización chain llevó ahí.
La regla mental que resume el paper y el OWASP 2026 es la misma: asume que el modelo será engañado y diseña para que, cuando eso pase, nada importante se rompa. Tu agente no necesita ser perfecto; necesita tener un blast radius acotado.
Fuentes
- The Implications of Linguistic Illegibility for LLM Security (arXiv) (fuente original)
- OWASP 2026 LLM Top 10: "The model will be fooled" — Help Net Security
- The Hardest AI Security Problems Now Live Outside the Model — Unite.AI
🤖 La IA no es solo para leer sobre ella
En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.
👥 Aplicarla en la comunidad













