Por qué los desarrolladores independientes de agentes de IA pasan por alto los riesgos de seguridad

En resumen La mayoría de los fallos de seguridad en agentes de IA en producción no son exploits exóticos: son riesgos que quienes construyen el agente nunca modelaron. Un estudio publicado en junio de 2026 (arXiv 2606.03190) entrevistó a desarrolladores independientes de agentes de IA sobre cómo razonan la seguridad y la privacidad. El hallazgo: los creadores piensan casi exclusivamente desde la perspectiva del usuario, reduciendo la seguridad a «¿la salida es dañina?», con poca conciencia de los riesgos adversarios como la inyección de prompts, el abuso de herramientas o la exfiltración. Las protecciones que aplican son artesanales, inconsistentes e incompletas. Es un hallazgo de factores humanos, no un exploit, pero explica por qué tantos de los ataques que documentamos siguen funcionando.

¿De qué se trata?

El artículo Focused on the User, Overlooking the Risks (arXiv 2606.03190, junio de 2026) es un estudio basado en entrevistas con desarrolladores independientes que construyen y despliegan agentes de IA: los creadores en solitario y los equipos pequeños detrás de buena parte de los asistentes, automatizaciones y aplicaciones «al estilo GPT» hoy en producción. En lugar de probar modelos, los investigadores preguntaron a quienes construyen sobre ellos cómo entienden la seguridad y la privacidad, qué hacen realmente al respecto y dónde se atascan.

El resultado principal es un desajuste estructural entre el modelo mental de los desarrolladores y la superficie de amenaza real. Los creadores razonan desde la perspectiva de sus usuarios finales y optimizan una seguridad de cara al usuario: evitar que el agente diga algo dañino, ofensivo o fuera de marca. Ese encuadre desplaza la perspectiva adversaria, donde la amenaza no es el usuario sino un tercero que coloca instrucciones en una página web, un documento, el resultado de una herramienta o un almacén de memoria.

Qué encontró el estudio

Destacan tres observaciones, todas coherentes con lo que ven los defensores en la práctica.

Primero, la seguridad se confunde con la moderación de contenido. Al preguntarles por «seguridad», los desarrolladores recurren al filtrado de salidas dañinas y rara vez mencionan la inyección, la exfiltración o las fronteras de privilegio. El riesgo de seguridad y los límites de capacidad del modelo se mezclan, de modo que una vulnerabilidad de arquitectura parece, para el creador, un problema de calidad que se suaviza con un mejor prompt.

Segundo, las defensas son manuales y improvisadas. El estudio indica que los desarrolladores dependen casi exclusivamente de soluciones hechas a mano —redacción de prompts a medida, comprobaciones de entrada puntuales—, inconsistentes e incompletas entre proyectos. Hay poco uso de barreras sistemáticas y automatizadas, y pocas pruebas adversarias antes del lanzamiento.

Tercero, los flujos de datos transfronterizos son un riesgo no gestionado. Como muchos desarrolladores independientes conectan sus agentes a API de LLM globales y atienden a usuarios en varias jurisdicciones, los datos del usuario cruzan fronteras de forma rutinaria sin un modelo de privacidad explícito. El estudio lo plantea como un problema de ecosistema global, no local: el mismo patrón aparece allí donde equipos pequeños construyen sobre modelos de frontera alojados.

El panorama coincide con otro esfuerzo de medición de junio de 2026, el AI Agent Index alojado en Cambridge, que halló que la mayoría de los agentes desplegados se entregan sin información básica de seguridad y de riesgo. Ambos resultados describen la misma brecha desde dos extremos: creadores que no modelan el riesgo y productos que no lo documentan.

Por qué importa

Casi todas las clases de ataque de este sitio asumen un defensor que ha pensado en el ataque: el trío letal, la inyección de prompts indirecta, el envenenamiento de descripciones de herramientas, el envenenamiento de memoria. Este estudio es la explicación, del lado de la oferta, de por qué esos ataques siguen siendo tan productivos: una amplia población de creadores de agentes sencillamente no modela al adversario. No se puede limitar, aislar ni filtrar un riesgo que no se ha representado.

También reorienta dónde invertir en defensa. Si la brecha es de conciencia y de herramientas, y no de malicia o incompetencia, entonces los frameworks seguros por defecto, los arneses de pruebas adversarias integrados y unos ajustes de privacidad claros aportan mucho más que otra entrada de blog de concienciación. La solución debe vivir en las plataformas y bibliotecas que los desarrolladores ya usan, porque es la única capa que alcanza a quienes nunca buscaron un modelo de amenaza.

Defensas

Las implicaciones del propio estudio apuntan a la automatización, las pruebas y la rendición de cuentas. En concreto, para cualquiera que despliegue agentes:

1. Adopte un modelo de amenaza real, no un filtro de contenido. Trate cada entrada externa que el agente lee —páginas web, archivos, salidas de herramientas, documentos recuperados, memoria previa— como controlada por un atacante. El filtrado de salidas dañinas es necesario, pero no es seguridad.

2. Use patrones estructurales, no redacción de prompts. Apóyese en los design patterns de agentes restringidos (mínimo privilegio, listas de acciones permitidas, separar la planificación de la ejecución de herramientas, aprobación humana para acciones irreversibles) en lugar de intentar redactar un prompt de sistema «seguro». Un prompt blindado aporta poca robustez.

3. Haga que las pruebas adversarias sean automáticas. Añada casos de inyección y exfiltración a la CI para que el agente sea atacado en cada cambio, no revisado una sola vez a mano. Las comprobaciones manuales, proyecto por proyecto, son justo lo que el estudio considera inconsistente.

4. Modele explícitamente el flujo de datos transfronterizo. Documente qué proveedor ve qué datos, dónde se procesan y qué sale de la jurisdicción del usuario. Por defecto, minimice lo que el agente reenvía a modelos alojados.

5. Publique información de riesgo. Declare las capacidades del agente, los datos que maneja y sus limitaciones conocidas: lo que el AI Agent Index halló mayormente ausente. La divulgación es barata y obliga a la conversación de modelado de amenazas.

Estado

Elemento	Referencia	Fecha	Notas
Focused on the User, Overlooking the Risks	arXiv 2606.03190	2026-06	Estudio por entrevistas; modelo mental centrado en el usuario, baja conciencia de seguridad, defensas manuales/improvisadas
AI Agent Index — divulgaciones de seguridad	University of Cambridge	2026-06	La mayoría de los agentes desplegados se entregan sin información básica de seguridad/riesgo
Design patterns para asegurar agentes LLM	arXiv 2506.08837	2025-06	Patrones de agentes restringidos citados como la alternativa estructural

El encuadre útil no es «los desarrolladores son descuidados». Es que el modelo mental dominante de la seguridad de los agentes —mantener la salida limpia para el usuario— no contiene al adversario, y las herramientas a las que recurren la mayoría de los creadores no lo añaden. Hasta que unos valores por defecto seguros y unas pruebas automatizadas cierren esa brecha a nivel de framework, los ataques documentados aquí seguirán encontrando superficie no modelada.