VNet Integration para Azure SRE Agent: Controle de Egress que Sua Segurança Já Deveria Ter

A preview da VNet Integration para Azure SRE Agent finalmente trata o tráfego de saída do agente como qualquer outra workload de produção: submete-o às mesmas regras de rede que você já aplica a databases, APIs internas e sistemas legados. Para times de SRE e segurança no Brasil, isso resolve um dilema clássico: como dar a um agente de IA acesso a logs, runbooks e repositórios sem abrir uma porta de exfiltração de dados ou vetor de ataque por prompt injection.

TL;DR: A preview da VNet Integration para o Azure SRE Agent permite controlar todo o tráfego de saída do agente usando sua própria VNet, NSG e DNS privado. Isso mitiga riscos de exfiltração de dados e prompt injection, já que o agente acessa logs, runbooks e repositórios internos. São três modos de egress (Unrestricted, Limited, Azure VNet), sendo o Azure VNet o recomendado para produção. A preview cobre apenas tráfego de saída; conexões de entrada e connectors ainda trafegam pela internet pública.

Por que o controle de egress é crítico para o SRE Agent?

Dois motivos principais. Primeiro, o agente lê dados sensíveis por design – logs de aplicação, código-fonte, configuração de infraestrutura e sistemas internos. Durante um incidente, ele precisa desses recursos para diagnosticar e agir. Sem controle de saída, qualquer dado que ele acesse pode ser enviado para fora da sua rede, um risco que você não aceitaria para nenhuma outra workload adjacente à produção.

Segundo, o agente raciocina sobre texto que não escreveu – logs, descrições de issues, saídas de ferramentas – exatamente o cenário onde prompt injection acontece. A proteção contra isso envolve segurança do modelo (Microsoft segue padrões Responsible AI com OpenAI e Anthropic), mas o controle de rede adiciona uma camada infalível: uma instrução que tente alcançar um destino não autorizado simplesmente não consegue, porque a rede bloqueia.

Exemplo: um agente investigando uma queda de performance pode consultar o Log Analytics, ler a configuração de deployment e chamar um runbook interno – todos recursos privados. Com VNet Integration, essas chamadas seguem as rotas, DNS e regras de firewall que suas workloads já usam. Uma requisição para um endpoint externo não autorizado falha na borda da rede, independentemente de o modelo reconhecer ou não o risco.

Como escolher o modo de egress ideal?

O Azure SRE Agent oferece três modos, e você não precisa começar pelo mais restritivo:

• Unrestricted – todo tráfego de saída permitido.
• Limited – nega tudo, permite uma lista explícita de hosts. Dá controle em nível de host sem precisar configurar uma VNet completa.
• Azure VNet (recomendado) – tráfego de saída passa por uma sub-rede delegada na sua rede, com suas regras de NSG e DNS privado. Ideal para produção e workloads regulados.

Como funciona o modo Azure VNet na prática?

O tráfego de saída segue exatamente um de dois caminhos:

1. Sua VNet: tudo que não estiver no caminho gerenciado passa pela sub-rede delegada, onde suas NSG rules, DNS privado e firewall se aplicam. O agente se comporta como qualquer workload naquela sub-rede – pode acessar databases atrás de private endpoints, serviços internos, monitoring stores e key vaults. Se sua rede tem conectividade on-premises via ExpressRoute ou VPN, o agente alcança esses sistemas também, desde que suas rotas e regras permitam.

2. Caminho gerenciado (managed infra path): alguns destinos vão pela rede de infraestrutura gerenciada do Azure SRE Agent – serviços de plataforma que o agente precisa, mais categorias opcionais que você ativa: package registries, code repositories e remote MCP servers. Esse caminho pula sua VNet, então suas NSG e Firewall Policies não se aplicam. Trate como uma exceção deliberada, use só onde necessário.

Por que serviços públicos começam no caminho gerenciado?

GitHub, PyPI, npm, NuGet, apt e container registries operam em ranges de IP grandes e mutáveis, que não mapeiam para um único service tag do Azure. Manter listas de IP atualizadas em NSGs é trabalho constante – e quando a lista fica desatualizada, o agente não consegue puxar um pacote ou ler um repositório, travando uma investigação por um problema de rede que nada tem a ver com o incidente.

Cada categoria tem um toggle: package registries, code repositories, remote MCP servers e uma lista de hostnames adicionais. Começar com eles no caminho gerenciado mantém o agente funcionando sem exigir manutenção de allowlist de IP. Para dependências de build, isso normalmente é suficiente.

