A medida que los agentes de IA ganaron acceso real a sistemas de producción durante 2026, los ataques de prompt injection dejaron de ser una curiosidad académica y se convirtieron en un vector de incidente documentado.
Durante años, la inyección de prompts fue discutida principalmente como riesgo teórico en papers de seguridad. En 2026, varios incidentes documentados públicamente confirmaron el patrón de ataque más temido: un agente con acceso a herramientas (correo, calendario, sistemas internos) procesa contenido externo no confiable —un correo, una página web, un documento adjunto— que contiene instrucciones ocultas diseñadas para manipular al agente y hacerle ejecutar una acción no autorizada por el usuario legítimo.
A diferencia del jailbreak clásico (donde el atacante manipula directamente su propia conversación con el modelo), la inyección indirecta ataca a través de contenido que el agente consume como parte de su trabajo normal: un archivo compartido con instrucciones ocultas en texto blanco sobre fondo blanco, un comentario en un repositorio de código con una directiva disfrazada de comentario técnico, o metadatos de un documento que el agente procesa sin que el usuario los vea directamente. El denominador común es que el agente no puede distinguir fácilmente entre "instrucciones del usuario que debo seguir" y "contenido de un documento que debo solo leer y resumir".
El crecimiento del ecosistema de Model Context Protocol trajo consigo una variante específica: servidores MCP maliciosos o comprometidos que describen sus herramientas de forma engañosa, incluyendo instrucciones ocultas en la descripción de una tool que el modelo lee como parte de su contexto de decisión. Casos documentados en el registro público de MCP durante 2026 llevaron a la introducción de firmas criptográficas para servidores verificados, cubierto en detalle en nuestro artículo sobre el aniversario del protocolo.
La respuesta de la industria convergió en un conjunto de prácticas que en 2026 ya se consideran mínimas para cualquier agente con acceso a herramientas de efectos secundarios: separación explícita entre contenido de confianza (instrucciones del sistema y del usuario autenticado) y contenido no confiable (documentos, páginas web, resultados de búsqueda), delimitado con marcadores claros en el prompt; aprobación humana obligatoria antes de acciones irreversibles o de alto impacto (envío de correos, transferencias, eliminación de datos); y clasificadores dedicados de detección de instrucciones sospechosas dentro de contenido que el agente procesa como datos, no como órdenes.
Un error común es asumir que la seguridad contra prompt injection es responsabilidad exclusiva de Anthropic, OpenAI o Google. En la práctica, la mitigación más efectiva vive en la arquitectura de la aplicación: qué herramientas se le dan a un agente, con qué alcance de permisos, y qué pasos requieren confirmación humana antes de ejecutarse — decisiones que corresponden al equipo que construye el agente, no al proveedor del modelo subyacente. Para empresas en Guatemala que están desplegando sus primeros agentes con acceso a sistemas reales, la recomendación concreta es tratar cada herramienta que se le da a un agente con el mismo rigor de revisión de seguridad que un endpoint de API expuesto públicamente, porque en la práctica eso es exactamente lo que es.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel