Los agentes de IA amplían el radio de impacto de la seguridad empresarial

Google News puso de relieve esta semana un marcado conflicto empresarial: los agentes de IA obtienen mayor autoridad, mientras que los controles que los rodean siguen siendo incompletos. El titular de BankInfoSecurity resume la preocupación en términos operativos. Un agente ya no solo produce texto. Puede recuperar registros, invocar software, modificar archivos, enviar mensajes y activar flujos de trabajo.

Esa combinación cambia el significado de un fallo de IA. Un error de chatbot suele quedarse dentro de una conversación. Un error de agente puede propagarse por cada herramienta conectada, credencial, almacén de datos y sistema posterior. Su radio de impacto mide el daño total alcanzable a partir de una única acción comprometida o equivocada.

Por tanto, la cuestión central no es la capacidad de la IA frente al software tradicional. Es la autonomía de los agentes frente a la contención empresarial. Las compañías quieren que los agentes completen trabajos de varios pasos con menos interrupciones. Los equipos de seguridad necesitan que esos agentes operen con identidades acotadas, permisos limitados, herramientas verificadas y rutas de aprobación observables.

Anthropic ha descrito el mismo equilibrio desde dentro de sus propios despliegues. La compañía afirma que el acceso suficiente para interrumpir un servicio interno se volvió habitual a medida que los agentes de programación ganaban utilidad. Sin embargo, sus ingenieros también concluyeron que las salvaguardas a nivel de modelo no pueden proporcionar protección completa.

Ese cambio importa más allá de un solo proveedor. Un mejor razonamiento puede reducir errores evidentes, pero también ayuda a un agente a encontrar más rutas hacia un objetivo. Ahora las empresas deben proteger sistemas que interpretan información, eligen acciones y adaptan sus planes durante la ejecución.

Lo que realmente cambia con la advertencia de Google News

El perímetro de seguridad se desplaza cuando el software puede decidir cómo usar su acceso, no solo ejecutar una instrucción predefinida.

La automatización tradicional sigue una ruta diseñada. Un script de nómina recupera registros especificados, realiza cálculos definidos y escribe los resultados en destinos conocidos. Sus permisos pueden ser excesivos, pero los defensores aún pueden trazar la secuencia esperada.

Los agentes de IA introducen una capa de decisión entre la solicitud y la acción. Interpretan un objetivo, lo dividen en tareas, seleccionan herramientas, inspeccionan resultados y revisan el plan. Esa flexibilidad crea valor, pero también hace que el comportamiento sea menos predecible.

NIST define los sistemas de agentes como software capaz de planificar y realizar acciones autónomas que afectan entornos reales. Su solicitud sobre seguridad de agentes de enero de 2026 identificó tres preocupaciones distintas. Los agentes pueden procesar datos adversarios, depender de modelos contaminados o perjudicar la seguridad sin un atacante externo.

El primer problema es la inyección indirecta de prompts. Un atacante oculta instrucciones dentro de contenido que un agente leerá posteriormente, como un correo electrónico, una página web, un documento o un ticket de soporte. El agente puede confundir esas instrucciones hostiles con parte de la tarea asignada.

Esto no es lo mismo que un usuario que pide directamente a un chatbot que infrinja una regla. La persona que opera el agente quizá nunca vea el contenido malicioso. Una solicitud rutinaria para resumir mensajes o revisar documentos puede llevar el ataque al contexto de trabajo del modelo.

El segundo problema es la autoridad. Una instrucción inyectada importa solo en la medida del acceso disponible para el agente. Un agente de investigación de solo lectura podría devolver información manipulada. Un agente con permisos para correo electrónico, almacenamiento en la nube, ejecución de código y bases de datos puede exponer datos o modificar sistemas.

El tercer problema es la persistencia. Algunos agentes conservan memoria entre tareas o recuperan contexto previo de un almacén de conocimiento. La información contaminada puede sobrevivir más allá de la sesión original e influir en decisiones posteriores.

Estos riesgos convierten el contenido empresarial en parte de la superficie de ejecución. Tradicionalmente, los equipos de seguridad analizan documentos en busca de código malicioso. Ahora deben considerar si el lenguaje ordinario dentro de esos documentos puede redirigir a un actor de software autorizado.

