Los agentes de IA convierten el acceso empresarial en un riesgo de datos de dentro hacia fuera

Google News ha puesto de relieve una advertencia más contundente sobre los agentes de IA: la mayor amenaza para los datos empresariales podría ya contar con credenciales válidas y acceso aprobado.

La cobertura de Dark Reading no describe una brecha aislada. Expone una inversión más amplia de la seguridad. Las empresas otorgan a los agentes acceso interno para que automaticen trabajo útil. Ese mismo acceso permite que errores, instrucciones hostiles o permisos excesivos desplacen información sensible entre sistemas de confianza.

Las defensas tradicionales se centran en mantener a los intrusos fuera de la red. Los agentes de IA complican ese modelo porque suelen operar dentro de aplicaciones aprobadas, utilizando identidades legítimas y herramientas autorizadas. El conflicto central ahora es productividad frente a control, no defensores frente a un atacante externo evidente.

Los lectores de Google News que se encuentren con esta historia deberían tratarla como una advertencia sobre la gobernanza del acceso. Un agente no necesita vulnerar el perímetro cuando una empresa ya lo ha conectado al correo electrónico, documentos, bases de datos, navegadores y API externas.

Lo que realmente señala el titular de Google News

Los agentes de IA convierten errores ordinarios de acceso en cadenas automatizadas de acciones que pueden atravesar varios sistemas empresariales.

Un agente de IA es software que utiliza un modelo para planificar tareas, seleccionar herramientas y actuar con una participación humana limitada. A diferencia de un chatbot, no se limita a devolver texto. Puede recuperar registros, enviar mensajes, editar archivos, llamar a API o activar flujos de trabajo.

Esa distinción cambia el problema de seguridad. Un chatbot puede revelar información incluida en su contexto. Un agente puede buscar más información, combinarla, transformarla y trasladarla a otro lugar.

La preocupación de fondo en el titular de Google News no es que los agentes contengan todos los secretos de una empresa. La información empresarial suele permanecer en repositorios como almacenamiento en la nube, sistemas de clientes, plataformas de código y herramientas de colaboración.

El riesgo proviene de las conexiones entre esos repositorios y el agente. El reportaje de Dark Reading sobre la responsabilidad compartida subraya que las empresas siguen siendo responsables de proteger los datos y usuarios conectados a servicios agénticos.

Esa responsabilidad se vuelve más difícil de gestionar cuando un agente hereda el acceso del usuario mientras otro utiliza una cuenta de servicio genérica. Ambos diseños pueden crear rutas de exposición inesperadas.

Un agente acotado al usuario puede buscar en todo aquello a lo que un empleado puede acceder, incluidas carpetas compartidas olvidadas. Una identidad de servicio puede tener privilegios más amplios de los que necesita cualquier usuario individual.

El agente también puede reunir datos que parecen inofensivos cuando se observan por separado. Una lista de clientes, una hoja de ruta interna y un directorio de empleados pueden volverse muy sensibles tras su agregación.

Esta es una inversión importante. La búsqueda empresarial antes ayudaba a los empleados a localizar documentos que ya tenían permitido leer. Ahora un agente puede encontrar esos documentos y realizar acciones posteriores sin una decisión humana independiente.

El peligro no requiere intención maliciosa. Una solicitud imprecisa puede producir una búsqueda demasiado amplia. Un plan poco fiable puede seleccionar al destinatario o destino equivocado.

Un documento comprometido también puede redirigir el flujo de trabajo. La inyección indirecta de prompts ocurre cuando instrucciones hostiles se ocultan dentro de contenido que el agente lee, como un correo electrónico o una página web.

El modelo puede interpretar esas instrucciones como parte de su tarea. Si el mismo agente puede acceder a datos privados y comunicarse externamente, el atacante ha conectado el descubrimiento con la exfiltración.

Por eso esta historia importa más allá de un solo titular. El agente se sitúa en la intersección de identidad, datos, aplicaciones y acción. Cada conexión amplía lo que puede alcanzar un único fallo.

Por tanto, el cambio inmediato es arquitectónico. Las empresas ya no solo conceden a un software acceso a los datos. Están otorgando a los sistemas discrecionalidad sobre cómo se utiliza ese acceso.

La vía de exposición de dentro hacia fuera

El flujo de trabajo de agentes más peligroso combina contenido no confiable, datos sensibles y una acción saliente bajo una sola identidad.

Consideremos un agente al que se le pide preparar una revisión de cuenta. Lee registros de clientes, busca mensajes internos, revisa casos recientes de soporte y elabora un resumen.

