Acceso seguro de los LLM a herramientas: controlar lo que pueden hacer los agentes
En el momento en que dejas que un gran modelo de lenguaje llame a herramientas (que use API, consulte bases de datos, ejecute código, realice acciones), dejas de tener un chatbot y pasas a tener un agente con una capacidad real en tu entorno. Esa capacidad es lo que se busca, y también es donde se concentra el riesgo: a un LLM se le puede dirigir con una entrada no confiable para que haga un mal uso de las mismas herramientas que le concediste. Proteger el acceso de los LLM a las herramientas consiste en acotar ese poder.
Por qué es arriesgado
Un LLM no puede distinguir de forma fiable las instrucciones de los datos. Si procesa contenido no confiable (una página web, un documento, un correo, el resultado de una herramienta) que contiene instrucciones inyectadas, puede actuar según ellas y usar sus herramientas para exfiltrar datos o realizar acciones dañinas. No puedes evitarlo del todo, así que contienes su impacto.
Los controles básicos
- Mínimo privilegio: limita cada herramienta a la capacidad y los datos mínimos que necesita; de solo lectura siempre que sea posible.
- Aprobación humana para las acciones de alto impacto: las acciones destructivas o irreversibles (borrar datos, enviar mensajes al exterior, mover dinero) requieren a una persona, para que un agente secuestrado no pueda ejecutarlas por su cuenta. Esto importa sobre todo en los agentes personales siempre activos que mantienen sesiones iniciadas en el navegador, como Open Dot.
- Aislamiento: limita a qué pueden llegar las herramientas: red, sistema de archivos, datos.
- Trata las salidas como no confiables: la salida del modelo y los resultados de las herramientas que alimentan otros sistemas deben validarse, no darse por buenos.
- Registra cada llamada a una herramienta: logs completos y revisables para la detección y la auditoría.
Para los agentes basados en MCP
Si tus agentes usan el Model Context Protocol, aplica los mismos controles a cada servidor MCP: lista de servidores aprobados, mínimo privilegio, autenticación, aprobación de las acciones de alto impacto y registro de todo.
Gobierna el acceso a herramientas y servidores con MCP Guard →, evalúa un servidor concreto con MCP Server Risk, consulta la base de controles en los controles de gobierno de MCP y modela las amenazas de la función con el AI Threat Model.
Preguntas frecuentes
¿Por qué es arriesgado? El acceso a herramientas da al modelo una capacidad real, y la inyección de prompts puede llevarlo a hacer un mal uso de esas herramientas.
¿Controles básicos? Mínimo privilegio, aprobación humana para las acciones de alto impacto, aislamiento, tratar las salidas como no confiables y registro.
¿Relación con la inyección de prompts? La inyección es el mecanismo; el mínimo privilegio y las aprobaciones contienen su impacto.
¿Cómo empezar? Inventaría las herramientas, limítalas al mínimo privilegio, somete a aprobación las acciones destructivas, aísla, trata las salidas como no confiables y registra; y aplica lo mismo a los servidores MCP.
Preguntas frecuentes
¿Por qué el acceso de los LLM a herramientas es un riesgo de seguridad?
Porque da al modelo una capacidad real en tu entorno, y el modelo se puede manipular. Si un LLM procesa contenido no confiable (una página web, un documento, un correo o el resultado de una herramienta) que contiene instrucciones inyectadas, se le puede dirigir para que llame a sus herramientas de forma dañina: exfiltrando datos, realizando acciones destructivas o escalando el acceso. Las herramientas que concedes para un uso legítimo se convierten en la superficie de ataque, y por eso hay que controlar estrictamente el acceso.
¿Cuáles son los controles básicos para un acceso seguro de los LLM a herramientas?
El mínimo privilegio (cada herramienta limitada a la capacidad y los datos mínimos necesarios, de solo lectura siempre que sea posible); la aprobación con una persona en el bucle para las acciones de alto impacto o irreversibles; el aislamiento, para que las herramientas solo puedan llegar a lo que deben; tratar la salida del modelo y los resultados de las herramientas como entradas no confiables para los sistemas posteriores; y un registro completo de cada llamada a una herramienta para la detección y la auditoría. Juntos limitan lo que puede hacer realmente un agente secuestrado.
¿Qué relación tiene la inyección de prompts con el acceso a herramientas?
La inyección de prompts es el mecanismo que hace peligroso el acceso a herramientas. Un atacante coloca instrucciones en el contenido que el agente va a procesar, y el agente, incapaz de distinguir de forma fiable las instrucciones de los datos, puede actuar según ellas y usar sus herramientas para hacer lo que quiere el atacante. Como no puedes evitar del todo la inyección, contienes su impacto limitando lo que pueden hacer las herramientas (mínimo privilegio) y exigiendo la aprobación de una persona para todo lo que tenga consecuencias.
¿Cómo empiezo a proteger el acceso a herramientas de nuestros agentes de IA?
Inventaría a qué herramientas puede llamar cada agente y a qué pueden llegar, limita cada herramienta al mínimo privilegio, exige la aprobación de una persona para las acciones destructivas o sensibles, aísla la ejecución de las herramientas, trata todas las salidas como no confiables y registra cada llamada a una herramienta. En los agentes que usan el Model Context Protocol, aplica los mismos controles a cada servidor MCP: lista de permitidos, mínimo privilegio, autenticación, aprobaciones y registro.