Se você quiser que esse tráfego também seja inspecionado, o próximo passo é fazer filtragem de egress baseada em FQDN (nome) no seu firewall. Quando seu firewall conseguir permitir github.com e pypi.org por nome, você pode mover essas categorias para fora do caminho gerenciado e roteá-las pela sua VNet.

Como configurar a VNet Integration?

Duas decisões principais: a sub-rede e o que (se algo) usa o bypass.

1. Navegue até Settings > Workspace Configuration > Network.
2. Escolha Azure VNet como modo de egress.
3. Selecione uma sub-rede /28 ou maior, delegada a Microsoft.App/environments.
4. Decida quais categorias (se alguma) usarão o bypass.
5. Restrinja quem pode alterar o modo de egress e os toggles de bypass – essas configurações ampliam ou reduzem o alcance do agente, então governe-as como qualquer controle de rede de produção.
6. Teste o comportamento de saída antes de usar o agente com dados de produção.

Uma configuração razoável para a maioria das empresas durante a preview: use Azure VNet mode, mantenha package registries e code repositories no bypass se precisar de acesso confiável a eles, e roteie todo o resto pela sua VNet. Ambientes mais restritivos podem desligar essas categorias e depender de suas próprias regras de firewall baseadas em nome.

O que essa preview ainda não cobre?

Duas limitações importantes: a VNet Integration cobre apenas tráfego de saída – acessar o agente privadamente de dentro da sua rede não faz parte desta preview. Além disso, o tráfego de connectors ainda passa pela internet pública; as políticas de governança e isolamento de credenciais do Connectors V2 continuam valendo.

Use a VNet Integration para controle de saída do workspace do agente, e combine com identity, RBAC, tool permissions e connector governance para um conjunto completo de controles.

Onde ela se encaixa na sua estratégia de segurança?

VNet Integration não substitui identity, RBAC, tool permissions ou connector governance. Ela controla para onde o tráfego pode ir. O agente ainda precisa da identidade e permissões corretas para acessar um recurso.

Identity é a fundação: suas atribuições RBAC decidem o que o agente pode alcançar. Permissions e hooks moldam o que ele faz dentro desse alcance: regras allow/ask/deny controlam o que é executado, e hooks permitem inspecionar ou alterar uma chamada de ferramenta antes da execução. A VNet Integration fica por baixo, controlando para onde o tráfego pode ir independentemente do que o agente tente fazer.

Você quer o agente capaz. Você também quer uma fronteira que se mantenha, quer ele se comporte bem ou não.

Perguntas Frequentes

• O que é VNet Integration para Azure SRE Agent e por que devo me importar?
  É uma funcionalidade em preview que direciona o tráfego de saída do agente SRE para uma sub-rede delegada dentro da sua própria VNet, aplicando suas regras de NSG, firewall e DNS privado. Isso impede que dados sensíveis (logs, configurações, runbooks) saiam da rede sem controle, e bloqueia tentativas de prompt injection que tentem enviar comandos para destinos não autorizados.

• Quais são os modos de egress disponíveis e qual usar em produção?
  Três modos: Unrestricted (todo tráfego permitido), Limited (nega tudo, permite lista explícita de hosts) e Azure VNet (tráfego passa pela sua VNet com NSG e DNS privado). O Azure VNet é o modo recomendado para produção e workloads regulados, pois oferece controle granular sem depender apenas do comportamento correto do modelo de IA.

• Como funciona o caminho gerenciado (managed infra path) e quando usá-lo?
  Alguns destinos – como PyPI, npm, GitHub, Azure DevOps e servidores MCP – podem ser roteados por uma infraestrutura gerenciada da Azure, ignorando sua VNet. Isso evita a complexidade de manter listas de IPs de serviços públicos que mudam constantemente. Você pode ativar ou desativar cada categoria por toggle, e migrar para filtragem baseada em FQDN quando seu firewall suportar.

• Quais são as limitações atuais da preview?
  Duas principais: 1) Cobre apenas tráfego de saída – não é possível acessar o agente privadamente de dentro da rede; 2) O tráfego de connectors ainda passa pela internet pública, sujeito às políticas de governança e isolamento de credenciais do Connectors V2. A Microsoft recomenda combinar VNet Integration com identity, RBAC, tool permissions e hooks para uma segurança completa.

• Como configuro a VNet Integration no Azure SRE Agent?
  Vá em Settings > Workspace Configuration > Network, escolha Azure VNet como modo de egress, selecione uma sub-rede /28 ou maior delegada a Microsoft.App/environments, decida quais categorias usarão o bypass (package registries, code repositories, MCP servers) e restrinja quem pode alterar essas configurações. Teste o comportamento de saída antes de usar com dados de produção.

---

Artigo originalmente publicado por sanchitmehta em Azure Updates - Latest from Azure Charts.