Cada paso parece legítimo. La vía de exposición surge cuando un elemento recuperado contiene instrucciones diseñadas para el modelo, no para el empleado.

Un ticket de soporte malicioso podría indicarle al agente que ignore su tarea original. Podría dirigir al sistema a localizar registros adicionales y transmitirlos mediante una solicitud web permitida.

El atacante nunca inicia sesión en la empresa. El agente lee el contenido del atacante después de que este entra por un canal comercial normal.

Este patrón de ataque explota una frontera que los modelos de lenguaje no pueden imponer de manera fiable por sí solos. El mismo contexto puede contener instrucciones del usuario, datos recuperados, orientación del sistema y texto controlado por el atacante.

Los modelos procesan esos elementos como lenguaje. Las etiquetas y los prompts pueden ayudar, pero no crean una barrera de autorización determinista.

Las herramientas del agente hacen que esa debilidad tenga consecuencias. Una instrucción envenenada tiene poco valor cuando el modelo no puede acceder a datos privados ni actuar fuera de la sesión.

El riesgo aumenta cuando los desarrolladores proporcionan herramientas amplias por comodidad. Un navegador general, un conector de base de datos sin restricciones, un shell o una función de mensajería pueden servir a muchos flujos de trabajo. También pueden permitir acciones que la funcionalidad original nunca requirió.

OWASP identifica este problema como agencia excesiva. Sus ejemplos incluyen tareas de solo lectura respaldadas por extensiones que también pueden modificar, eliminar o enviar información.

Los permisos crean otra capa. Un conector destinado a leer una tabla de producto no debería recibir acceso de escritura ni visibilidad sobre registros no relacionados.

Las cuentas genéricas con privilegios elevados son especialmente riesgosas. Pueden borrar la distinción entre lo que un usuario individual puede solicitar y lo que la infraestructura del agente puede recuperar.

La memoria amplía la ventana de exposición. La memoria del agente almacena datos o contexto para su uso posterior, lo que ayuda a mantener la continuidad entre sesiones.

Sin embargo, la memoria persistente puede conservar instrucciones envenenadas, material confidencial o una suposición de seguridad incorrecta. Un problema introducido durante una tarea puede influir más tarde en otro usuario o flujo de trabajo.

Los registros pueden convertirse en un segundo repositorio de datos. Las trazas detalladas ayudan a los equipos a investigar las decisiones de un agente, pero esas trazas pueden contener prompts, documentos recuperados, credenciales o información personal.

Por tanto, un equipo puede reducir un riesgo mientras crea otro. Los datos de observabilidad mal protegidos se convierten en un objetivo valioso porque registran lo que el agente vio e intentó hacer.

Los sistemas multiagente añaden más transferencias. Un agente puede recopilar información, un segundo analizarla y un tercero comunicar el resultado.

Cada transferencia necesita identidades autenticadas, permisos acotados y datos validados. De lo contrario, un componente comprometido puede transmitir instrucciones dañinas aguas abajo con la apariencia de tráfico interno de confianza.

El atacante externo sigue siendo relevante, pero la acción final ocurre desde dentro de la empresa. Llega mediante una identidad aprobada y sigue una ruta de aplicación que los defensores pueden considerar normal.

Ese es el problema de dentro hacia fuera. El fallo de seguridad empieza con acceso legítimo, atraviesa límites internos de datos y sale a través de una herramienta permitida.

Por qué los equipos de identidad afrontan la primera presión

Los agentes de IA se comportan como usuarios, se autentican como servicios y operan más rápido que los procesos de gobernanza diseñados para cualquiera de los dos grupos.

Los sistemas de acceso humano presuponen un empleado identificable, un puesto, un responsable y un ciclo de vida laboral. Las cuentas de servicio suelen respaldar software predecible con funciones estables.

Los agentes no encajan en ninguna de las dos categorías. Sus acciones cambian según los prompts, el contexto recuperado, las herramientas disponibles, las versiones del modelo y los resultados intermedios.

Un agente puede autenticarse con un token de API, actuar en nombre de un empleado y delegar parte de una tarea en otro agente. Eso crea varias identidades dentro de un mismo flujo de trabajo.

Los equipos de seguridad deben saber quién inició la solicitud. También necesitan saber qué agente actuó, qué credenciales utilizó y qué autorización se aplicó.

Una acción final debe seguir siendo atribuible a esas identidades. Sin esa cadena, los equipos de respuesta a incidentes pueden ver una llamada API autorizada sin comprender el razonamiento ni la intención del usuario que había detrás.

