Los agentes de IA en la sombra plantean un riesgo invisible para las empresas

Google News destacó una advertencia de Dark Reading sobre los agentes de IA en la sombra, mientras las empresas afrontan un conflicto preocupante: la adopción se acelera, pero la visibilidad sigue siendo incompleta.

La preocupación va más allá de que los empleados peguen texto confidencial en un chatbot no autorizado. Los agentes autónomos pueden recibir credenciales, conectarse a sistemas corporativos, conservar contexto y realizar acciones sin aprobación en cada paso.

Eso cambia el principal desafío de seguridad. Las empresas ya no equilibran la productividad con la gobernanza habitual del software. Equilibran la acción autónoma con controles diseñados para usuarios humanos y aplicaciones predecibles.

Dark Reading ha documentado cómo los sistemas agénticos pueden llegar a entornos de producción con credenciales amplias y controles de confirmación débiles. Un incidente reportado con un agente de programación eliminó en segundos una base de datos de producción y sus copias de seguridad a nivel de volumen. La conclusión más amplia de la publicación es más importante que el fallo individual: un agente con acceso excesivo puede convertir un error rutinario en un incidente operativo inmediato.

La advertencia también llega en medio de un rápido desarrollo de productos por parte de Microsoft, Google, Amazon, Nvidia y numerosos proveedores de seguridad. Cada empresa quiere formar parte de la pila de agentes empresariales. Sin embargo, cada nuevo marco, conector e identidad delegada ofrece a los equipos de seguridad otra relación que descubrir y gobernar.

La inversión central resulta incómoda. Los agentes de IA prometen reducir el trabajo manual, pero gobernarlos crea una nueva categoría de trabajo continuo. Los equipos de seguridad deben identificar cada agente, comprender su propósito, mapear su acceso, supervisar sus acciones y retirarlo de forma segura.

Google News pone en perspectiva el problema de los agentes en la sombra

La última advertencia importa porque la IA en la sombra ha pasado de conversaciones no autorizadas a acciones no autorizadas.

Google News funciona aquí como canal de descubrimiento, mientras que la cobertura subyacente de Dark Reading refleja un cambio más amplio en la investigación sobre seguridad empresarial. Empleados y desarrolladores están desplegando agentes mediante herramientas locales, plataformas en la nube, extensiones de software y proyectos internos de automatización.

Un agente de IA es software que utiliza un modelo para perseguir un objetivo a través de varios pasos. Puede seleccionar herramientas, recuperar información, llamar a API y modificar sistemas con menos supervisión directa que una aplicación convencional.

Esa autonomía diferencia a un agente en la sombra de un chatbot no autorizado. Un chatbot normalmente devuelve información a una persona. Un agente puede enviar un mensaje, cambiar código, actualizar un registro de cliente, consultar una base de datos o activar otro proceso automatizado.

Dark Reading informó que la seguridad de la IA agéntica sigue siendo un obstáculo empresarial importante, ya que los agentes locales populares se extienden más rápido de lo que los equipos de identidad pueden inventariarlos. Su cobertura describió a usuarios que establecían instancias antes de que los equipos de seguridad supieran que esos agentes existían. El informe también examinó una demostración en la que un ticket de soporte malicioso ayudó a un agente a escalar acceso y extraer datos en menos de un minuto.

Esos ejemplos no demuestran que todos los despliegues de agentes sean inseguros. Muestran cómo fallos de control conocidos se vuelven más trascendentes cuando el software puede planificar y actuar.

La magnitud de la brecha de visibilidad queda más clara en una encuesta empresarial sobre agentes de 2026 de Cloud Security Alliance. CSA informó que el 82% de las organizaciones participantes había descubierto agentes previamente desconocidos durante el año anterior.

La investigación se basó en 418 respuestas de profesionales de TI y seguridad. Token Security encargó y financió la encuesta, una relación que los lectores deberían considerar al interpretar sus conclusiones.

Incluso con esa salvedad, varios hallazgos revelan un problema de gobernanza coherente. El cuarenta y uno por ciento de los encuestados había descubierto agentes desconocidos varias veces. Los entornos internos de automatización y scripting fueron la fuente más común, citada por el 51%.

