Anthropic y otros modelos de lenguaje pueden invocar herramientas ocultas sin permiso

El principal riesgo de los LLM agentivos hoy no es que a veces cometan errores con parámetros de función, sino que con una arquitectura deficiente pueden invocar una herramienta que formalmente nunca les fue otorgada. Si tal función existe en el entorno, el modelo es capaz de adivinar su nombre, inventar argumentos y conseguir un efecto secundario real: leer un secreto, escribir un mensaje, acceder a la API de otro. En papel, los derechos de acceso se ven limitados, pero en la práctica el límite entre permitido y prohibido se vuelve probabilístico.

Para sistemas donde el modelo trabaja con datos, correo, documentos o integraciones corporativas, esto deja de ser una curiosidad y se convierte en un riesgo de seguridad. El problema se manifiesta en la combinación de un modelo agentivo y entorno cliente, donde la lista de herramientas permitidas y el namespace real divergen. En una demostración, al modelo se le dio solo read_url, pero en el entorno existía una función read_secret.

Tras una pista como from dialoghelper import *, el modelo decidió que tenía acceso a read_secret e intentó invocar esa herramienta. Si la biblioteca o API verifica solo el formato de la llamada y no coteja estrictamente el nombre de la función con el esquema emitido, la solicitud sigue adelante. El autor mostró un comportamiento similar no solo en Anthropic, sino en escenarios específicos también en Gemini, Grok y a través de envolturas multi-proveedor.

En otras palabras, la vulnerabilidad surge no en una marca, sino en la intersección de modelo, SDK y andamiaje agentivo. El peligro aumenta drásticamente cuando tal sistema cae en la llamada tríada mortal: el modelo tiene acceso a herramientas externas, contenido no confiable y datos privados. Entonces la inyección de prompt deja de ser simplemente una característica molesta y se convierte en un canal de fuga.

Es suficiente que un atacante incruste una instrucción en un correo, página web o documento, y el modelo, confiado en tener una herramienta oculta, él mismo alcanza el secreto y lo envía hacia afuera. Especialmente desagradable es que la separación arquitectónica en la que confían los desarrolladores puede dar una falsa sensación de seguridad: una herramienta sensible parece no estar incluida en el conjunto, pero físicamente se encuentra cerca en el entorno y se vuelve accesible a través de una llamada no autorizada. Detectar tal fallo es difícil.

En muchos casos el modelo se comporta correctamente y rechaza la llamada prohibida, luego de repente falla por una nimiedad en el contexto: la formulación de una pista, historial de mensajes o incluso el nombre de un módulo. El artículo proporciona un ejemplo ilustrativo donde la misma acción a veces se bloquea, a veces pasa después de una mención inofensiva de dialoghelper. La decodificación estructurada reduce parcialmente el riesgo porque obliga al modelo a ajustarse a un esquema, pero también hay compromisos aquí: aumento de latencia, límites estrictos en el número de strict-tools y degradación del rendimiento en conjuntos grandes de funciones.

Por lo tanto, confiar solo en el comportamiento inteligente del modelo es imposible. La verificación del nombre de la herramienta debe ocurrir en el lado del proveedor y en el código cliente antes de la ejecución real. La conclusión práctica es simple: si estás construyendo un agente sobre MCP, Jupyter, SDK internos o cualquier otro entorno dinámico, no es suficiente ocultar funciones adicionales de la descripción y esperar la disciplina del modelo.

Necesitas validar estrictamente cada llamada de herramienta, separar operaciones sensibles de contenido no confiable y mantener el espacio de ejecución más estrecho que la visibilidad del LLM. De lo contrario, un único read_secret o add_msg adivinado convierte una arquitectura agentiva ordenada en un sistema donde los derechos de acceso existen solo hasta la primera alucinación exitosa. La buena noticia es que la corrección no se ve complicada: es suficiente rechazar cualquier llamada cuyo nombre esté ausente del esquema permitido antes de pasarla al runtime.

Algunas líneas de código defensivo en una biblioteca o puerta de enlace pueden cerrar una clase de problemas que de otro modo se disimularía como una alucinación rara, pero de hecho rompe el modelo de confianza de todo el sistema.