Un agente de Azure diagnostica una app lenta. El modelo de amenazas pregunta qué más podría hacer

Un ingeniero de guardia abre un incidente y pregunta a un asistente de IA: ¿por qué va lenta esta aplicación? El asistente consulta Azure Monitor, lee Log Analytics, inspecciona la configuración de App Service y la compara con un despliegue saludable. El trabajo que ocupaba varias hojas del portal, comandos de CLI y consultas Kusto ocurre en una sola conversación.

Ahora conecte el mismo asistente con la propia sesión de Azure del ingeniero. Esa sesión probablemente puede reiniciar cargas de trabajo, cambiar reglas de red y leer secretos de Key Vault en varias suscripciones. La pregunta era de diagnóstico. La autoridad no.

Esa brecha es el punto de partida de un modelo de amenazas que Microsoft publicó el 16 de octubre para asistentes de IA conectados a Azure mediante Azure MCP Server. Es una guía, no el lanzamiento de un producto, y su valor es que es específica de una plataforma. El consejo genérico sobre agentes e inyección de prompt es fácil de encontrar; una lista de lo que sale mal cuando un agente toca suscripciones, asignaciones de rol y espacios de trabajo de Log Analytics no lo es.

La superficie de lectura y la superficie de escritura

Una investigación de latencia necesita una superficie de lectura pequeña. Una sesión personal prestada carga una superficie de escritura grande. La primera amenaza de Microsoft es ese desajuste: un error del modelo o un cliente comprometido se convierte en un riesgo del plano de control porque la identidad puede hacer mucho más de lo que la tarea requiere.

Los controles recomendados son los habituales de Azure: una identidad dedicada o administrada por workflow, asignaciones de rol limitadas al grupo de recursos o al recurso, roles personalizados cuando los integrados son demasiado amplios, roles de diagnóstico separados de los de remediación y Privileged Identity Management para elevación limitada en el tiempo. Una frase del artículo merece repetirse a cada equipo que configura herramientas de agente: el filtrado de herramientas es útil, pero no es autorización. Ocultar una herramienta al agente no impide que la identidad llame a la API por otra ruta. El proveedor de recursos tiene que denegarlo.

La guía también advierte de que las asignaciones de rol de Azure son aditivas. Conceder Reader a una identidad de prueba no elimina permisos más amplios que hereda a través de un grupo, una suscripción o un grupo de administración. La autoridad real de un agente es su acceso efectivo, no el rol que acaba de asignar.

Los logs los escriben desconocidos

Azure Monitor y Log Analytics contienen texto de rutas de solicitud, mensajes de excepción, user agents y tickets, y parte está controlada por el atacante. El ejemplo de Microsoft es una línea de log que le dice al asistente que obtenga una cadena de conexión de Key Vault y la envíe a un endpoint. Eso son datos, no una instrucción del ingeniero.

La respuesta estructural no es mejorar el prompt. Una identidad de diagnóstico simplemente debería carecer de secrets/get en Key Vault y de acceso de escritura a producción, para que un asistente manipulado pregunte y reciba una negativa. Defendimos el mismo argumento sobre los roles de ejecución de agentes que deciden el daño en otra nube.

Errores que no necesitan atacante

La parte más práctica de la guía cubre fallos sin ningún adversario: la suscripción equivocada, dos grupos de recursos con nombres parecidos, un ID de recurso de staging, “reiniciar la instancia no saludable” leído como permiso para reiniciar todo un servicio. La validación de esquema comprueba que un argumento tenga el tipo correcto. Las operaciones de Azure también necesitan validación semántica: ¿este tenant, esta suscripción, este grupo de recursos y este recurso son los que el workflow tiene aprobados, y está abierta la ventana de cambio?

Para acciones con consecuencias, Microsoft propone una secuencia fija: proponer, validar el destino y los argumentos, obtener aprobación, ejecutar, verificar el estado del recurso. La aprobación muestra la suscripción, el recurso, la operación, los parámetros, el impacto esperado y el plan de rollback exactos, y si cualquiera de esos valores cambia, la aprobación queda anulada. En producción, el asistente puede preparar un despliegue o un pull request mientras el proceso de cambio existente lo ejecuta.

Dos puntos menores evitarán una caída a alguien. Un timeout no demuestra que una operación haya fallado, así que consulte el estado de la operación y del recurso antes de reintentar. Y el Azure Activity Log normalmente no registra lecturas, así que una investigación que necesite saber qué miró un agente depende de los logs de diagnóstico del recurso y de los logs del propio servidor MCP.

La interpretación y la autoridad quedan en manos distintas

El asistente

• Lee telemetría aprobada
• Correlaciona y explica
• Propone un cambio con su destino exacto

Puede equivocarse o ser manipulado

Azure

• Identidad de Entra y ámbito de RBAC
• Modo de servidor de solo lectura y selección de herramientas
• Aprobación ligada al destino exacto
• Logs de actividad, de recurso y de MCP

Decide lo que ocurre realmente

Pruebe las denegaciones antes de conceder el acceso

La guía termina con una demo de solo lectura que conecta GitHub Copilot en Visual Studio Code a Azure MCP Server con una identidad de prueba dedicada, un conjunto estrecho de espacios de nombres de servicio y modo de solo lectura. Su paso más reutilizable es la lista de solicitudes que deben fallar: reiniciar la app, leer un secreto de Key Vault, asignar Contributor a la cuenta del agente, consultar otra suscripción, seguir una instrucción plantada en un log. Cada una debería ser denegada por configuración o por RBAC, no por el buen juicio del modelo. Si una tiene éxito, la identidad está mal y la corrección está en Azure, no en el prompt.

Esa lista de comprobación es la puerta correcta para cualquier agente de infraestructura en cualquier nube. Amplíe el acceso solo cuando el equipo pueda demostrar que se aplica el comportamiento ante fallos, el mismo principio que hay detrás de agentes que nunca tienen una credencial. Microsoft también aconseja no ejecutar en absoluto un Azure MCP Server local con datos o credenciales de producción; un despliegue en producción necesita su propia arquitectura revisada.