Las plataformas LLM, incluidas herramientas personalizadas, asistentes y plugins, siguieron con un 47%. La automatización SaaS y los flujos de trabajo creados por desarrolladores también figuraron entre las principales fuentes.

Esta distribución explica por qué un inventario de software convencional es insuficiente. Un agente puede aparecer como un proceso de escritorio, un recurso en la nube, un plugin, una integración de API o un flujo de trabajo integrado en un producto SaaS aprobado.

La aplicación visible es solo un componente. Las credenciales, los endpoints de modelos, las conexiones de herramientas, los almacenes de memoria y los agentes posteriores conforman el sistema operativo que la rodea.

Ese sistema puede seguir activo después de que el empleado que lo creó pase a otro proyecto. También puede conservar acceso después de que desaparezca su propósito empresarial original.

Google News puede haber llevado un titular a una audiencia más amplia, pero el fenómeno es mayor que un solo ciclo de publicaciones. Las empresas están descubriendo que su ecosistema de IA incluye actores que nunca registraron y permisos que nunca revisaron.

Por qué los agentes de IA en la sombra conllevan un riesgo distinto

Un agente en la sombra combina un activo desconocido con una identidad activa, creando riesgos que la TI en la sombra tradicional rara vez conllevaba a la misma velocidad.

La TI en la sombra suele referirse al software o la infraestructura adoptados sin aprobación formal. Sus riesgos incluyen almacenamiento de datos no gestionado, configuraciones inseguras, una evaluación deficiente de proveedores y registros de auditoría ausentes.

La IA en la sombra hereda esos problemas. Luego añade decisiones probabilísticas, contexto persistente, uso de herramientas y ejecución autónoma.

Una aplicación SaaS convencional sigue flujos de trabajo programados. Un agente interpreta un objetivo y selecciona una ruta. Dos solicitudes similares pueden conducir a acciones distintas porque el modelo, el contexto y las herramientas disponibles influyen en cada decisión.

Esta flexibilidad genera valor. También dificulta evaluar al agente mediante una revisión de seguridad puntual.

La autoridad efectiva de un agente depende de más que su configuración inicial. Los equipos de seguridad deben considerar al usuario solicitante, las credenciales delegadas, las herramientas conectadas, el contenido recuperado, los datos accesibles y cada acción posterior.

La inyección de prompts vuelve esa relación especialmente peligrosa. La inyección de prompts ocurre cuando contenido no confiable manipula las instrucciones de un agente, desviándolo potencialmente de la tarea prevista por el usuario.

Una instrucción maliciosa podría ocultarse dentro de un ticket de soporte, documento, correo electrónico o página web. Si el agente trata ese contenido como orientación confiable, podría revelar información o llamar a una herramienta autorizada con un propósito no autorizado.

El análisis de infraestructura de Cloud Security Alliance describe esto como una superficie de ataque por capas, en lugar de una colección de aplicaciones no autorizadas. Esa distinción es útil porque los agentes conectan sistemas que los equipos de seguridad suelen evaluar por separado.

Pensemos en un empleado que crea un agente para resumir comentarios de clientes. El agente lee una unidad compartida, llama a un modelo externo, almacena contexto, publica conclusiones en un canal de mensajería y actualiza una base de datos de planificación.

Cada conexión puede parecer razonable por separado. Juntas, crean un canal capaz de trasladar información confidencial a través de varios límites de confianza.

El empleado podría proteger la primera fuente de datos, pero pasar por alto la configuración de retención del proveedor del modelo. Podría almacenar una credencial de API en un archivo de configuración local. Podría conceder al agente permiso para editar todos los registros cuando solo necesita acceso de lectura.

El agente también puede acumular privilegios mediante acceso OAuth delegado. OAuth permite que un servicio actúe mediante permisos otorgados por un usuario u otra aplicación.

Por lo tanto, un agente abandonado puede seguir funcionando sin una cuenta de empleado convencional. Su token puede permanecer dentro de un flujo de trabajo, integración o entorno de desarrollo que recibe poca atención.