Google News no creó este problema, pero su agregación de la advertencia de BankInfoSecurity hace visible el cambio para un público empresarial más amplio. La seguridad de los agentes ha ido más allá de un debate especializado sobre seguridad de modelos. Ahora pertenece a los programas de identidad, seguridad de aplicaciones, arquitectura de nube, gobierno de datos y respuesta a incidentes.

El desarrollo también cambia la responsabilidad. Un proveedor de modelos puede mejorar la resistencia a instrucciones maliciosas, pero la empresa que los despliega controla los permisos y las integraciones. Los desarrolladores de conectores controlan el comportamiento de las herramientas. Los equipos de seguridad definen la supervisión, mientras que los responsables de negocio deciden cuánta autonomía recibe un flujo de trabajo.

Ningún participante puede contener el riesgo por sí solo. El sistema alcanzable forma una cadena, y el eslabón menos restringido determina gran parte del daño posible.

La identidad de los agentes se está convirtiendo en el punto de presión

Una empresa no puede aplicar el principio de mínimo privilegio cuando no puede identificar a cada agente, a su propietario y la tarea exacta que justifica su acceso.

BankInfoSecurity destacó anteriormente esta brecha de identidad mediante comentarios de Rishi Kaushal, CIO de Entrust. Sostuvo que los agentes necesitan identidades diferenciadas, permisos definidos, trazas de auditoría y una rendición de cuentas clara. Estos requisitos resultan familiares porque extienden las prácticas consolidadas de identidad a un actor menos predecible.

La parte difícil es la ejecución. Un empleado suele tener una identidad estable, departamento, responsable y función laboral. Un agente puede crearse para un proyecto, copiarse a otro flujo de trabajo y conectarse a herramientas adicionales en cuestión de horas.

Algunos despliegues permiten que varios agentes compartan una cuenta de servicio. Otros heredan los permisos del empleado que los inicia. Ambos diseños debilitan la atribución porque los registros muestran una credencial amplia en lugar del agente específico y la tarea delegada.

La proliferación de agentes agrava el problema. Gartner predijo en abril de 2026 que una empresa global media del Fortune 500 utilizaría más de 150.000 agentes en 2028. La firma contrastó esa proyección con menos de 15 agentes en 2025.

La previsión no es un recuento de despliegues medido, y la adopción puede quedar por debajo de las expectativas. Aun así, ilustra el desafío de gobernanza. Las revisiones manuales diseñadas para una pequeña colección de aplicaciones no pueden seguir miles de identidades de software dinámicas.

Por ello, cada agente debería tener una identidad única y verificable desde su creación hasta su retirada. Ese registro debería identificar a su propietario de negocio, propietario técnico, herramientas aprobadas, alcance de datos, entorno operativo y nivel máximo de acción.

Una identidad útil también debe preservar el contexto de delegación. Los equipos de seguridad necesitan saber qué persona o servicio asignó la tarea. Necesitan conocer el propósito solicitado, la fase actual del flujo de trabajo y las condiciones vinculadas a la autoridad.

El acceso estático basado en roles no puede responder a todas las preguntas. Un agente de compras puede leer legítimamente contratos durante la revisión de proveedores. Ese mismo acceso no debería seguir disponible cuando el agente prepara un resumen de calendario no relacionado.

La autorización vinculada a tareas reduce esa brecha. Concede a un agente capacidades específicas para un propósito definido y un período limitado. Las acciones de alto impacto pueden exigir una comprobación de identidad o una decisión de política separada en el momento de la ejecución.

El National Cybersecurity Center of Excellence de NIST ha propuesto aplicar estándares de identidad establecidos a agentes de software e IA. Su documento conceptual sobre identidad se centra en la identificación, autorización y casos de uso empresariales, en lugar de tratar a los agentes como procesos anónimos en segundo plano.

Este enfoque presiona a los proveedores de identidad, los proveedores de nube y los desarrolladores de aplicaciones. Deben representar a los agentes como actores de primera clase en productos diseñados en torno a personas y cargas de trabajo convencionales.

También presiona a los compradores empresariales. Un equipo que evalúa una plataforma de agentes debe mirar más allá de la calidad del modelo. Los compradores deben saber si cada llamada a una herramienta lleva un principal identificable, un propósito de tarea y un alcance de permisos aplicable.

