TL;DR: Este artigo analisa os novos controles de governança do Azure SRE Agent, incluindo tool permissions (Allow/Ask/Deny) e hooks (command e prompt hooks). A conclusão principal é que a Microsoft oferece uma abordagem em camadas — identidade, permissões granulares e hooks customizáveis — permitindo que times de plataforma e segurança definam limites claros para ações do agente em produção, com fallback seguro (fail-closed).
Quando um AI agent opera em produção, a primeira pergunta que todo time de segurança faz é: "O que ele pode fazer, quem decidiu isso e o que o impede de fazer algo que não deveria?" O Azure SRE Agent atingiu disponibilidade geral em março. Desde então, equipes dentro da Microsoft e clientes executando-o em cargas reais de produção pediram a mesma coisa: controles mais granulares sobre o que o agente pode fazer por conta própria e uma resposta clara sobre quem governa cada chamada que chega a uma ferramenta.
Hoje, no Build 2026, a Microsoft lançou as global tool access policies como parte de um conjunto de novos controles de governança. Este artigo analisa como eles funcionam. As políticas de acesso a ferramentas oferecem aos times de segurança e plataforma um único lugar para definir quais ferramentas o agente pode invocar, sob quais condições e o que requer aprovação humana antes de ser executado. Abaixo dessas políticas está a identidade sob a qual o agente executa — a base sobre a qual todas as outras camadas de controle dependem. É defesa em profundidade aplicada ao comportamento do agente: camadas de controle, cada uma sustentando-se por si só, para que governar o agente seja algo legível, auditável e raciocinável à medida que você o escala em produção.
Por que a identidade é a base fundamental: managed identity hoje, agent identity amanhã?
Comece por aqui, porque nada mais importa se você pular esta etapa. A identidade sob a qual o SRE Agent executa, e as atribuições de função RBAC do Azure nessa identidade, são o limite mais poderoso dentro do qual o agente trabalha. Se suas atribuições de função não concederem ao agente acesso a um recurso, nenhum dos controles abaixo entra em jogo, porque o agente não consegue alcançar o recurso para começar. Regras de rede, permissões de ferramentas, hooks e contratos de conectores ficam todos sobre uma história de RBAC que você escreve. Os recursos neste post adicionam camadas acima desse piso. Eles não o substituem.
Hoje, o SRE Agent opera como uma managed identity, e suas atribuições de função RBAC nessa identidade governam o que ele pode fazer. Essa é a base, e é o mesmo modelo que suas outras cargas de trabalho do Azure já usam. Você atribui funções, define escopos e o agente herda exatamente o que você concedeu e nada mais.
Tudo o que se segue pressupõe que a base está no lugar. Com a identidade resolvida, a próxima questão é óbvia: para onde o agente pode enviar seu tráfego?
Como as permissões governam o que o agente faz com uma ferramenta?
A identidade decide o que o agente pode alcançar. As permissões decidem o que o agente faz com o acesso que tem, até o nível de cada ferramenta. Dois níveis cobrem o espectro: uma grade de apontar e clicar para os casos comuns e hooks quando uma decisão precisa do seu próprio código.
A grade é o modo fácil. Cada ferramenta que o agente pode usar — ferramentas integradas junto com servidores MCP, serviços e ferramentas personalizadas — aparece em uma lista pesquisável com dois interruptores. On/Off define se a ferramenta está disponível; desligue-a e o agente não pode usá-la. Allow/Ask define o que acontece quando está ligada: Allow permite que o agente execute a ferramenta automaticamente, Ask exige aprovação humana toda vez, exceto no modo Autonomous. Selecione ferramentas em lote para alternar uma categoria inteira de uma vez, filtre por categoria ou permissão e use a aba Advanced permissions quando quiser regras que se aplicam em escopo global, por agente ou por thread, em vez de ferramenta por ferramenta. Os padrões permanecem até que você os toque, e o motor é fail-closed: se uma regra não puder ser avaliada, a chamada é bloqueada em vez de permitida. Isso cobre a maioria do que as equipes precisam.
Abaixo desses interruptores estão três regras — allow, ask e deny — e a aba Advanced é onde você as define por escopo. Regras globais se aplicam a todos os agentes e threads, regras de Agent a um agente personalizado, regras de Thread a uma única conversa. Deny é a regra forte: bloqueia a ferramenta completamente, independentemente do modo de execução, e um deny em escopo superior sempre vence, então um Allow em escopo de thread não pode reabrir algo negado globalmente. Essa divisão é deliberada: a equipe de plataforma define as guardrails globais que nunca devem ser cruzadas e os Asks que sempre precisam de um humano, e as equipes de serviço adicionam suas próprias regras Allow no escopo do Agent para trabalho rotineiro, sem poder substituir as guardrails acima deles.
Exemplo: equipe de plataforma, escopo Global:
- deny: bash(az * delete *) — nunca deletar, em nenhum agente ou thread
- deny: bash(kubectl delete *)
- ask: bash(az webapp restart *) — sempre confirmar, mesmo em Autonomous
- allow: bash(az monitor *) — auto-aprovar consultas de monitoramento
Exemplo: equipe de serviço, escopo Agent:
- allow: bash(kubectl get *) — trabalho rotineiro de leitura
- allow: bash(kubectl describe *)
Dois detalhes tornam isso seguro para usar. As regras correspondem à invocação canônica da ferramenta, não ao texto bruto, então a aplicação se mantém independentemente de como o comando foi montado. E o fail-closed tem uma borda mais suave do que uma parada brusca: uma política em cache (last-known-good) cobre falhas transitórias, então uma oscilação no armazenamento de políticas bloqueia a chamada em vez de ampliar silenciosamente o acesso.
A camada que vale a pena explorar são os hooks. Allow e Ask respondem "esta ferramenta deve ser executada?". Hooks respondem "esta chamada específica deve ser executada, dado exatamente o que ela está prestes a fazer?". Um hook é disparado antes de o agente executar uma ferramenta e recebe a chamada real, parâmetros e tudo. Seu código então decide o resultado e pode remodelá-lo: reescrever parâmetros antes de serem enviados, injetar contexto extra no pipeline como uma mensagem de usuário para que o agente reconsidere antes de seu próximo passo, bloquear a chamada completamente ou redirecionar o agente para um caminho mais seguro. Como seu código vê os parâmetros reais, a decisão pode depender de qualquer coisa que você possa expressar em código: qual recurso a chamada visa, se um valor está fora de um intervalo permitido, a hora do dia, o resultado de uma consulta de política externa. É aqui que você escreve a regra que a grade não consegue.
Dois tipos de hook, combináveis no mesmo agente. Command hooks são scripts que você escreve; use-os quando código é suficiente. Prompt hooks colocam um LLM separado no loop como um juiz que avalia a chamada em contexto; use-os quando a decisão precisa de raciocínio em vez de uma regra fixa. Um exemplo real do próprio agente de teste interno da Microsoft: quando o agente tenta listar arquivos via shell com ls ou dir, um hook bloqueia a chamada. O agente absorve o sinal, reconsidera e usa a ferramenta ListDir. O hook não discutiu com um humano. Ele moldou o que aconteceu em seguida. Assim como na grade, se você não configurar nada, o agente se comporta exatamente como hoje. Ambos são aditivos.
Criar um hook é um formulário curto. Você nomeia o hook, escolhe o evento (Pre Tool Use, para ser executado antes da chamada) e define um matcher de ferramenta, selecionado no menu ou escrito como regex como (FetchWebpage|SearchMemory) com âncoras e lookaheads quando necessário, para que o hook dispare apenas nas chamadas que interessam. Você define um timeout e um modo de falha (Block, para que um hook que erre ou trave pare a chamada em vez de deixá-la passar), e escreve o corpo em Bash ou Python. Um command hook lê a chamada como JSON no stdin — nome do evento, nome da ferramenta, parâmetros e ID da chamada — e responde no stdout. Não imprima nada e saia com zero para permitir. Retorne uma decisão de block com uma razão para parar a chamada, e essa razão é o que o agente lê de volta. Você também pode substituir: execute uma versão mais barata ou mais segura você mesmo, bloqueie a chamada real e entregue sua própria saída como resultado, para que o agente nunca execute o original caro ou arriscado.
#!/bin/bash
input=$(cat)
tool=$(echo "$input" | jq -r '.tool_name')
if [ "$tool" = "ExampleToolName" ]; then
echo '{"decision":"block","reason":"Blocked ExampleToolName by hook policy."}'
exit 0
fi
exit 0
Cada camada se sustenta por si só
As camadas se empilham. Identidade é o piso: suas atribuições RBAC decidem o que o agente pode alcançar. Permissões — a grade e os hooks juntos — decidem o que ele faz com uma ferramenta. Você cria cada camada, cada uma se sustenta independentemente de a camada acima dela se comportar como esperado, e tudo é configurado pela mesma superfície ARM e Bicep que sua equipe de plataforma já usa, reproduzível como o restante do seu patrimônio no Azure.
O caminho de atualização é aditivo e não quebra nada. Agentes existentes continuam funcionando. Ative cada controle quando estiver pronto, na ordem que sua governança exigir.
Há mais por vir. A Microsoft executa o Azure SRE Agent internamente em suas próprias cargas de produção, então sente as mesmas lacunas que você. A próxima rodada será moldada pelo que ouvirem de equipes executando-o em produção hoje. Qual controle está fazendo mais por você? E qual você ainda está esperando? Deixe seu feedback.
Perguntas Frequentes
-
Como o Azure SRE Agent lida com permissões em nível de ferramenta?
O agente usa uma grade de permissões com três regras: allow (execução automática), ask (aprovação humana obrigatória, exceto em modo autônomo) e deny (bloqueio total). As regras podem ser aplicadas em escopos global, por agente ou por thread, com deny de escopo superior sempre prevalecendo. -
O que são hooks e como eles diferem das permissões simples?
Hooks são scripts (command hooks) ou chamadas a um LLM (prompt hooks) que disparam antes de uma ferramenta ser executada. Diferentemente da grade, eles permitem decisões baseadas nos parâmetros reais da chamada — como recurso alvo, valor ou horário — e podem reescrever parâmetros, bloquear ou redirecionar a ação. -
É possível que um time de serviço ultrapasse as regras globais definidas pela plataforma?
Não. Uma regra deny definida no escopo global bloqueia a ferramenta em qualquer agente ou thread, e um allow em escopo inferior (agente ou thread) não pode reabri-la. Isso garante que a equipe de plataforma mantenha guardrails intransponíveis. -
O que acontece se uma regra de permissão não puder ser avaliada?
O sistema é fail-closed: se a avaliação falhar, a chamada é bloqueada. Para evitar interrupções por instabilidade no armazenamento de políticas, uma política em cache (last-known-good) é usada temporariamente, mas o comportamento padrão ainda é bloquear, nunca ampliar acesso. -
Como a identidade do agente se relaciona com os demais controles?
A identidade (managed identity) e as atribuições de RBAC são a camada mais fundamental. Se o agente não tiver acesso a um recurso via RBAC, os controles de permissão e hooks sequer entram em jogo. Os demais controles adicionam camadas acima dessa base, mas não a substituem.
Artigo originalmente publicado por Dalibor_Kovacevic em Azure Updates - Latest from Azure Charts.