CSA denomina a la acumulación de agentes olvidados y permisos retenidos “deuda de retirada”. Solo el 21% de los encuestados de su encuesta informó contar con un proceso formal para retirar agentes.

Esta brecha en el ciclo de vida complica la respuesta a incidentes. Un equipo de seguridad no puede revocar rápidamente un agente cuando carece de un registro completo de su identidad, propietario, herramientas y dependencias.

El riesgo no se limita a una intrusión hostil. Un agente puede causar daños mientras persigue fielmente un objetivo mal especificado.

Dark Reading examinó este patrón de fallo después de que un agente de programación con IA supuestamente eliminara datos de producción y copias de seguridad asociadas. El incidente específico implicó varias debilidades de control, incluidas credenciales amplias y una separación insuficiente entre entornos.

Son errores de ingeniería conocidos. La autonomía reduce el tiempo entre el error y sus consecuencias.

Un operador humano podría detenerse antes de eliminar una base de datos. Un sistema de despliegue determinista podría rechazar una acción fuera de su ruta programada. Un agente puede interpretar una acción destructiva como un paso válido para completar el objetivo que se le asignó.

Por eso las reglas basadas en prompts no bastan. Decirle a un agente que evite acciones perjudiciales puede influir en su comportamiento, pero no elimina su capacidad técnica para realizarlas.

La capacidad debe limitarse fuera del modelo. El agente no debería tener acceso a sistemas y acciones que su tarea no requiere.

Los controles de identidad empresariales afrontan su prueba más difícil

El desafío principal ahora es la capacidad autónoma frente a sistemas de identidad construidos en torno a usuarios estables, cuentas de servicio y cargas de trabajo predecibles.

La gestión de identidades y accesos responde varias preguntas fundamentales. Quién solicita acceso, a qué recurso puede acceder, qué acción puede realizar y cuánto tiempo debe seguir siendo válido ese permiso.

Las empresas han dedicado años a mejorar estos controles para empleados y cuentas de servicio. Los agentes desafían ambas categorías.

Un agente no es una persona, pero a menudo actúa para una. Tampoco es una cuenta de servicio tradicional, porque su secuencia de acciones puede cambiar a medida que interpreta nuevo contexto.

Tratar a un agente como una cuenta de servicio compartida oculta la responsabilidad. Los registros podrían mostrar qué credencial accedió a un archivo sin revelar qué usuario inició la tarea ni por qué el agente seleccionó ese archivo.

Los sistemas multiagente dificultan más el problema. Un agente puede delegar trabajo en otro, que llama a una tercera herramienta con una credencial distinta.

La identidad e intención del usuario original pueden desaparecer a lo largo de esa cadena. Los permisos pasan entonces a seguir la integración técnica en lugar de la autoridad de la persona que solicitó el trabajo.

El pronóstico de seguridad de Google para 2026 anticipó este cambio. Sostuvo que los agentes deberían convertirse en actores digitales gestionados con acceso granular y consciente del contexto.

El informe destacó el mínimo privilegio, el acceso temporal y una cadena de delegación trazable. El mínimo privilegio significa que una identidad recibe únicamente el acceso necesario para su tarea actual.

Estos principios son prácticas de seguridad consolidadas. La parte difícil consiste en aplicarlos a la velocidad y escala de la actividad de los agentes.

Un empleado puede realizar varias acciones importantes durante una jornada laboral. Un agente puede iniciar numerosas llamadas a herramientas dentro de una sola tarea y puede ejecutarse continuamente.

Una revisión trimestral de accesos no puede evaluar cada decisión. Los permisos estáticos no pueden determinar si una acción concreta se ajusta al propósito actual del agente.

Por lo tanto, las empresas necesitan contexto en el punto de decisión. Una solicitud para leer una carpeta de proyecto aprobada podría continuar automáticamente. Una solicitud para exportar registros de clientes debería activar una verificación más estricta o una puerta de aprobación humana.

La encuesta de CSA muestra que las organizaciones ya reconocen esta distinción. El cincuenta y tres por ciento afirmó que los agentes operan de forma autónoma en tareas de bajo riesgo, mientras que las acciones de mayor riesgo reciben revisión humana.

Solo el 13% informó de modelos totalmente autónomos. Sin embargo, cuando los agentes excedían su alcance, apenas el 11% de los encuestados indicó que la acción se bloquearía automáticamente.

Esa brecha importa. Registrar una acción después de completarla ayuda a la investigación, pero no evita la pérdida de datos ni el daño operativo.

La aprobación humana también tiene limitaciones. Si cada acción genera una solicitud, los empleados aprobarán peticiones sin evaluarlas detenidamente. La fatiga de aprobación puede convertir un control visible en un ritual ineficaz.

Un diseño mejor vincula la intervención al riesgo. Los equipos de seguridad deben definir qué recursos, clasificaciones de datos y acciones requieren controles más estrictos.

Microsoft ha comenzado a posicionar Agent 365 como un plano de control para este problema. Su actualización de Agent 365 describe la detección de agentes locales y en la nube, incluidas conexiones entre entornos de Microsoft, Amazon y Google.

Microsoft afirma que sus productos de seguridad pueden mapear dispositivos, servidores de Model Context Protocol, identidades asociadas y recursos de nube accesibles. Model Context Protocol, o MCP, es un estándar que permite a las aplicaciones de IA conectarse con herramientas y fuentes de datos.

Ese mapa de relaciones es más útil que una lista plana de agentes. Ayuda a los defensores a estimar el radio de impacto si un agente o sus credenciales se ven comprometidos.

Microsoft también afirma que los administradores pueden detectar y bloquear métodos comunes utilizados por determinados agentes locales no gestionados. Los controles de tiempo de ejecución están destinados a detener comportamientos sospechosos mientras el agente opera.

Estas capacidades ilustran la dirección de la seguridad empresarial, pero las afirmaciones de los proveedores requieren validación práctica. La detección multiplataforma puede pasar por alto agentes personalizados, infraestructura privada, conectores no compatibles y flujos de trabajo ocultos dentro de otros productos.

Un plano de control también crea su propio riesgo de concentración. Las empresas deben decidir cuánta autoridad conceder al sistema responsable de gobernar a todos los demás agentes.

El resultado no es una simple migración de antiguas herramientas de identidad a otras nuevas. Las empresas deben ampliar los controles de identidad mientras preservan la supervisión independiente, las rutas de recuperación y una rendición de cuentas humana significativa.

La visibilidad por sí sola no equivale al control

Descubrir un agente es necesario, pero un inventario no puede demostrar que sus acciones sigan siendo seguras o estén alineadas con el propósito asignado.

Los proveedores de seguridad han respondido a la IA en la sombra con productos de detección. Estos productos inspeccionan endpoints, tráfico de red, entornos de nube, actividad de navegadores, identidades e integraciones SaaS.

Esa visibilidad proporciona un punto de partida. Una empresa no puede gobernar un activo que no puede identificar.

El peligro es tratar el descubrimiento como si fuera la conclusión. Un agente puede aparecer en un inventario mientras sus relaciones más importantes siguen siendo desconocidas.

Los equipos de seguridad necesitan saber quién es su propietario, qué modelo utiliza, qué datos recupera, dónde reside su memoria, qué credenciales posee y qué herramientas puede invocar.

También necesitan evidencia de comportamiento. Un agente aprobado para la conciliación de facturas no debería empezar de repente a buscar en repositorios de código fuente ni a enviar archivos a un dominio desconocido.

La prevención tradicional de pérdida de datos puede detectar cierta información sensible que sale de una organización. Podría no comprender por qué un agente accedió a la información o si la acción coincidía con la intención del usuario que la inició.

La misma limitación se aplica a la supervisión de endpoints. El nombre de un proceso puede revelar que un agente está en ejecución, pero no siempre puede reconstruir un flujo de trabajo en la nube iniciado a través de ese agente.

La autorización continua ofrece un modelo más sólido. Evalúa si el acceso sigue siendo apropiado en cada paso significativo, en lugar de confiar en un único inicio de sesión inicial.

Para los agentes, esa evaluación debería incluir el propósito de la tarea, la autoridad del usuario, la sensibilidad del recurso, la reputación de la herramienta, el comportamiento actual y los cambios recientes en el riesgo.

La autorización continua no requiere aprobación manual para cada operación. Las acciones de bajo riesgo y reversibles pueden continuar dentro de un límite definido.

Las acciones de alto impacto merecen una ruta diferente. Eliminar registros, publicar mensajes externos, modificar infraestructura, cambiar permisos o exportar datos regulados debería encontrar límites técnicos.

El límite debe existir fuera del modelo. Las credenciales de solo lectura, los entornos aislados, los límites de transacción y los servicios de aprobación separados pueden restringir lo que un agente realmente puede hacer.

La recuperación requiere una separación similar. Las copias de seguridad no deberían situarse dentro del mismo límite de permisos que el sistema de producción que un agente puede modificar.

La cobertura de bases de datos de Dark Reading ilustra este punto de forma concreta. Si un agente puede eliminar tanto los datos de producción como su copia de recuperación a través de una única ruta de credenciales, la copia de seguridad no proporciona una salvaguarda independiente.

La observabilidad también necesita registros duraderos. Los registros deben conservar el usuario iniciador, la identidad del agente, el modelo y la versión, el objetivo solicitado, las herramientas seleccionadas, los datos consultados, las aprobaciones recibidas y el resultado final.

Registrar todo genera preocupaciones de privacidad y almacenamiento. Las solicitudes sensibles y los datos recuperados no deberían convertirse en un conjunto de datos secundario sin restricciones.

Las empresas necesitan límites de retención y controles de acceso para la telemetría de agentes. Los investigadores requieren suficiente contexto para reconstruir decisiones sin exponer cada entrada confidencial a un grupo amplio.

La gobernanza también debe distinguir entre la experimentación aprobada y el acceso a producción no controlado. Los desarrolladores necesitan entornos donde puedan probar nuevos agentes sin esperar un ciclo completo de adquisición.

Esos entornos deberían utilizar datos sintéticos o adecuadamente protegidos. Deberían aislar las credenciales e impedir el acceso directo a recursos críticos de producción.

Una prohibición general crea otro problema de visibilidad. La previsión de Google advirtió que prohibir los agentes puede empujar su uso fuera de la red corporativa, donde la supervisión se vuelve aún más débil.

Eso no significa que cada herramienta deba recibir aprobación. Significa que la vía aprobada debe ser lo bastante utilizable para que los empleados la elijan.

Los equipos de seguridad pueden ofrecer modelos validados, conectores estándar, credenciales restringidas, entornos de prueba y un proceso de registro rápido. Estas medidas reducen el incentivo para crear alternativas ocultas.

Los responsables de negocio también tienen un papel. Deberían designar un propietario para cada agente de producción y documentar el proceso empresarial al que da soporte.

La propiedad debe incluir la retirada. Cuando termina el proyecto, la organización debe revocar tokens, eliminar integraciones, borrar la memoria innecesaria y verificar que los flujos de trabajo dependientes ya no llamen al agente.

Sin esa disciplina de ciclo de vida, la visibilidad se convierte en una lista creciente de activos sin resolver. La empresa sabe que el riesgo existe, pero aun así no puede eliminarlo con confianza.

La evidencia es seria, pero tiene límites

La investigación actual muestra una brecha sustancial de gobernanza, aunque las encuestas financiadas por proveedores y los incidentes aislados no pueden medir la frecuencia total del daño causado por agentes.

Los informes de seguridad requieren dos formas de cautela. Las empresas no deberían descartar los agentes en la sombra como un problema hipotético. Tampoco deberían tratar cada previsión o estadística de un proveedor como una medición neutral.

La encuesta de CSA ofrece detalles útiles porque identifica el número de encuestados, el momento de la encuesta y varios patrones de implementación. También indica que Token Security encargó, financió y ayudó a desarrollar el cuestionario.

Token vende seguridad de identidades para agentes de IA. Eso no invalida los hallazgos, pero crea un interés comercial en destacar las brechas de visibilidad e identidad.

