LangChain, LangGraph, LlamaIndex, CrewAI y AutoGen: seguridad de aplicaciones agentivas personalizadas
Con LangChain, LangGraph, LlamaIndex, CrewAI y AutoGen, el equipo no solo utiliza un asistente de codificación: construye aplicaciones en las que un LLM razona, recupera contexto, utiliza herramientas, llama a APIs y coordina pasos. La superficie de seguridad ya no es solo la de una aplicación web o un modelo aislado, sino que abarca el tiempo de ejecución (runtime) agentivo, las herramientas, la memoria, la recuperación (retrieval) y los permisos que los gobiernan.
La cuestión no es decidir si la IA es una buena o mala elección para el desarrollo. El punto es mucho más práctico: entender qué controles se necesitan cuando un resultado generado o acelerado por IA entra en un producto, un flujo de trabajo empresarial o un entorno con datos reales. Este artículo se dirige a fundadores, CTOs, desarrolladores y equipos de TI/seguridad que construyen aplicaciones agentivas personalizadas y quieren entender dónde concentrar los controles: abuso de herramientas, envenenamiento de RAG (RAG poisoning), envenenamiento de memoria, permisos y salidas no validadas.
Por qué una aplicación que funciona no es necesariamente segura
Las herramientas de IA reducen el tiempo necesario para crear código, interfaces, flujos de trabajo, pruebas y configuraciones. Sin embargo, esta velocidad puede comprimir los pasos que normalmente hacen que el software sea confiable: modelado de amenazas, revisiones, gestión de secretos, controles de roles, validación de entradas, verificación de dependencias y pruebas manuales de rutas críticas.
Una demostración funciona con un solo usuario, datos ficticios y permisos implícitos. La misma lógica puede fallar cuando llegan clientes reales, múltiples inquilinos (tenants), diferentes roles, APIs públicas, integraciones, datos personales, pagos o automatizaciones con efectos externos. Por eso, la seguridad debe evaluarse según el comportamiento real de la aplicación, no por la promesa de la herramienta que la generó.
Llamada a herramientas (Tool calling) y permisos excesivos
Cada herramienta concedida al agente es un permiso de aplicación en toda regla. La lectura, escritura, correo electrónico, tickets, bases de datos, shell o CRM deben tener un alcance (scope) mínimo, políticas externas al modelo, registros de auditoría (audit logs) y confirmación explícita para acciones sensibles. Delegar al prompt la gestión de los permisos es uno de los errores más comunes y peligrosos en las aplicaciones agentivas: las reglas críticas deben residir en el código, las políticas y los controles del lado del servidor, no en el system prompt.
RAG, memoria y contexto no confiable
Los documentos, tickets, páginas web, correos electrónicos y bases de conocimiento pueden contener instrucciones hostiles. La recuperación (retrieval) debe filtrar por autorización y el contenido recuperado no debe poder sobrescribir las políticas del sistema o los permisos del usuario. El riesgo de envenenamiento de RAG y envenenamiento de memoria entre sesiones o inquilinos es concreto y a menudo subestimado: un documento malicioso insertado en la base de conocimiento puede alterar el comportamiento del agente de manera indetectable sin pruebas específicas.
Manejo de salidas y decisiones automatizadas
La salida del modelo no debe utilizarse directamente para generar HTML, construir consultas, ejecutar comandos, llamar a APIs, gestionar autorizaciones o tomar decisiones irreversibles. Se requiere validación estructurada, esquemas, listas de permitidos (allowlist), entornos aislados (sandbox) y pruebas con entradas maliciosas antes de que cualquier salida llegue a un sistema real.
Principales riesgos a controlar
Los riesgos que siguen no son teóricos: se refieren al comportamiento concreto de la aplicación con datos reales y deben verificarse mediante evidencias, configuración, comportamiento en tiempo de ejecución e impacto efectivo.
- Inyección de prompt directa e indirecta: instrucciones hostiles inyectadas en el prompt o en los documentos recuperados por el sistema.
- Abuso de herramientas con permisos excesivos: agentes que pueden realizar acciones no autorizadas porque las herramientas no tienen un alcance limitado.
- Envenenamiento de RAG y documentos hostiles: contenido malicioso en la base de conocimiento que altera el comportamiento del agente.
- Envenenamiento de memoria entre sesiones o inquilinos: contaminación de la memoria persistente que influye en sesiones posteriores o en diferentes usuarios.
- Divulgación de información sensible: datos sensibles expuestos a través de salidas, registros o respuestas del modelo.
- Salida no validada hacia APIs o shell: resultados del modelo utilizados directamente como entrada para sistemas externos sin saneamiento.
- Autorizaciones delegadas al prompt: lógica de control de acceso confiada al system prompt en lugar de a políticas del lado del servidor.
Estos riesgos deben vincularse al perímetro concreto de la aplicación. Una aplicación expuesta requiere pruebas de aplicación manuales; un cambio crítico en el código requiere revisión; un flujo de trabajo interno requiere control de permisos y credenciales; una aplicación agentiva requiere pruebas de prompts, herramientas y salidas. La combinación correcta depende del impacto real, no del nombre de la herramienta utilizada para construirla.
Controles mínimos antes del lanzamiento (go-live)
- Mapear usuarios, roles, datos reales, integraciones, entornos y propietarios del servicio.
- Identificar qué partes fueron generadas o modificadas con IA y quién las revisó.
- Verificar autorizaciones del lado del servidor, aislamiento de inquilinos y funciones administrativas.
- Buscar secretos en el código, prompts, registros, variables de entorno, compilaciones y el historial del repositorio.
- Controlar dependencias, licencias, paquetes, plantillas, complementos y componentes generados.
- Probar entradas hostiles, manejo de errores, registro de eventos (logging), límites de tasa (rate limits) y rutas no previstas.
- Separar correcciones bloqueantes, remediación planificada y riesgo residual aceptado.
- Repetir la prueba o re-test después de correcciones que afecten flujos críticos.
Cuándo se necesita una verificación independiente
Se necesita una verificación independiente cuando la aplicación o el flujo de trabajo maneja datos reales, usuarios externos, roles, APIs, integraciones empresariales, pagos, almacenamiento, flujos de trabajo automáticos o código crítico generado con IA. También es necesaria cuando el equipo no puede demostrar qué partes han sido revisadas y qué controles bloquean regresiones o abusos.
Para aplicaciones agentivas, el perímetro recomendado incluye: Pruebas de Aplicaciones de IA (AI Application Testing), Revisión de Código (Code Review) y Revisión de Arquitectura Segura (Secure Architecture Review). La revisión más útil no es genérica: debe producir hallazgos reproducibles, prioridades de remediación, indicación del riesgo residual y, cuando sea necesario, re-test después de las correcciones.
Preguntas operativas para fundadores, CTOs y equipos de seguridad
- ¿Qué datos reales entran en el sistema y dónde se guardan, registran o envían?
- ¿Qué roles existen y qué acciones están bloqueadas del lado del servidor, no solo en la interfaz?
- ¿Qué secretos, tokens, webhooks o credenciales permitirían el acceso a sistemas críticos?
- ¿Qué partes fueron generadas o modificadas por la IA y cuáles fueron revisadas por una persona competente?
- ¿Qué pruebas cubren abusos, errores, diferentes roles y diferentes inquilinos, no solo el camino feliz?
- ¿Qué evidencia puede mostrarse a clientes, auditorías, compras o dirección?
Información útil adicional
- Pruebas de Aplicaciones de IA: profundiza en metodologías y perímetro de pruebas en aplicaciones que integran LLMs, sin duplicar el enfoque de este artículo.
- OWASP Top 10 Agentic AI: visión general de los riesgos clasificados por OWASP para aplicaciones agentivas, útil como referencia normativa y de priorización.
- Riesgos de servidores MCP y agentes de codificación: análisis específico de los riesgos relacionados con los servidores del Protocolo de Contexto de Modelo (MCP) y los agentes de codificación.
- Seguridad de API keys y flujos de trabajo de IA: guía para la gestión segura de credenciales en flujos de trabajo que integran modelos de IA.
Preguntas frecuentes (FAQ)
- ¿Cuál es la diferencia entre una aplicación LLM y una aplicación agentiva?
- Una aplicación agentiva no se limita a responder a un prompt: recupera contexto, planifica, utiliza herramientas, llama a APIs o coordina pasos con efectos externos en sistemas reales.
- ¿Puede el prompt ser una barrera de seguridad?
- No. Las reglas críticas deben estar en el código, políticas, permisos y controles del lado del servidor. El system prompt puede guiar el comportamiento del modelo, pero no es un mecanismo de seguridad confiable.
- ¿Cómo se prueba la inyección de prompt indirecta?
- Insertando instrucciones hostiles en documentos, páginas, tickets o registros recuperados por el sistema y verificando las llamadas a herramientas, salidas y acceso a datos en las respuestas del agente.
- ¿Cuándo se necesitan pruebas de aplicaciones de IA?
- Cuando la aplicación integra LLMs, RAG, memoria, llamadas a herramientas, agentes o flujos de trabajo con acciones en sistemas reales, especialmente si maneja datos sensibles o usuarios externos.
- ¿Se necesita también una revisión de código?
- Sí. Es necesario leer autorizaciones, envoltorios de herramientas (tool wrappers), validación de salidas, recuperación, registro, gestión de secretos y límites operativos: aspectos que una prueba de aplicación por sí sola no cubre.
[Callforaction-CR-Footer]