Escucha este artículo aquí:
Durante el último par de años, muchas organizaciones empezaron a convivir con modelos de lenguaje (LLMs) como asistentes: redactan, resumen, responden dudas, ayudan a analizar información. En general, el riesgo se podía encerrar en un marco relativamente claro: lo que la IA “dice” puede ser incorrecto, puede filtrar información, o puede ser manipulada a través de prompts. Todo eso importa, pero tiene un límite: el LLM, por sí solo, no cambia tu realidad. Solo produce contenido.
La IA agente (agentic AI) rompe ese límite.
Radware lo plantea de forma contundente: los LLMs generan texto; la IA agente genera consecuencias. El salto de respuestas predictivas a acciones autónomas cambia por completo la ecuación de riesgo. Un agente acepta objetivos, planifica tareas en varios pasos, usa herramientas, llama APIs, actualiza registros y toma decisiones sin que necesariamente haya un humano aprobando cada movimiento.
Y cuando la IA puede actuar, la seguridad deja de ser un tema de “prompt y respuesta”. Se convierte en un tema de operación.
El “salto de autonomía”: por qué aquí cambia todo
Un LLM puede ayudarte a redactar un correo de atención al cliente. Un agente, en cambio, podría hacer algo como: consultar datos del cliente, validar un caso, emitir un reembolso, actualizar el CRM, y disparar un flujo de seguimiento. Ese ejemplo aparece como analogía directa en el texto de Radware, y es perfecto porque lo vuelve tangible: la IA ya no está en el dominio del contenido; está en el dominio de los procesos.
Ese cambio tiene tres implicaciones enormes para el riesgo:
1) La velocidad del error se comprime.
Entre un input malicioso y un resultado dañino puede pasar muy poco tiempo, porque el sistema está diseñado para ejecutar.
2) El “radio de impacto” crece.
Un mal prompt ya no solo produce una mala respuesta; puede desencadenar movimientos de datos, cambios en sistemas, decisiones operativas o impactos financieros.
3) El riesgo se vuelve sistémico.
El agente no vive aislado: se conecta a herramientas, identidades, memorias, pipelines, sistemas internos. Y eso amplifica cualquier debilidad de gobierno.
Los riesgos no vienen solo de “lo que dice”, sino de “lo que puede hacer”
Cuando el agente puede usar herramientas, hay una pregunta que se vuelve inevitable para TI y seguridad: ¿qué permisos tiene?
En el mundo clásico, el problema era: “¿qué información vio el modelo?”.
En el mundo agentic, el problema es: “¿qué acciones tiene permitido ejecutar el sistema?”.
Radware enfatiza que, una vez que el AI puede actuar, la seguridad debe extenderse más allá de prompts y outputs y entrar en dominios como identidad, herramientas, memoria y gobernanza de runtime.
En lenguaje de negocio, el riesgo no es que la IA “se equivoque” al responder. El riesgo es que la IA se equivoque mientras opera: moviendo datos, generando transacciones, abriendo accesos, automatizando cambios o ejecutando procesos.
El punto ciego más común: confundir automatización con control
Un patrón que estamos viendo en muchas organizaciones es este: se implementan agentes para ganar velocidad, pero el gobierno se queda atrás. Se asume que “si el agente es útil”, entonces “es seguro”.
La realidad es más incómoda: la autonomía no solo multiplica productividad; también multiplica exposición si no existe un marco de control. Y ese marco no se resuelve con “buenas prácticas de prompts” únicamente. Necesita, como mínimo, cuatro pilares:
- Identidad y privilegios mínimos para lo que el agente puede hacer.
- Gobierno de herramientas y APIs: qué puede invocar, cuándo y con qué validaciones.
- Memoria y contexto: qué recuerda, qué conserva y qué puede reusar (y qué no).
- Monitoreo y enforcement en runtime: visibilidad de acciones, límites, bloqueos, auditoría.
No es un tema de paranoia. Es el equivalente moderno a lo que ya aprendimos con automatización en IT: si automatizas un proceso sin controles, automatizas también el error.
Dos escenarios “antes y después”
Imagina un agente que ayuda a soporte y finanzas a resolver casos en minutos. En el flujo normal, es brillante. Pero un atacante logra manipular el contexto (por ejemplo, inyectando instrucciones en datos que el agente consulta) y el agente ejecuta reembolsos o cambios de cuenta que “parecen” legítimos porque siguen el flujo. El daño no viene de un exploit tradicional; viene de abuso de autonomía: el agente hizo lo que estaba diseñado para hacer, pero bajo un contexto adverso.
Ahora piensa en un agente que “optimiza” procesos: actualiza tickets, crea accesos temporales, reinicia servicios, aplica cambios de configuración con base en diagnósticos. Si el agente tiene permisos amplios y el monitoreo es débil, cualquier error de razonamiento o manipulación de entrada puede convertirse en un cambio real en producción. No necesitas un atacante brillante; basta con una cadena de suposiciones incorrectas ejecutadas a máquina.
En ambos casos, el problema no es que la IA “alucine”. El problema es que la IA puede ejecutar.
Qué cambia para TI, SecOps y el CISO
Para TI, esto introduce una nueva disciplina: no basta con “integrar” un agente; hay que operar su ciclo de vida como un sistema crítico. Permisos, roles, auditabilidad, límites de acción, pruebas de abuso, y observabilidad se vuelven parte del estándar.
Para SecOps, los agentes agregan una nueva superficie de ataque: entradas manipulables, contextos contaminables, herramientas invocables, identidades automatizadas. El monitoreo debe evolucionar para incluir no solo “alertas”, sino trazabilidad de decisiones y acciones.
Para el CISO, el reto principal es de gobierno: el negocio va a pedir agentes por eficiencia. La pregunta es cómo habilitarlos sin crear una deuda de riesgo que explota después. Aquí el lenguaje de riesgo importa: autonomía = mayor productividad, sí, pero también mayor blast radius si no se diseña con controles.
Cómo se conecta con el enfoque CROC
En Nova, cuando hablamos de CROC, hablamos de operar el riesgo como un proceso continuo: ver exposición, priorizar, intervenir y verificar reducción.
La IA agente encaja perfecto como nuevo frente de exposición. No porque sea “mala”, sino porque cruza una línea: pasa de recomendar a ejecutar. Y eso exige un enfoque operativo, no solo políticas.
Un CROC aplicado a este problema significaría: mapear dónde hay agentes, qué sistemas tocan, qué permisos tienen, qué datos consumen, qué acciones ejecutan, qué tan verificables son sus decisiones, y qué guardrails existen en runtime. Es el mismo principio: convertir un riesgo emergente en un proceso manejable y medible.
La idea central
La IA agente no es “un LLM más”. Es un cambio de categoría.
Si tu IA puede actuar, tu seguridad debe proteger no solo lo que el modelo responde, sino lo que el sistema puede ejecutar: identidad, herramientas, memoria y gobierno operativo. Ahí es donde se juega la resiliencia, el cumplimiento y la confianza del negocio en la nueva economía agentic.
Para mantenerte informado y protegido, sigue las redes sociales de Nova en: Instagram, Facebook y LinkedIn, donde puedes encontrar más noticias y conocer las soluciones en ciberseguridad que ofrecemos.
#NovaInforma
