Un agente de IA no es peligroso porque escriba texto convincente. Se vuelve peligroso cuando texto no confiable puede influir en acciones: llamadas de API, edición de archivos, consultas de base de datos, actualización de tickets, comandos de shell o mensajes enviados a otros sistemas. La seguridad de agentes empieza separando lo que el modelo puede leer de lo que el sistema puede ejecutar.
Prompt injection suele describirse como un problema de texto: una instrucción maliciosa escondida en un mensaje, página web, email, documento, issue de repositorio o fragmento recuperado por RAG. En sistemas con agentes, sin embargo, el riesgo real está en la ejecución. El ataque importa porque el modelo puede convertir contexto manipulado en una llamada de herramienta.
La página de OWASP sobre prompt injection lo presenta como una vulnerabilidad que apunta al comportamiento de los LLM. Para equipos backend, el siguiente paso es preguntar qué frontera del sistema recibe la salida del modelo. Si la respuesta es "una herramienta con permisos", prompt injection deja de ser solo comportamiento del modelo y pasa a ser un problema de autorización y control de flujo.
El trabajo de NIST en 2026 sobre seguridad de agentes de IA destaca riesgos de agentes que interactúan con datos adversariales, incluido el prompt injection indirecto. En un texto sobre red teaming, NIST describió el secuestro de agentes como un riesgo creciente cuando los agentes procesan fuentes externas como emails, sitios web y repositorios de código. Es exactamente ahí donde trabajan muchos agentes de ingeniería.
La seguridad clásica de aplicaciones asume que el código controla la ejecución. Los sistemas agentic agregan un planificador probabilístico entre el usuario y la acción. Ese planificador puede ser útil, pero no debe convertirse en la capa de enforcement. El enforcement debe vivir en código determinístico: políticas, schemas, allowlists, aprobaciones, sandboxing y logs.
La primera regla de diseño es la cuarentena de contexto. Instrucciones de sistema, políticas de desarrollador, intención del usuario, contenido recuperado, salidas de herramientas y documentos externos no son equivalentes. Deben representarse como clases distintas de datos y pasar por rutas de control distintas.
Una arquitectura segura trata el contenido no confiable como evidencia, no como autoridad. El agente puede resumirlo, citarlo y usarlo para proponer un plan. No debería permitir que ese contenido redefina políticas, conceda permisos, elija credenciales o elimine aprobaciones.
Prompt injection es una ruta hacia el abuso de herramientas, pero no la única. Un agente también puede usar herramientas de forma indebida por objetivos ambiguos, permisos demasiado amplios, retrieval defectuoso, schemas débiles, falta de validación o un modelo que optimiza la finalización de la tarea sin respetar límites operativos.
El OWASP MCP Top 10 destaca riesgos directamente relacionados con herramientas de agentes, incluidos command injection y prompt injection mediante payloads contextuales. Esto importa porque los servidores MCP y adaptadores de herramientas suelen estar cerca de sistemas poderosos: archivos, navegadores, bases de datos, CI, APIs cloud y paneles administrativos.
Los agentes no deberían recibir una capacidad genérica de "ejecutar comando" o "llamar API" salvo que el entorno esté fuertemente aislado y el radio de impacto sea intencionalmente pequeño. Las herramientas de producción deben ser estrechas: crear una issue en borrador, leer estado de despliegue, buscar una factura por ID, resumir logs del servicio X o abrir un pull request sin permiso de merge.
Esa es la diferencia entre exponer una cocina entera y exponer un botón. El agente no necesita toda la cocina para cada tarea. Necesita una operación segura, con entradas tipadas, políticas y salida predecible.
| Amenaza | Señal de ejemplo | Control backend |
|---|---|---|
| Prompt injection indirecto | Documento externo ordena al agente ignorar instrucciones anteriores. | Cuarentena de contexto, escaneo de prompt injection y prohibición de cambiar políticas desde contenido recuperado. |
| Agencia excesiva | El agente puede enviar emails, editar archivos y desplegar con un token amplio. | Alcances con forma de tarea, allowlists de herramientas y aprobaciones. |
| Manipulación de salida de herramienta | El resultado de una herramienta contiene instrucciones para guiar la siguiente acción. | Schemas estrictos de salida, escaping, etiquetas de confianza y validación secundaria. |
| Exfiltración de datos | El agente intenta enviar secretos a una URL externa o a un mensaje. | Revisiones DLP, controles de egress, redacción y allowlists de destino. |
| Bypass de política | El agente llama una API directa en vez del gateway aprobado. | Segmentación de red, credenciales centralizadas y acceso default-deny. |
Construiría un gateway de seguridad de agentes delante de toda herramienta privilegiada. El gateway recibiría llamadas propuestas, validaría el schema de entrada, clasificaría el riesgo, revisaría políticas, aplicaría allowlists de destino, exigiría aprobación cuando corresponda, ejecutaría la acción con una credencial acotada y escribiría un evento de auditoría inmutable.
Para un stack pequeño pero realista, usaría Cloudflare Workers para el gateway, FastAPI para herramientas internas de mayor riesgo, Supabase/Postgres para políticas y auditoría, y una cola para aprobaciones humanas. Cada herramienta tendría schema, nivel de riesgo, recursos permitidos, destinos permitidos y nivel máximo de autonomía.
La prevención no lo detecta todo. Los sistemas con agentes necesitan detección: acciones bloqueadas de forma repetida, secuencias inusuales de herramientas, acceso repentino a recursos sensibles, llamadas disparadas por contenido no confiable y salidas con secretos o destinos externos. Esto debe convertirse en métricas y alertas, no solo en logs que alguien quizá lea después.
Los mejores dashboards muestran actividad de agentes como operación de producción: volumen de acciones, intentos bloqueados, cola de aprobación, latencia de herramientas, llamadas de alto riesgo, principales fuentes externas y denegaciones recientes de política. Si un agente puede actuar, debe ser observable.
No le pidas al modelo que sea la frontera de seguridad. Pídele a sistemas determinísticos que sean esa frontera. El modelo puede proponer, explicar, resumir y redactar. El plano de control decide qué puede ejecutarse.
Artículo sobre seguridad de agentes de IA que cubre prompt injection, prompt injection indirecto, abuso de herramientas, agencia excesiva, seguridad MCP, cuarentena de contexto, gateways de herramientas, validación de schema, aprobación humana, controles de egress, logs de auditoría y detección en sistemas agentic.