Los registros de auditoría deben capturar más que prompts y respuestas. Deben registrar qué datos recuperó el agente, qué herramientas invocó, qué cambió cada herramienta y qué aprobación autorizó la acción.

Esta evidencia importa durante un incidente. Si los investigadores solo saben que un agente procesó un documento malicioso, aún no pueden medir la exposición. Deben reconstruir cada registro tocado, secreto accedido, mensaje enviado y sistema modificado después.

Un sistema interno de conocimiento con capacidad de búsqueda puede ayudar a los empleados a conservar decisiones y contexto de fuentes. Sin embargo, cualquier base de conocimiento de IA conectada a un agente también necesita límites de confianza claros. El contenido recuperado sigue siendo datos, no autoridad de confianza.

Por tanto, el problema de identidad es mayor que la autenticación. Abarca procedencia, propiedad, delegación, propósito y rendición de cuentas. Sin estos elementos, una empresa sabe que la automatización actuó, pero no puede explicar de forma fiable quién la autorizó ni por qué.

Los agentes más capaces crean un equilibrio de seguridad más difícil

El mismo acceso que hace útil a un agente también determina hasta dónde puede propagarse un error, secuestro o herramienta comprometida.

Un modelo aislado no puede enviar dinero ni modificar producción. Se vuelve valioso operativamente después de que los desarrolladores lo conectan a bases de datos, navegadores, repositorios de código, sistemas de comunicación y aplicaciones empresariales.

Cada conexión amplía el grafo alcanzable. Ese grafo incluye herramientas directas, credenciales heredadas, datos recuperados, destinos de red, memoria compartida y otros agentes. El radio de impacto es la porción de ese grafo disponible tras el fallo de un control.

La respuesta evidente es pedir a una persona que autorice cada acción sensible. Sin embargo, las solicitudes frecuentes pueden volverse ceremoniales. Anthropic informó de que los usuarios de Claude Code aprobaron aproximadamente el 93% de las solicitudes de permisos en su telemetría.

Esa cifra procede de los datos del propio producto de Anthropic, por lo que no representa a todas las empresas. Aun así, revela la fatiga de aprobación. Cuando el software interrumpe repetidamente a los usuarios, muchas personas aprueban solicitudes sin examinar cuidadosamente el comando o destino.

El análisis de contención de Anthropic separa la supervisión conductual de la restricción ambiental. Las defensas conductuales intentan influir en lo que un agente elige. Los controles ambientales limitan lo que puede alcanzar, independientemente de su elección.

La distinción es crítica. Los prompts de sistema, clasificadores, entrenamiento y evaluaciones de modelos pueden reducir el comportamiento dañino. Sin embargo, estos controles son probabilísticos, lo que significa que pueden no detectar ataques desconocidos o adaptativos.

La contención establece límites más estrictos. Los entornos aislados restringen procesos y archivos. Las máquinas virtuales separan cargas de trabajo. Los controles de salida limitan las conexiones de red salientes. El aislamiento de credenciales mantiene los secretos valiosos fuera del entorno.

Un agente no puede divulgar una credencial que nunca recibe. No puede escribir en una base de datos de producción mediante una conexión de solo lectura. No puede enviar datos a un servidor arbitrario cuando el tráfico saliente sigue una lista de permitidos estricta.

Esto genera un equilibrio incómodo. El entorno más restringido suele ser el más seguro, pero también limita la utilidad. Un agente sin espacio de trabajo persistente, archivos locales ni acceso a red no puede completar muchas tareas empresariales valiosas.

El diseño más sólido no concede autoridad amplia simplemente porque un modelo parezca capaz. Divide el trabajo en compartimentos. Cada compartimento expone únicamente los datos y las acciones necesarios para esa etapa.

Consideremos un agente de atención al cliente. Necesita leer un ticket y recuperar detalles relevantes de la cuenta. Puede redactar una respuesta, pero enviar esa respuesta representa una capacidad distinta.

Emitir un reembolso requiere otra capacidad con un límite definido. Cambiar el propietario de una cuenta o exportar datos de clientes debería exigir una verificación más sólida. El agente nunca debería recibir todos esos poderes mediante una única credencial permanente.

El mismo principio se aplica a los agentes de programación. Leer un repositorio es distinto de modificar una rama de desarrollo. Fusionar código, acceder a secretos, cambiar infraestructura y desplegar en producción pertenecen a zonas de confianza separadas.

La reversibilidad también importa. Las empresas pueden permitir que las acciones de bajo impacto se ejecuten automáticamente cuando son fáciles de inspeccionar y deshacer. Los cambios irreversibles merecen controles más estrictos, límites más acotados y registros independientes.

Este marco reduce la dependencia de la aparente intención del agente. La política de seguridad evalúa la acción solicitada, la identidad, el recurso, el destino y el contexto de la tarea. El control no necesita determinar si el modelo es sincero.

El marco de riesgos agénticos de OWASP refleja este modelo de amenazas más amplio. Sus categorías incluyen el secuestro de objetivos, el uso indebido de herramientas, el abuso de privilegios, el envenenamiento de memoria, la comunicación insegura y los fallos en cascada.

Estas categorías muestran por qué el filtrado convencional de prompts no puede cargar con toda la responsabilidad. Una solicitud de usuario perfectamente limpia aún puede activar una herramienta comprometida. Una herramienta segura puede devolver contenido envenenado. Un agente que funciona correctamente puede heredar una autoridad excesiva.

La pregunta central de seguridad no es si se puede confiar en un agente en abstracto. Es si la arquitectura circundante sigue siendo segura cuando el agente toma la decisión equivocada.

La inyección de prompts es solo el primer fallo de la cadena

Una inyección de prompts exitosa se convierte en un incidente empresarial cuando un acceso excesivo, un aislamiento débil o la falta de verificación permiten que la instrucción produzca consecuencias.

NIST describe el secuestro de agentes como un fallo al separar las instrucciones de confianza de los datos no confiables. Las arquitecturas actuales de agentes suelen combinar ambos dentro de un mismo contexto de modelo. Ese diseño permite que el contenido en lenguaje natural influya en la planificación.

Un atacante podría colocar instrucciones ocultas en una página web que visita un agente de investigación. Un correo electrónico malicioso puede indicar a un asistente que reenvíe documentos. Un archivo de repositorio envenenado puede redirigir a un agente de programación hacia un comando inseguro.

El agente no necesita tener intención maliciosa. Solo necesita interpretar el texto del atacante como una autoridad relevante. La llamada resultante a una herramienta puede parecer técnicamente válida porque utiliza un conector aprobado y una cuenta autenticada.

NIST probó este patrón mediante AgentDojo, un marco de investigación con entornos simulados de trabajo, viajes, Slack y banca. Sus evaluaciones de secuestro también añadieron escenarios de ejecución remota de código, exfiltración de bases de datos y phishing automatizado.

Estas pruebas demuestran rutas de ataque, no una tasa universal de vulneración. Los resultados dependen del modelo, las herramientas, el método de ataque, la tarea y el número de intentos. Las empresas deberían resistirse a convertir una puntuación de referencia aislada en una garantía de seguridad.

Los atacantes adaptativos hacen necesaria esa cautela. Una defensa que bloquea una frase conocida podría pasar por alto una paráfrasis. Un modelo que resiste un único intento aún puede fallar tras variaciones repetidas.

La preocupación más profunda es la composabilidad. Los agentes suelen llamar a otros servicios que tienen sus propios permisos y vulnerabilidades. Por tanto, una decisión manipulada puede desplazarse entre varios sistemas sin cruzar un perímetro de red evidente.

Los flujos de trabajo multiagente añaden otra capa. Un agente de planificación podría delegar la investigación en un agente y la ejecución en otro. Si la identidad y la integridad de los mensajes son débiles, un participante comprometido puede falsear instrucciones o resultados.

La memoria puede prolongar la cadena en el tiempo. Una política falsa, un contacto de proveedor o una excepción de seguridad almacenados durante una tarea pueden influir en trabajos posteriores. La fuente maliciosa original puede desaparecer antes de que los investigadores detecten el efecto.

Las cadenas de suministro de herramientas añaden riesgos convencionales de software. Un conector de agente puede tener código vulnerable, configuraciones predeterminadas inseguras o una dependencia comprometida. Las salvaguardas del modelo no corrigen esos defectos.

Estas incertidumbres debilitan las afirmaciones de que un único producto de seguridad puede resolver el riesgo de los agentes. Los escáneres de prompts, las pasarelas de agentes, las plataformas de identidad, las herramientas de observabilidad y los entornos aislados abordan cada uno una parte del problema. Ninguno controla por sí solo toda la cadena.

Las empresas también enfrentan una brecha de medición. Un informe de red team podría afirmar que una inyección de prompts tuvo éxito sin documentar a qué podía acceder después el agente. Ese resultado dice poco sobre el impacto empresarial.

Las pruebas útiles deberían registrar la huella posterior a la intrusión. Los investigadores necesitan conocer las herramientas invocadas, los datos a los que se accedió, las credenciales expuestas, los destinos contactados y los cambios completados. Esto vincula el radio de impacto teórico con consecuencias observables.

Las pruebas también deberían distinguir las acciones intentadas de las acciones exitosas. Un modelo podría solicitar una transferencia prohibida, mientras que la capa de políticas la bloquea. Eso supone un fallo de comportamiento, pero un resultado exitoso de contención.

Por el contrario, un agente podría producir una solicitud aparentemente inocua que cruce una frontera empresarial. La supervisión de seguridad tradicional podría aprobarla porque la credencial y la llamada a la API parecen legítimas.

Aquí es donde el contexto empresarial se vuelve esencial. Una tarea de análisis de ventas no tiene motivo para cambiar datos de nóminas. Un asistente de reuniones no debería crear claves de acceso a la nube. La política debe vincular la acción con el propósito asignado.

La revisión humana sigue siendo valiosa para casos ambiguos o de alto impacto, pero el revisor necesita evidencia utilizable. Un diálogo genérico de confirmación no revela el origen, el destino, los registros afectados ni la reversibilidad.

Un punto de control significativo podría indicar que un agente quiere enviar cinco archivos a una dirección externa. Debería identificar los archivos, el destinatario, la instrucción desencadenante y la excepción de política. El revisor puede entonces tomar una decisión informada.

Las empresas también deberían asumir que algunos controles fallarán. Los planes de incidentes necesitan una forma de suspender una identidad de agente sin deshabilitar toda una cuenta de servicio compartida. Los equipos deberían revocar las credenciales delegadas y poner en cuarentena la memoria afectada.

Los registros deben sobrevivir a la sesión del agente y mantenerse independientes de su entorno. De lo contrario, un proceso comprometido puede alterar la evidencia que necesitan los defensores.

La conclusión escéptica es directa. Ningún benchmark público ni declaración de un proveedor establece que la inyección de prompts haya sido eliminada. La seguridad depende de controles superpuestos que impidan que un fallo del modelo se convierta en un evento para toda la empresa.

Tres señales mostrarán si las empresas están conteniendo el riesgo

La próxima etapa de adopción de agentes se juzgará por una autoridad más acotada, una contención medible y evidencia de incidentes, no solo por la autonomía.

La primera señal es el respaldo generalizado a una identidad específica para agentes. Las plataformas de nube y software deberían identificar al agente, al usuario que delega, al propietario empresarial y a la tarea activa en cada solicitud sensible.

Esa información debe viajar a través de los conectores. Una aplicación que recibe una llamada de herramienta no debería ver solo una clave API compartida. Debería recibir un contexto verificable sobre el actor de software y su autoridad delegada.

Si los proveedores estandarizan ese contexto, las empresas podrán aplicar políticas coherentes en múltiples plataformas de agentes. Reforzaría el argumento de que la identidad puede contener la proliferación de agentes. La dependencia continuada de credenciales compartidas lo debilitaría.

La revisión de comentarios públicos de NIST de mayo de 2026 encontró un amplio acuerdo en que las prácticas establecidas de ciberseguridad siguen siendo pertinentes, pero necesitan adaptación. El resumen de respuesta de seguridad también identificó demanda de orientación para la implementación, intercambio de información y estándares.

La segunda señal es si los proveedores publican resultados de contención en lugar de limitarse a puntuaciones de seguridad del modelo. Las empresas necesitan pruebas que midan lo que ocurre después de que un agente siga una instrucción maliciosa.

Un informe útil debería indicar si el agente alcanzó un secreto, modificó un registro, contactó un destino no aprobado o cruzó un límite entre inquilinos. Debería separar la resistencia del modelo de la aplicación de políticas y del aislamiento ambiental.