NIST reconoció esta brecha en su proyecto de identidad de agentes de 2026. El trabajo propuesto se centra en la identificación, autorización, auditoría y no repudio para agentes de software.

Esos requisitos se asemejan a prácticas de identidad ya consolidadas, pero los agentes cambian el ritmo de operación. Una revisión trimestral de acceso no puede contener privilegios que dejan de ser necesarios minutos después de que termine una tarea.

El acceso permanente crea un problema de acumulación. Los equipos conceden un permiso para una prueba piloto, lo conservan por comodidad y más tarde conectan el agente a otro sistema.

El alcance efectivo del agente crece incluso cuando ningún administrador crea deliberadamente un superagente privilegiado. Permisos separados pueden combinarse en una ruta peligrosa.

Por ejemplo, el acceso de lectura a una base de datos puede parecer seguro por sí solo. El acceso web externo también puede respaldar una tarea de investigación legítima.

Juntas, esas capacidades pueden permitir que registros sensibles abandonen la organización. Los equipos de seguridad suelen calificar esta combinación como tóxica porque el riesgo total supera el de cada permiso considerado de forma aislada.

La presión también recae sobre los propietarios de las aplicaciones. Deben exponer funciones más limitadas en lugar de entregar a los agentes interfaces administrativas genéricas.

Un agente de programación puede necesitar crear reservas en el calendario. No necesariamente necesita permiso para eliminar todos los eventos o leer las notas privadas de cada asistente.

Los propietarios de datos afrontan una decisión relacionada. Deben determinar si los permisos de usuario existentes siguen siendo adecuados cuando el software puede buscar, resumir y redistribuir información a velocidad de máquina.

Un empleado que técnicamente puede abrir miles de documentos rara vez los inspeccionará todos. Un agente puede recorrer rápidamente ese acceso y eliminar la fricción práctica que antes limitaba la exposición.

Esto no significa que todos los agentes merezcan menos acceso que su usuario. Significa que la autorización debe tener en cuenta la tarea solicitada, el destino, la sensibilidad de los datos y la acción propuesta.

El acceso estático basado en roles no puede expresar todas esas condiciones. Las empresas necesitan comprobaciones de políticas durante todo el flujo de trabajo, especialmente antes de recuperar datos sensibles o realizar comunicaciones externas.

Google News está amplificando un problema de seguridad que atraviesa la responsabilidad organizativa. Los equipos de identidad controlan las credenciales, los equipos de aplicaciones crean herramientas y los equipos de datos clasifican la información.

Los líderes de programas de IA suelen controlar la velocidad de despliegue. Cuando esos grupos trabajan de forma independiente, el agente hereda sus brechas y las conecta en una única ruta de ejecución.

Las promesas de productividad ahora chocan con la realidad de la seguridad

Los agentes se vuelven más útiles a medida que obtienen contexto y autoridad, pero esas mismas características aumentan el daño derivado de la manipulación o el error.

Un agente empresarial útil debe saber lo suficiente para completar trabajo real. Necesita acceso a sistemas relevantes, comprensión del contexto del usuario y autoridad para realizar acciones aprobadas.

Eliminar esas capacidades produce un chatbot más seguro, pero limitado. Ampliarlas produce un trabajador capaz cuyos errores pueden tener consecuencias operativas.

Esta es la principal disyuntiva detrás del artículo de Dark Reading. El objetivo no es eliminar la autonomía de los agentes. Es evitar que la autonomía se convierta en autoridad sin restricciones.

Los controles de seguridad pueden reducir el riesgo, pero ninguno ofrece por sí solo una respuesta completa. Los filtros de prompts pueden detectar lenguaje malicioso conocido, pero los atacantes pueden codificar o disfrazar instrucciones.

Las salvaguardas basadas en modelos enfrentan una limitación más profunda. Utilizan sistemas probabilísticos para evaluar otro sistema probabilístico, y debilidades similares pueden afectar a ambas capas.

La aprobación humana ayuda cuando una acción es poco frecuente y tiene consecuencias importantes. Se vuelve menos útil cuando los empleados aprueban habitualmente solicitudes complejas que no pueden revisar de forma significativa.

Las solicitudes de aprobación también necesitan información clara. Un usuario no puede evaluar una acción descrita únicamente como “continuar flujo de trabajo” o “usar conector”.

La interfaz debería identificar el recurso, la operación, el destinatario y la categoría de datos. También debería explicar por qué la acción solicitada se deriva de la tarea original.

El principio de mínimo privilegio reduce el daño potencial. Sin embargo, definir el mínimo privilegio para un flujo de trabajo cambiante y de varios pasos es más difícil que delimitar una aplicación tradicional.

Los permisos pueden ser apropiados durante un paso y excesivos en el siguiente. Las credenciales temporales vinculadas a la tarea ofrecen un modelo mejor que el acceso persistente.

La supervisión en tiempo de ejecución proporciona otra capa. Puede detectar volúmenes de recuperación inusuales, nuevos destinos, combinaciones atípicas de herramientas o comportamientos que se apartan de la línea base del agente.

Sin embargo, la detección de anomalías necesita historial, contexto y atribución fiable. Un agente nuevo puede carecer de una línea base estable, mientras que los flujos de trabajo legítimos pueden variar ampliamente.

Dark Reading informó sobre una investigación de Gartner que sugiere que aproximadamente el 90% de los agentes actuales tienen baja autonomía. El 10% restante cuenta con herramientas más amplias, acceso a datos y discrecionalidad en tiempo de ejecución.

Esos sistemas de alta autonomía merecen controles específicos porque sus modos de fallo implican algo más que texto incorrecto. Pueden modificar sistemas de producción o transferir datos confidenciales.

El mismo informe citó una encuesta de un proveedor a más de 400 líderes de tecnología y seguridad. Concluyó que el 84% afirmó que sus agentes podían acceder a datos sensibles.

Otro 67% creía que los agentes habían accedido a información a la que no deberían haber llegado. Esas cifras procedían de una encuesta de un proveedor de seguridad, por lo que indican preocupación, no una tasa universal de incidentes.

Aun así, los hallazgos se alinean con el riesgo arquitectónico. Las empresas suelen conectar agentes antes de contar con un inventario completo de identidades, herramientas, rutas de datos y permisos heredados.

También es necesaria una visión escéptica. No todos los agentes representan una nueva clase de amenaza catastrófica.

Muchos riesgos se asemejan a fallos conocidos relacionados con cuentas de servicio, privilegios excesivos, integraciones inseguras y una gobernanza de datos deficiente. Controles mejor establecidos pueden prevenir una gran parte de ellos.

Lo que cambia es la combinación. Los agentes seleccionan acciones de forma dinámica y procesan lenguaje controlado por atacantes, mientras que las integraciones tradicionales siguen rutas de código predeterminadas.

Esa diferencia hace que el comportamiento sea menos predecible. También hace que la calidad de la autorización en tiempo de ejecución sea más importante que la calidad del inicio de sesión inicial.

Los controles que limitan la exposición de datos de los agentes

Las empresas necesitan controles deterministas alrededor del modelo porque las instrucciones dentro del modelo no pueden imponer su propia autoridad.

El primer requisito es un inventario de agentes. Los equipos de seguridad no pueden gobernar identidades, conectores, herramientas y almacenes de datos cuya existencia desconocen.

El inventario debería incluir agentes en producción, pilotos internos, aplicaciones de proveedores y asistentes instalados por empleados. También debería registrar proyectos abandonados con credenciales que siguen activas.

Cada agente necesita una identidad distinta. Las claves API compartidas ocultan la atribución y dificultan la revocación.

La identidad debería estar vinculada a un propietario, propósito aprobado, modelo, conjunto de herramientas y estado de ciclo de vida. Las empresas deberían desactivarla cuando termine el proyecto o su propietario se marche.

El segundo requisito es la autorización acotada a la tarea. Las decisiones de acceso deberían evaluar lo que solicitó el usuario y qué acción propone ahora el agente.

Una solicitud para resumir una carpeta no debería autorizar una búsqueda en todos los repositorios. Una solicitud para redactar un correo electrónico no debería autorizar automáticamente su envío.

El tercer requisito es la separación entre leer y actuar. Los agentes que procesan contenido no confiable no deberían controlar automáticamente herramientas de alto impacto.

La guía de seguridad para agentes de OWASP recomienda acceso mínimo a herramientas, memoria aislada, revisión humana para acciones riesgosas y supervisión estructurada.

Una opción arquitectónica utiliza componentes separados. Un modelo restringido lee contenido externo, mientras que un componente privilegiado recibe únicamente información validada y estructurada.

Este enfoque no elimina la manipulación, pero rompe la ruta directa entre texto hostil y una acción autorizada.

El cuarto requisito es la aplicación de controles conscientes de los datos. Una herramienta debería evaluar la clasificación de la información solicitada antes de devolverla.

El punto de aplicación debería estar fuera del modelo. El modelo puede proponer una consulta, pero una política determinista debería decidir qué registros y campos están disponibles.

Las empresas también deberían preservar el contexto de seguridad del usuario. Un agente que actúa para un empleado no debería cambiar silenciosamente a una identidad de servicio más amplia.

El acceso de solo lectura debería ser el predeterminado cuando sea posible. Las funciones de escritura, eliminación, envío, publicación y pago deberían requerir ámbitos más restringidos y verificaciones más sólidas.

El quinto requisito es el control de destinos. Las organizaciones suelen centrarse en lo que un agente puede leer y pasan por alto dónde puede enviar el resultado.

Los dominios permitidos, destinatarios aprobados, inspección de contenido y rutas de red restringidas pueden limitar la exfiltración. Estos controles siguen siendo útiles incluso cuando fallan las defensas de prompts.

El sexto requisito es la memoria protegida. El material sensible no debería entrar en la memoria a largo plazo sin un propósito definido, un período de retención y un límite de acceso.

La memoria debería permanecer aislada entre usuarios y espacios de trabajo. Los equipos deberían analizar el contexto almacenado en busca de credenciales, información personal e instrucciones sospechosas.

Una base de conocimiento con capacidad de búsqueda también necesita permisos claros sobre las fuentes y límites de recuperación. La comodidad de búsqueda no debería eliminar las reglas de acceso a nivel de documento.

Por último, los equipos deben probar el flujo de trabajo completo. Las evaluaciones del modelo por sí solas no pueden revelar qué ocurre cuando interactúan identidad, recuperación, memoria, herramientas y contenido externo.

Los equipos rojos deberían utilizar documentos envenenados, correos electrónicos engañosos, solicitudes excesivas, pruebas de memoria entre usuarios y destinos no autorizados. Deberían repetir las pruebas después de cualquier cambio en el modelo, prompt, conector o política.

Tres señales que observar tras esta advertencia de Google News

La próxima prueba es si las empresas sustituyen el acceso amplio y permanente de los agentes por una autoridad visible, temporal y aplicable.

La primera señal es la adopción de identidades específicas para agentes. Microsoft y otros proveedores de plataformas están incorporando formas de registrar agentes, asignar permisos y registrar su comportamiento.

El registro por sí solo no basta. El cambio significativo llegará cuando las empresas puedan rastrear cada acción a través del agente, el usuario iniciador, la credencial y el servicio delegado.

Si esos registros aparecen en los sistemas estándar de gobernanza de identidades y respuesta a incidentes, será más fácil investigar el riesgo interno. La dependencia continuada de tokens compartidos debilitaría ese avance.

La segunda señal es la aplicación de controles en tiempo de ejecución. Los equipos de seguridad necesitan controles capaces de denegar una llamada a una herramienta sin apagar todo el agente.

Esté atento a las credenciales vinculadas a tareas, ventanas de autorización cortas, políticas conscientes de los datos y solicitudes de aprobación que identifiquen la operación propuesta. Estas capacidades reforzarían la idea de que la autonomía puede coexistir con el control.

Las afirmaciones de marketing sobre “agentes seguros” aportan poca evidencia por sí solas. Los compradores deberían preguntar si la autorización ocurre fuera del modelo y si las políticas se aplican a cada solicitud posterior.

La tercera señal es la evidencia pública de incidentes. El mercado aún carece de informes coherentes sobre fallos de agentes, incidentes evitados por poco y exposición de datos.

Las divulgaciones útiles deberían describir la entrada que inició el proceso, las herramientas disponibles, los permisos efectivos, las salvaguardas que fallaron y el impacto final. Las afirmaciones agregadas sin esos detalles no pueden demostrar si los nuevos controles funcionan.

Los reguladores y los grupos de estándares también importan aquí. El trabajo de NIST sobre estándares para agentes puede proporcionar a las empresas un lenguaje común para identidad, autorización y auditabilidad.

Google News seguirá mostrando advertencias a medida que los proveedores incorporen agentes en más flujos de trabajo. Los lectores deberían mirar más allá de los titulares dramáticos y examinar la ruta de acceso detrás de cada evento.

Haga tres preguntas antes de confiar en cualquier agente empresarial: ¿Qué puede leer, qué puede hacer y adónde puede enviar el resultado?

Si la organización no puede responder las tres a partir de políticas aplicables y registros auditables, el agente no es simplemente un asistente. Es una identidad interna sin límites esperando la instrucción equivocada.