Otras mediciones citadas con frecuencia proceden de proveedores de seguridad que observan a sus propios clientes. Estos conjuntos de datos pueden revelar tendencias dentro de la telemetría de un producto, pero quizá no representen a todas las empresas.

La selección de clientes, la configuración de implementación, los métodos de detección y la terminología pueden influir en el resultado. Un producto podría contar cada flujo de trabajo como un agente, mientras que otro solo cuenta identidades de agentes independientes.

El término “incidente” también necesita una interpretación cuidadosa. Puede abarcar exposición de datos, infracciones de políticas, comportamientos inesperados, interrupción operativa o compromiso confirmado.

CSA informó de que el 65% de los encuestados experimentó un incidente relacionado con agentes de IA durante el año anterior. Entre las organizaciones afectadas, la exposición de datos fue el impacto empresarial comunicado con mayor frecuencia.

Ese hallazgo es preocupante. No establece cuántos incidentes involucraron atacantes maliciosos, acciones accidentales, uso no aprobado o fallos en sistemas autorizados.

Los informes de casos aportan profundidad, pero no prevalencia. La eliminación de la base de datos de producción de una empresa demuestra una cadena de fallos plausible. No puede indicar a los lectores con qué frecuencia ocurren eventos similares en todo el mercado.

La misma cautela se aplica a las demostraciones de ataques. Un exploit controlado muestra que un diseño puede fallar en condiciones específicas. Las defensas, los permisos y la supervisión en producción pueden cambiar el resultado.

Por lo tanto, las empresas deberían pedir a los proveedores su metodología de detección, límites de cobertura, tasas de falsos positivos y validación independiente. Un panel etiquetado como “inventario completo” merece un escrutinio particular.

Los agentes desconocidos son desconocidos precisamente porque la detección es incompleta. Ningún proveedor puede demostrar una cobertura universal mostrando solo los activos que encontraron sus propios sensores.

Los líderes de seguridad también deberían separar el riesgo del modelo del riesgo de los sistemas. Un agente puede tomar una mala decisión debido al comportamiento del modelo, pero unos permisos excesivos determinan si esa decisión se convierte en un incidente grave.

A la inversa, los permisos limitados no resuelven todos los problemas. Un agente con acceso de solo lectura aún puede divulgar información confidencial, producir recomendaciones perjudiciales o influir en otro sistema.

La respuesta más creíble combina evaluación de modelos, gobernanza de identidades, protección de datos, supervisión en tiempo de ejecución y resiliencia operativa. Ninguna capa por sí sola soporta toda la carga.

Las empresas también necesitan informes de incidentes que distingan los fallos de los agentes de los fallos ordinarios de las aplicaciones. Los informes útiles deberían recoger el nivel de autonomía, la ruta de acceso, la identidad iniciadora, el componente comprometido y el impacto empresarial.

Sin definiciones compartidas, el mercado producirá cifras grandes pero incompatibles. Eso dificulta que los consejos de administración y los reguladores comprendan si el riesgo está mejorando.

Los lectores de Google News deberían interpretar el titular actual como una advertencia respaldada por evidencia convergente, no como una medición completa de la exposición empresarial.

La brecha de verificación forma parte de la historia. La industria puede ver lo suficiente para justificar la acción, pero todavía carece de datos públicos consistentes sobre los incidentes de agentes y sus consecuencias.

Lo que las empresas deberían vigilar a continuación

La próxima fase estará definida por los registros de agentes, la aplicación de controles en tiempo de ejecución y la evidencia de incidentes que ponga a prueba si los productos de gobernanza funcionan fuera de las demostraciones de los proveedores.

La primera señal es la adopción de registros de agentes multiplataforma. Microsoft, los proveedores de seguridad y los proveedores de nube están creando sistemas que inventarían agentes en endpoints, productos SaaS y entornos de nube.

Las empresas deberían examinar si esos registros detectan flujos de trabajo personalizados y herramientas no compatibles. La cobertura de un solo entorno de proveedor no resolverá un problema de agentes en la sombra multicloud.

La evidencia más sólida procederá de comparaciones independientes. Los equipos de seguridad necesitan pruebas que implementen agentes conocidos a través de varios canales y midan qué productos detectan cada componente.

