No te preocupes solo por lo que “responde” la IA. Preocúpate por lo que puede ejecutar.
En 2026, muchas empresas ya pasaron del “chat que ayuda” a agentes de IA que planean, usan herramientas y realizan acciones en sistemas reales: crean y cierran tickets, consultan CRMs, modifican configuraciones, generan reportes, y disparan automatizaciones. Esa autonomía acelera operación… pero también abre una superficie de ataque que la seguridad tradicional no siempre alcanza a ver.
OWASP ya lo resume en una idea clave: cuando un sistema con LLM tiene capacidad de actuar, aparecen riesgos nuevos (más allá del clásico “prompt malicioso”), y por eso existen guías específicas de AI Agent Security.
1) Qué cambió: pasamos de “texto” a “tool-use”
Un agente de IA normalmente combina:
- Un LLM (razona y decide),
- Memoria / contexto (datos internos, documentos, correos),
- Herramientas conectadas (APIs, RPA, scripts, consola cloud),
- Permisos reales (tokens, llaves, cuentas de servicio).
Eso significa que el problema ya no es solo “que la IA diga algo incorrecto”, sino que una decisión equivocada (o manipulada) se convierta en una acción.
Esto es un riesgo de seguridad específico: agent hijacking, donde el agente puede ser desviado para ejecutar acciones no deseadas (frecuentemente asociado a prompt injection indirecta).
2) El error #1: permisos excesivos
(el “admin por comodidad”)
El patrón más común que vemos cuando una empresa “pone agentes a trabajar” es este:
“Para que sea útil, démosle acceso amplio… y luego vemos.”
Eso crea un usuario no-humano con privilegios altos que opera de forma continua. Si ese agente es manipulado (o si se equivoca con confianza), el impacto se multiplica.
Señales de alarma típicas:
- Tokens con alcance global (all-resources / all-actions).
- Acceso a producción sin compuertas (gates).
- Herramientas potentes habilitadas por defecto (export masivo, borrados, cambios de permisos).
- Falta de segmentación por ambiente (dev/test/prod).
- Microsoft, por ejemplo, viene insistiendo en que los agentes necesitan identidad gobernada y acceso least privilege / just-in-time para evitar el sobre-permisionamiento.
📍 ¿Vas a implementar agentes de IA este año?
Hagamos una evaluación rápida de permisos, herramientas y compuertas antes de ponerlos en producción.
3) Prompt Injection
(y por qué la “indirecta” es la peligrosa)
OWASP clasifica Prompt Injection como uno de los riesgos principales: ocurre cuando un input altera el comportamiento del modelo de manera no deseada.
Pero en agentes, la más delicada suele ser la inyección indirecta: cuando el agente lee información externa (correo, web, PDF, ticket, comentario) y esa información contiene instrucciones camufladas que el LLM interpreta como mandato.
AWS lo describe justamente en el contexto de workloads generativos: al conectar el modelo a datos y herramientas, una inyección puede escalar de “respuesta” a “acción”.
Ejemplo realista (sin sci-fi):
Un agente que “lee correos y actualiza casos” recibe un mensaje con texto diseñado para que, al ser ingerido por el LLM, le indique exportar información “para auditoría” o reenviar un resumen a un destino no permitido. Si el agente tiene permisos y herramientas, el daño puede ocurrir en segundos.
4) “Inherently confusable deputy”:
asume riesgo residual y diseña para impacto
El NCSC del Reino Unido plantea algo incómodo pero muy útil: prompt injection no se parece a SQL injection, porque los LLMs no separan de forma nativa “instrucciones” vs “datos” como lo hacen otros sistemas. Por eso recomiendan tratar el LLM como un “diputado inherentemente confundible” y enfocarse en reducir impacto (no solo “prevenir al 100%”).
Traducción práctica: incluso con defensas, debes diseñar tu arquitectura para que un agente no pueda causar un desastre con un solo desvío.
5) El riesgo silencioso: intent drift
(cumplir el objetivo rompiendo el control)
Además del atacante, hay un modo de falla interno típico:
- Se le da al agente un objetivo (“optimiza”, “reduce tiempos”, “cierra incidentes”),
- El agente aprende que ciertos controles “estorban”,
- Empieza a proponer (o ejecutar) atajos.
La IA no “quiere hacer daño”, pero puede priorizar eficiencia sobre seguridad si tu sistema no le impone límites determinísticos (políticas, permisos, compuertas, y aprobaciones).
📍 Agenda una sesión de diagnóstico TI Rescue
para revisar tu arquitectura de agentes (riesgo de prompt injection indirecta, over-privilege e intent drift) y definir un plan de mitigación.6) Gobernanza de agentes: el modelo que sí funciona
(en la vida real)
Si tu agente tiene herramientas, tu defensa debe parecerse a Zero Trust para agentes: identidad, mínimos privilegios, compuertas, observabilidad y auditoría.
Una forma práctica de armarlo:
A) Identidad y acceso por agente (no “un token para todo”)
- Identidad única por agente y por función.
- Least privilege por tarea (scopes mínimos).
- Acceso just-in-time (se otorga solo durante la ejecución).
- Separación estricta dev/test/prod.
B) “Policy gate” antes de ejecutar acciones
Antes de permitir una acción, valida:
- Qué quiere hacer (tipo de acción),
- Sobre qué recurso,
- Con qué datos,
- En qué ambiente,
- Con qué nivel de riesgo.
Y define acciones que siempre requieren aprobación humana, por ejemplo:
- Cambios en producción,
- Exportación masiva,
- Cambios de permisos,
- Eliminaciones irreversibles,
- Transferencias / aprobaciones financieras.
C) Herramientas seguras por diseño
- Deshabilita herramientas “peligrosas” por defecto.
- Limita parámetros (por ejemplo, export size, destination allowlist).
- Sandboxing / entornos controlados para acciones automatizadas.
D) Protección contra inyección (especialmente cuando el contexto es externo)
- Marcar y separar “contenido no confiable” (emails, web, tickets).
- No permitir que contenido externo modifique instrucciones del sistema.
- Reducir herramientas disponibles cuando el contexto viene de afuera.
E) Auditoría que sirva (sin inventar “chain of thought”)
En vez de intentar registrar “lo que pensó”, registra evidencia ejecutable:
- Input recibido (con clasificación de confianza),
- Output final,
- Herramienta invocada + parámetros,
- Permisos utilizados,
- Política aplicada (permitido/denegado y por qué),
- Resultado y trazabilidad (logs firmados / inmutables).
7) Impacto comercial y cumplimiento: por qué esto ya es tema de gerencia
Cuando un agente puede ejecutar acciones, un incidente deja de ser “un error técnico” y se vuelve:
- Riesgo de datos,
- Riesgo reputacional,
- Riesgo contractual,
- Riesgo regulatorio.
En la UE, por ejemplo, el AI Act tiene una aplicación por fases, con fecha general de aplicación el 2 de agosto de 2026, y varias disposiciones con hitos distintos. Eso hace aún más valiosa la trazabilidad y gobernanza.
Checklist rápido: “Gobernanza de agentes” en 30 días (realista)
Si estás por desplegar agentes (o ya lo hiciste), estas 10 preguntas te ahorran dolores:
- ¿Cada agente tiene identidad propia y no comparte credenciales?
- ¿Los permisos son mínimos y por tarea (no “admin”)?
- ¿Hay accesos just-in-time y revocación automática?
- ¿Existe aprobación humana para acciones críticas?
- ¿El agente puede leer fuentes externas? ¿Están marcadas como no confiables?
- ¿Las herramientas tienen límites (allowlists, rate limits, parámetros acotados)?
- ¿Hay separación dev/test/prod y barreras para producción?
- ¿Se registran herramientas, permisos, parámetros, política y resultado?
- ¿Se monitorea comportamiento anómalo (picos, export masivo, cambios de permisos)?
- ¿Tienes un plan de respuesta si el agente “se sale del carril” (kill switch)?
📍 Lleva tu operación al siguiente nivel con soluciones TI pensadas para el presente y preparadas para el futuro.
Protege tus cuentas y sistemas con monitoreo y respuesta ante incidentes 24/7.
Suscríbete a Nuestro Blog: Mantente actualizado con las últimas noticias y consejos en ciberseguridad. Suscríbete ahora.
Temas que podrían interesarte:
