Por que o app está lento? O threat model da Microsoft pergunta o que mais o agente do Azure pode fazer

Um engenheiro de plantão abre um incidente e pergunta a um assistente de IA: “Por que este aplicativo está lento?” O assistente consulta o Azure Monitor, lê o Log Analytics, inspeciona a configuração do App Service e compara com um deploy saudável. Um trabalho que exigia várias telas do portal, comandos de CLI e consultas Kusto acontece em uma conversa.

Agora conecte o mesmo assistente à sessão do Azure do próprio engenheiro. Essa sessão provavelmente pode reiniciar workloads, alterar regras de rede e ler segredos do Key Vault, em várias assinaturas. A pergunta era diagnóstica. A autoridade não é.

Essa lacuna é o ponto de partida de um threat model que a Microsoft publicou em 16 de outubro para assistentes de IA conectados ao Azure por meio do Azure MCP Server. É orientação, não lançamento de produto, e seu valor está em ser específico para uma plataforma. Conselho genérico sobre agentes e prompt injection é fácil de encontrar; uma lista do que dá errado quando um agente mexe em assinaturas, atribuições de função e workspaces do Log Analytics, não.

A superfície de leitura e a superfície de escrita

Uma investigação de latência precisa de uma superfície de leitura pequena. Uma sessão pessoal emprestada carrega uma superfície de escrita grande. A primeira ameaça da Microsoft é esse descompasso: um erro do modelo ou um cliente comprometido vira risco de plano de controle porque a identidade pode fazer muito mais do que a tarefa exige.

Os controles recomendados são os comuns do Azure: uma identidade dedicada ou gerenciada por workflow, atribuições de função com escopo no grupo de recursos ou no recurso, funções personalizadas quando as internas são amplas demais, funções de diagnóstico separadas das funções de remediação, e Privileged Identity Management para elevação por tempo limitado. Uma frase do post merece ser repetida para todo time que configura ferramentas de agente: a filtragem de ferramentas é útil, mas não é autorização. Esconder uma ferramenta do agente não impede que a identidade chame a API por outra rota. O provedor de recursos precisa negar.

O guia também avisa que atribuições de função do Azure são aditivas. Conceder Reader a uma identidade de teste não remove permissões mais amplas que ela herda por meio de um grupo, de uma assinatura ou de um grupo de gerenciamento. A autoridade real de um agente é o acesso efetivo dele, não a função que você acabou de atribuir.

Logs são escritos por estranhos

O Azure Monitor e o Log Analytics guardam texto de caminhos de requisição, mensagens de exceção, user agents e tickets, e parte dele é controlada por atacantes. O exemplo da Microsoft é uma linha de log dizendo ao assistente para buscar uma connection string do Key Vault e enviá-la a um endpoint. Isso é dado, não uma instrução do engenheiro.

A resposta estrutural não é um prompt melhor. Uma identidade de diagnóstico deve simplesmente não ter secrets/get no Key Vault nem acesso de escrita à produção, para que um assistente manipulado peça e receba uma recusa. Fizemos o mesmo argumento sobre funções de execução de agentes que decidem o dano em outra nuvem.

Erros que não precisam de atacante

A parte mais prática do guia cobre falhas sem nenhum adversário: a assinatura errada, dois grupos de recursos com nomes parecidos, um ID de recurso de staging, “reiniciar a instância não saudável” interpretado como permissão para reiniciar um serviço inteiro. A validação de schema confere se um argumento tem o tipo certo. Operações no Azure também precisam de validação semântica: este tenant, assinatura, grupo de recursos e recurso são os aprovados para o workflow, e a janela de mudança está aberta?

Para ações consequentes, a Microsoft propõe uma sequência fixa: propor, validar alvo e argumentos, obter aprovação, executar, verificar o estado do recurso. A aprovação mostra a assinatura exata, o recurso, a operação, os parâmetros, o impacto esperado e o plano de rollback, e se qualquer um desses valores mudar, a aprovação é anulada. Para produção, o assistente pode preparar um deploy ou um pull request enquanto o processo de mudança existente o executa.

Dois pontos menores vão poupar alguém de uma queda. Um timeout não prova que uma operação falhou, então consulte a operação e o estado do recurso antes de tentar de novo. E o Azure Activity Log normalmente não registra leituras, então uma investigação que precisa saber o que um agente olhou depende dos logs de diagnóstico do recurso e dos logs do próprio servidor MCP.

Interpretação e autoridade ficam em mãos diferentes

O assistente

• Lê telemetria aprovada
• Correlaciona e explica
• Propõe uma mudança com o alvo exato

Pode errar ou ser manipulado

Azure

• Identidade Entra e escopo RBAC
• Modo somente leitura do servidor e seleção de ferramentas
• Aprovação vinculada ao alvo exato
• Logs de atividade, de recurso e do MCP

Decide o que realmente acontece

Teste as recusas antes de conceder o acesso

O guia termina com uma demo somente leitura que conecta o GitHub Copilot no Visual Studio Code ao Azure MCP Server com uma identidade de teste dedicada, um conjunto estreito de namespaces de serviço e modo somente leitura. O passo mais reutilizável é a lista de pedidos que precisam falhar: reiniciar o app, ler um segredo do Key Vault, atribuir Contributor à conta do agente, consultar outra assinatura, seguir uma instrução plantada em um log. Cada um deve ser recusado pela configuração ou pelo RBAC, não pelo bom senso do modelo. Se um funcionar, a identidade está errada, e a correção está no Azure, não no prompt.

Essa checklist é o critério de aprovação certo para qualquer agente de infraestrutura em qualquer nuvem. Expanda o acesso só quando o time conseguir mostrar que o comportamento de falha é imposto, o mesmo princípio por trás de agentes que nunca seguram uma credencial. A Microsoft também desaconselha rodar um Azure MCP Server local com dados ou credenciais de produção; um deploy de produção precisa da própria arquitetura revisada.