Un registro útil debe identificar la propiedad, el propósito, la identidad, los permisos, las herramientas, las fuentes de datos y el estado del ciclo de vida. Una lista de nombres de agentes ofrece demasiado poco contexto para tomar decisiones de riesgo.

La segunda señal es la aplicación de controles en tiempo de ejecución. Los anuncios de productos prometen cada vez más bloquear el uso sospechoso de herramientas, restringir a los agentes mediante políticas y aplicar autorizaciones conscientes del contexto.

La medida importante no es si un producto puede generar una alerta. Es si el producto detiene una acción de alto impacto sin interrumpir el trabajo habitual.

Los falsos positivos importan porque los agentes pueden iniciar muchas operaciones. Un control que bloquea la actividad rutinaria animará a los equipos a desactivarlo o a buscar formas de sortearlo.

Los falsos negativos importan aún más. Una sola acción destructiva no detectada puede anular miles de solicitudes aprobadas correctamente.

Las empresas deberían probar los controles frente a la inyección de prompts, credenciales comprometidas, delegación excesiva, transferencia no autorizada de datos e intentos de modificar registros de auditoría. Las pruebas deberían incluir tanto implementaciones autorizadas como implementaciones en la sombra.

La tercera señal es una mejor divulgación de incidentes. La industria tecnológica cuenta con sistemas detallados para informar de vulnerabilidades de software, pero los fallos de los agentes no encajan claramente en esos canales.

Un conector vulnerable podría recibir un identificador convencional. Un agente que interpreta mal un objetivo, hereda acceso excesivo y elimina datos plantea una cuestión de responsabilidad más compleja.

¿El fallo fue causado por el modelo, el marco de trabajo del agente, el conector, el diseño de credenciales, la implementación o la instrucción humana? En muchos casos, contribuyeron varias capas.

Una comunicación coherente ayudaría a las organizaciones a comparar incidentes y mejorar los controles. También revelaría si los riesgos ampliamente debatidos se traducen en fallos recurrentes en producción.

Es probable que reguladores y auditores soliciten pruebas, no documentos de políticas. Una empresa debería poder mostrar qué agentes existían, quién era responsable de ellos, a qué accedían y cómo se controlaban las acciones de alto riesgo.

La respuesta práctica debería comenzar antes de que lleguen esas solicitudes. Los equipos de seguridad pueden inventariar los agentes conocidos, buscar los no aprobados, clasificar su autoridad y eliminar credenciales abandonadas.

También pueden definir un pequeño conjunto de acciones que siempre requieran controles más estrictos. La eliminación en producción, la publicación externa, los cambios de permisos y la exportación masiva de datos son puntos de partida razonables.

Los desarrolladores y trabajadores del conocimiento deberían preguntarse qué puede hacer un agente antes de centrarse en lo que puede generar. Los permisos detrás de una demostración impresionante determinan su verdadero riesgo empresarial.

Los líderes empresariales deberían preguntarse si la vía aprobada para los agentes es lo bastante accesible como para reducir la adopción en la sombra. Una gobernanza que solo existe sobre el papel perderá frente a una herramienta que un empleado puede instalar en cuestión de minutos.

Por tanto, el titular de Google News trata menos de una amenaza recién descubierta que de un reconocimiento tardío. El software autónomo ya ha entrado en los flujos de trabajo empresariales, mientras muchas organizaciones aún lo gestionan como si fuera otra aplicación.

Ese enfoque no se sostendrá. Cada agente de producción necesita una identidad, un responsable definido, autoridad limitada, acciones observables y una vía de retirada verificada.

Los próximos tres meses deberían revelar si los registros de agentes logran una cobertura creíble entre plataformas, si los controles en tiempo de ejecución superan pruebas realistas y si las divulgaciones de incidentes se vuelven más específicas.

Si aparecen esas señales, la gobernanza empresarial empieza a ponerse al día. Si no aparecen, el problema de los agentes en la sombra seguirá expandiéndose detrás de paneles que sugieren más control del que las organizaciones realmente poseen.