Esta evidencia puede cambiar las compras. Los compradores podrían comparar implementaciones según el daño máximo alcanzable, en lugar de basarse en afirmaciones amplias sobre confiabilidad. Los equipos de seguridad también podrían fijar umbrales de aceptación para cada flujo de trabajo empresarial.

La divulgación pública seguirá siendo difícil porque la arquitectura de contención puede revelar detalles defensivos. Aun así, los proveedores pueden publicar metodologías, categorías de pruebas, resultados agregados y conclusiones revisadas de forma independiente sin revelar configuraciones explotables.

Si estos informes se normalizan, respaldarán la afirmación de que las empresas están tratando el radio de impacto como una propiedad de ingeniería medible. Si los proveedores siguen informando solo sobre el éxito de las tareas, la brecha de seguridad permanecerá en gran medida oculta.

La tercera señal es la primera oleada madura de informes de incidentes de agentes. Las organizaciones necesitan registros que distingan entre uso indebido por parte del usuario, mal comportamiento del modelo, manipulación externa, compromiso de conectores y fallo de autorización.

Los reguladores y los grupos sectoriales pueden ayudar a establecer un vocabulario común. Sin uno, cada incidente se convierte en una anécdota aislada y las empresas tienen dificultades para comparar causas o controles.

Los informes de incidentes deberían identificar el punto de entrada inicial y la ruta de acciones posteriores. Deberían describir qué límites se mantuvieron, cuáles fallaron y cómo se corrigieron las credenciales o la memoria.

Una mejor presentación de informes podría hacer que inicialmente la seguridad de los agentes parezca peor porque más fallos se volverían visibles. Esa transparencia seguiría representando un avance. Los incidentes ocultos no pueden mejorar los estándares ni las pruebas defensivas.

La advertencia de BankInfoSecurity difundida por Google News debería leerse, por tanto, como una historia de arquitectura, no como una predicción de catástrofe inevitable. Los agentes amplían la exposición porque las empresas conectan sistemas de razonamiento a autoridad real.

La contención sigue siendo posible. Requiere identidades separadas, permisos vinculados a tareas, herramientas compartimentadas, credenciales protegidas, redes restringidas, registros fiables y controles de aprobación deliberados.

También requiere un inventario. Los equipos de seguridad no pueden gobernar agentes que las unidades de negocio crearon sin registrarlos. Cada agente necesita un propietario, un propósito, un perfil de permisos, una clasificación de datos y un proceso de retiro.

Las organizaciones deberían comenzar con flujos de trabajo en los que la pérdida máxima sea limitada y las acciones sean reversibles. Solo pueden ampliar la autoridad después de que las pruebas demuestren que los límites de identidad, políticas y entorno resisten los ataques.

Este enfoque a veces ralentizará el despliegue. También puede preservar la adopción al evitar que un incidente evitable ponga fin a todo un programa. La seguridad se convierte en una restricción operativa que permite un uso controlado, no en una revisión final antes del lanzamiento.

Para los trabajadores del conocimiento, el asunto alcanza las herramientas cotidianas. Un asistente que lee correo electrónico, documentos, reuniones y archivos locales opera en un contexto profundamente personal. Los usuarios deberían saber a qué fuentes puede acceder y qué acciones requieren confirmación.

Para los desarrolladores, la unidad relevante ya no es solo el modelo. Es el sistema de agente completo, incluidos los prompts, la memoria, las herramientas, las credenciales, el entorno de ejecución, la red, las políticas y los registros.

Para los compradores empresariales, la pregunta decisiva es sencilla: ¿Qué puede seguir haciendo este agente después de que falle su razonamiento? Un proveedor que no puede delimitar esa frontera no ha definido el riesgo real del producto.

Google News seguirá mostrando ejemplos dramáticos a medida que los agentes entren en más flujos de trabajo. Los lectores deberían mirar más allá del comportamiento más alarmante y examinar la autoridad que lo respalda. ¿El agente estaba identificado de forma única, tenía un alcance limitado, estaba aislado y era observable? Formule esas preguntas antes de conceder el próximo conector, credencial o aprobación. El agente más seguro no es el que promete no fallar nunca. Es aquel cuyo fallo no puede llegar muy lejos.