Estaba leyendo el OWASP Top 10 para aplicaciones de modelos de lenguaje hace un par de tardes, la lista actualizada que salió a finales del año pasado, y algo en ella llamó mi atención de inmediato porque se mapea de forma muy directa con un problema que Newton Protocol intenta resolver en silencio. La inyección de prompts ocupó el primer puesto: no como una preocupación teórica, sino como la vulnerabilidad más crítica que afecta activamente a los sistemas de Al en este momento, desde copilotos empresariales hasta asistentes de codificación y agentes autónomos que gestionan flujos de trabajo reales. La descripción de la comunidad de seguridad es casi incómodamente simple: un atacante inserta instrucciones maliciosas dentro de contenido que el agente debe leer como datos; el agente no puede distinguir de manera fiable la instrucción de la información, y la carga maliciosa anula lo que el agente estaba originalmente destinado a hacer. En la mayoría de contextos de software, eso produce una respuesta incorrecta o un documento filtrado. En un agente financiero onchain con una billetera financiada y permisos de ejecución de transacciones, produce algo considerablemente peor.
Lo que me parece genuinamente interesante es qué tan precisamente la descripción del problema por parte de la comunidad de investigación en seguridad se corresponde con la brecha arquitectónica que Newton está diseñado para cubrir, aunque ambos temas rara vez se mencionan directamente entre sí. Los investigadores de seguridad han ido convergiendo en lo que un analista describió como la tríada mortal: la combinación de acceso a datos privados, exposición a contenido no confiable y la capacidad de realizar acciones externas. Cuando las tres están presentes simultáneamente en un solo agente, la superficie de ataque deja de ser teórica y se vuelve una certeza casi segura con suficiente presión adversaria. Para un agente de automatización de DeFi, esas tres propiedades no son casos límite: son la descripción básica del trabajo. El agente lee datos de mercado y fuentes externas, mantiene permisos de clave de sesión sobre una billetera financiada y ejecuta transacciones de forma autónoma. OpenAI, Anthropic y Google DeepMind reconocieron en publicaciones de 2025 que la inyección de prompts no puede resolverse completamente dentro de las arquitecturas actuales de grandes modelos de lenguaje, porque cualquier defensa expresada como instrucción en un prompt puede ser a su vez anulada por un ataque suficientemente elaborado. A veces me pregunto si las personas que despliegan agentes de IA para operaciones de tesorería onchain han leído esa frase con la atención suficiente, porque efectivamente dice que el propio modelo no puede ser la última línea de defensa.
La parte que sigo teniendo en mente es qué significa esto para dónde debe situarse realmente el límite de seguridad, y por qué la capa de aplicación previa al cierre (pre-settlement) de Newton aborda algo que las defensas puramente a nivel de modelo no pueden resolver de forma estructural. El consenso que está emergiendo de la investigación en seguridad es que el enfoque correcto no es un mejor filtrado de prompts, sino la aplicación determinista de políticas en la capa de herramientas (tool layer), que limita lo que el agente puede hacer con sus derechos de ejecución independientemente de qué instrucciones haya recibido o de quién. Las listas de beneficiarios (payee) aprobados de Newton, los topes de gasto y las políticas de cumplimiento de mandatos no son funciones que el propio agente aplique; son restricciones externas evaluadas por una red neutral de operadores antes de que la transacción llegue a la cadena. Un agente comprometido que haya sido inyectado con instrucciones para transferir fondos a una dirección del atacante sigue pasando por la comprobación de políticas de Newton antes de que esa transferencia se asiente, y si la dirección de destino queda fuera de la lista de beneficiarios aprobados, la transacción se bloquea de manera independiente de lo que el agente crea que estaba autorizado a hacer. La pregunta que me viene a la mente es si esta distinción—entre confiar en el agente y constreñir lo que el agente realmente puede ejecutar—está siendo comprendida con la claridad suficiente por los desarrolladores que actualmente construyen sistemas de automatización onchain para entornos de producción.
Mirando desde fuera hacia dónde se dirige esta conversación, hay una dimensión temporal que se siente importante y poco valorada. La comunidad de investigación en seguridad está documentando activamente ataques en los que un único documento inyectado en una base de datos vectorial logra un noventa por ciento de éxito del ataque, donde el envenenamiento de memoria crea ataques diferidos que persisten a través de sesiones, y donde los sistemas multiagente pasan instrucciones comprometidas entre ellos de maneras que hacen casi imposible rastrear el punto de inyección original después de los hechos. Toda esa investigación está madurando exactamente al mismo tiempo en que los agentes de IA en cadena (onchain) pasan de despliegues experimentales pequeños a sistemas que gestionan capital significativo en protocolos reales. La llegada de la beta de Newton a la red principal en esta ventana específica se siente menos como coincidencia y más como si el protocolo hubiera encontrado la unión entre dos campos, la seguridad de IA y las finanzas en cadena, que se han estado desarrollando en paralelo sin reconocer del todo qué tan directamente se intersectan. Si los desarrolladores que construyen la próxima generación de agentes financieros tratan la aplicación de políticas previa al cierre (pre-settlement) como un requisito fundamental o descubren su necesidad por la vía difícil, es una pregunta que honestamente aún no sé responder; en todo caso, el tiempo lo dirá...