Michael JohnsonUm agente de IA pode identificar por que uma conexão de rede está falhando e, em seguida, propor uma correção que afete a infraestrutura em produção. Em um artigo de engenharia publicado em 13 de outubro, a Microsoft descreveu uma arquitetura em camadas na qual regras de software independentes limitam o acesso do agente e verificam suas ações.
O autor do artigo, Arun Malik, engenheiro principal de Azure Networking na Microsoft, analisa um cenário de conexão instável em um datacenter. O agente coleta o estado dos dispositivos e a telemetria, relaciona alterações recentes, classifica a falha e prepara um resumo. Em seguida, o sistema pode avançar para uma correção — por exemplo, desativar uma sessão BGP em um dispositivo que transporta tráfego de usuários — por meio dos mecanismos de controle previstos na arquitetura.
A Microsoft descreve quatro limites: identidade, ferramentas, alterações e tempo. O agente atua dentro das permissões da pessoa que o acionou, acessa os sistemas por uma interface controlada, para antes de alterar o estado de produção para obter aprovação humana e, com o tempo, procedimentos repetitivos bem-sucedidos podem ser consolidados como procedimentos determinísticos.
As permissões do agente acompanham as do usuário
O primeiro limite são as credenciais. No modelo proposto, o agente atua em nome do usuário e não recebe permissões além das dele. Se for necessária uma conta de serviço, suas permissões devem ser ainda mais restritas. Isso limita as consequências de erros ou de textos maliciosos presentes em logs e respostas de ferramentas: o modelo não pode obter privilégios que não estejam disponíveis ao usuário ou à conta dedicada.
O segundo limite são as ferramentas. Cada operação é definida por meio de uma interface tipada, passa por uma autorização específica, aceita dados de entrada estruturados e deixa um registro de auditoria. Malik esclarece que o alvo das restrições não é a linha de comando em si, mas o acesso irrestrito ao shell: um comando limitado pode ser oferecido como ferramenta controlada, enquanto o acesso livre ao shell dificulta a separação de permissões e a auditoria.
Leitura e alteração exigem regras diferentes
Na arquitetura descrita, o diagnóstico pode ser executado automaticamente. Uma ação que altere o estado de um sistema em produção é suspensa até a aprovação de uma pessoa. Segundo o autor, essa restrição deve ser imposta pelo código do ambiente de execução, e não apenas por uma instrução dada ao modelo. O modelo pode analisar a saída não estruturada de um dispositivo, mas a decisão de agir e a verificação de permissões permanecem sob responsabilidade da lógica do software.
O artigo apresenta um exemplo com uma interface de rede: o modelo converte a saída de um comando em campos estruturados, um validador verifica esses campos em relação a um esquema e uma condição determinística seleciona a próxima ação. Se uma etapa alterar a configuração, a execução aguarda aprovação. Assim, o texto da tarefa fica separado das permissões para modificar a rede.
O quarto limite diz respeito à repetibilidade. A Microsoft propõe consolidar fluxos de diagnóstico já validados como procedimentos determinísticos, que podem ser executados sem uma nova chamada ao modelo em situações conhecidas. Segundo a empresa, isso reduz os custos de raciocínio repetido, aumenta a reprodutibilidade e diminui a superfície de erros e ataques. A publicação não apresenta resultados quantitativos de implantação em produção.
O que vale a pena verificar na implantação
O material da Microsoft é uma descrição de engenharia de uma arquitetura e de um cenário, não uma avaliação independente da confiabilidade de um produto pronto. Uma sequência prática para equipes que projetam seus próprios agentes é vincular as ações à identidade do usuário, enumerar as operações permitidas, tipar e registrar as chamadas, separar leitura de escrita e exigir aprovação explícita para alterações. Casos repetitivos podem ser convertidos em procedimentos convencionais após a validação das condições de execução e dos resultados.
A conclusão principal diz respeito à separação de funções: o modelo ajuda a analisar incidentes desconhecidos e a produzir resultados estruturados, enquanto o sistema de execução determina quais operações são permitidas e quando é necessária uma aprovação. É essa separação que a Microsoft propõe para passar de sugestões ao operador a uma automação limitada da infraestrutura de rede.