O checklist de segurança foi aprovado sem uma ressalva. Public network access desabilitado, private endpoint criado, tráfego saindo pela VNet, diagrama com cadeado em cima do recurso. Três semanas depois o agente entrou em produção com uma ferramenta HTTP, alguém apontou essa ferramenta para um endpoint externo e o conteúdo de um documento interno saiu do ambiente pela porta 443 — a mesma porta que o NSG libera para todo mundo. Ninguém violou a rede privada. A rede privada simplesmente nunca teve opinião sobre aquele caminho. O private endpoint fecha a porta de entrada; ele não sabe nada sobre a porta de saída, e um agente com ferramenta é, por definição, uma máquina de saída.

As três fronteiras Uma carga de IA tem três fronteiras diferentes, e a maioria dos projetos protege bem uma delas e presume que as outras vieram junto. A fronteira de entrada decide quem alcança o recurso — é o território do private endpoint e do DNS privado. A fronteira de identidade decide quem pode fazer o quê depois de alcançar — é o território do Entra ID e do desligamento da chave. A fronteira de saída decide para onde o seu dado pode ir — é o território do controle de egresso, e é a que quase sempre fica aberta. As três precisam ser fechadas separadamente, porque nenhuma delas é consequência da outra.

O que é isolar uma carga de IA em rede?

Isolar uma carga de IA não é “colocar num private endpoint”. É retirar quatro superfícies do alcance da internet pública ao mesmo tempo: o endpoint de inferência, a identidade que chama esse endpoint, o egresso de quem executa a tarefa e o armazenamento onde o estado da tarefa mora.

O ponto de partida mudou de forma. O recurso atual do Microsoft Foundry é um Microsoft.CognitiveServices/accounts com kind: AIServices, e os projetos são sub-recursos dele. O modelo antigo — hub baseado em Microsoft.MachineLearningServices/workspaces — continua funcionando, mas agora é documentado como Foundry (classic), e o investimento novo está no primeiro. Isso importa para rede porque os dois têm superfícies de isolamento diferentes, e boa parte do material que circula na internet descreve o modelo antigo.

O contraste que importa: o private endpoint responde “quem consegue me alcançar?”. Ele não responde “quem é você” nem “para onde você pode escrever”. Essas duas perguntas têm donos próprios, e é por isso que existem três fronteiras e não uma.

O problema que resolve

Uma carga de IA rompe a suposição em que a segurança de rede tradicional se apoia: a de que a aplicação fala com um conjunto conhecido e estável de destinos. Um agente com tool calling é o oposto disso. Ele decide em tempo de execução qual ferramenta chamar, e cada ferramenta é uma conexão de saída — um servidor MCP, uma API de terceiro, uma busca na web. A lista de destinos deixou de ser uma propriedade do deploy e passou a ser uma propriedade da conversa.

Some a isso um detalhe que muda a conta de risco: o agente lê texto que ninguém controla. Um documento recuperado pode conter instrução plantada, e o agente tem credencial válida, está dentro do perímetro e alcança os sistemas internos por private endpoint. Nesse desenho, o egresso não é um detalhe operacional — é o único lugar onde a exfiltração pode ser barrada.

Os quatro erros que eu mais encontro em campo:

1. Confundir private endpoint com perímetro. Ele controla ingresso. O caminho de saída continua governado por outra coisa — ou por nada.
2. Criar o private endpoint e esquecer o DNS. A zona privada existe, mas não foi vinculada à VNet. O nome resolve para o IP público e a conexão falha de um jeito que não parece problema de DNS.
3. Deixar a chave de API viva. Enquanto disableLocalAuth for false, quem tiver a string tem acesso total ao recurso — sem papel, sem escopo, sem Conditional Access. Todo o desenho de RBAC vira decoração.
4. Achar que NSG resolve egresso. NSG é camada 4. Ele libera ou bloqueia a porta 443, não o destino. Controle de saída por FQDN é camada 7.

Como funciona — passo a passo

1. Decida o modelo de rede antes de criar o recurso. Para agentes hospedados, a injeção de VNet precisa entrar na criação da conta Foundry: adicionar depois não é suportado. Essa é uma decisão irreversível disfarçada de configuração.
2. Reserve as sub-redes com folga. A sub-rede do agente precisa de delegação a Microsoft.App/environments. O mínimo é /27, mas o recomendado para produção é /24 — e ela não pode ser compartilhada entre dois recursos Foundry.
3. Use apenas faixas RFC 1918. 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16. Faixas públicas e CGNAT (100.64.0.0/10) não são suportadas na sub-rede delegada e falham na criação.
4. Crie o private endpoint de entrada e desabilite o acesso público. No setup padrão com rede privada, contas e projetos já nascem com Public network access Disabled, e a regra vale para todos os protocolos, inclusive WebSocket.
5. Configure as três zonas de DNS do Foundry. Não é uma: são três, e a razão está na próxima seção.
6. Crie os private endpoints dos recursos dependentes — na mão. Os endpoints de Azure AI Search, Storage e Cosmos DB não são criados automaticamente junto com o recurso Foundry.
7. Desligue a chave e distribua papéis. disableLocalAuth: true no recurso e Foundry User para quem constrói, no escopo do projeto.
8. Feche o egresso. Firewall com regra de FQDN ou modo de saída aprovada. Sem isso, tudo o que veio antes protege metade do caminho.
9. Valide resolvendo nome de dentro da VNet. nslookup em cada FQDN, a partir de uma máquina na rede, conferindo se o retorno é IP privado.

A fronteira de entrada: private endpoint e as três zonas de DNS

Aqui está o detalhe que derruba mais implantação do que qualquer outro: um recurso Foundry precisa de três zonas de DNS privado, não de uma.

A razão é que o mesmo recurso Foundry expõe três sufixos de endpoint diferentes, e qual deles você usa depende do SDK: o SDK antigo do Azure OpenAI fala com openai.azure.com, o de Cognitive Services com cognitiveservices.azure.com e o SDK novo do Foundry com services.ai.azure.com. Configurar só a zona que o seu código usa hoje funciona — até o dia em que alguém troca de biblioteca e o nome volta a resolver para o IP público.

E existe uma sutileza cruel no modo como isso falha. Criar a zona não basta: ela precisa do virtual network link para a VNet. Sem o vínculo, o CNAME público continua resolvendo para o endpoint público, a requisição sai pela internet e o erro que você recebe não menciona DNS em lugar nenhum. Em topologia hub-and-spoke com DNS próprio, o caminho é encaminhador condicional apontando para o Azure DNS Virtual Server, 168.63.129.16.

Um sintoma clássico vale mais que um parágrafo de teoria: Timeout of 60000ms exceeded ao abrir as páginas de Agents no projeto é, na documentação, o retrato de um projeto que não consegue falar com o Cosmos DB — private endpoint ou DNS. Não é lentidão de portal.

A fronteira de identidade: a chave é o buraco no seu desenho de RBAC

Rede resolvida, resta a pergunta que a rede não responde: quem é quem. E aqui vale ser direto — enquanto a chave de API estiver ativa, o seu RBAC é ornamental. A documentação do Foundry diz isso quase com essas palavras: os papéis valem quando a autenticação é via Microsoft Entra ID; com autenticação por chave, a chave concede acesso total, sem restrição de papel.

A correção é disableLocalAuth: true no recurso, com uma ressalva operacional que precisa entrar no seu plano de corte: a mudança não é instantânea. A propagação costuma levar minutos, mas pode levar horas dependendo de região, carga e estado de cache do gateway. Ou seja: desligar a chave não é um controle que você aciona no meio de um incidente.

A segunda armadilha é escolher o papel errado — e ela ficou pior porque os papéis foram renomeados recentemente. Azure AI User, Azure AI Owner, Azure AI Account Owner e Azure AI Project Manager viraram Foundry User, Foundry Owner, Foundry Account Owner e Foundry Project Manager. Os IDs e as permissões continuam os mesmos, mas os dois nomes ainda circulam. Em script, use o GUID.

E o aviso explícito que economiza uma tarde de depuração: não use papéis que começam com Cognitive Services para cenários Foundry — eles servem para acessar recursos de AI Services diretamente. Pelo mesmo motivo, não use Azure AI Developer: apesar do nome, o escopo dele é workspace do Azure Machine Learning e hub do Foundry, não projeto do Foundry nem agente hospedado. Para projeto, é Foundry User ou Foundry Owner.

Vale registrar o que está se desenhando ao lado disso: o Microsoft Entra Agent ID, anunciado no Ignite de 2025 e ainda em preview pública, dá a cada agente uma identidade própria no diretório, ao lado das identidades humanas — com Conditional Access, trilha de auditoria e ciclo de vida. É a direção certa para o problema de agente tratado como aplicação genérica, mas ainda não é onde se apoia um desenho de produção.

A fronteira de saída: onde a maioria dos projetos para de proteger

Esta é a fronteira esquecida, e a razão é cultural: a segurança de rede clássica foi construída para proteger o que entra. Numa carga de IA, o valor está no que sai.

O modelo mais forte é a rede virtual gerenciada em modo AllowOnlyApprovedOutbound. Nele, todo o egresso é negado por padrão e só passa o que estiver liberado por service tag, private endpoint ou regra de FQDN — e regras de FQDN valem apenas para as portas 80 e 443. Três consequências práticas que precisam entrar na decisão:

• Adicionar a primeira regra de FQDN provisiona um Azure Firewall gerenciado, com o custo correspondente. Não dá para trazer o seu próprio firewall para dentro da rede gerenciada, e cada conta Foundry tem o seu.
• Os modos são caminho de mão única. Depois de AllowInternetOutbound não se volta para Disabled; depois de AllowOnlyApprovedOutbound não se volta para AllowInternetOutbound.
• O portal não cria rede gerenciada. É CLI, Bicep ou Terraform — e o grupo de comandos az cognitiveservices account managed-network está marcado como preview.

Na alternativa com VNet própria, o desenho é o clássico: Azure Firewall em sub-rede dedicada e UDR forçando a saída da sub-rede do agente para o firewall, com regras de aplicação por FQDN. Aqui entram duas exigências específicas que costumam ser descobertas em produção:

• É preciso liberar os FQDNs de Managed Identity do Azure Container Apps, ou a service tag AzureActiveDirectory. Sem isso, o agente não consegue nem obter token.
• Não pode haver inspeção de TLS no firewall. Um certificado autoassinado injetado no caminho quebra o agente de um jeito silencioso.

O contraste com NSG merece uma linha própria, porque é onde mora o mal-entendido: um NSG que libera 443 de saída libera todos os destinos na 443. Ele não tem vocabulário para dizer “pode falar com a API do ERP e não pode falar com um bucket qualquer”. Essa frase só existe em camada 7.

usuário → App Gateway (WAF) → App Service na VNet
                                    │
                                    ├─ private endpoint → Foundry (inferência)
                                    │                        │
                                    │                        ├─ PE → Azure AI Search
                                    │                        ├─ PE → Cosmos DB
                                    │                        └─ PE → Storage
                                    │
                                    └─ ferramenta externa → Azure Firewall (FQDN) → internet

A arquitetura de referência baseline do Foundry chat monta exatamente isso: Application Gateway com WAF como entrada em camada 7, App Service integrado à VNet, todos os PaaS por private endpoint, Azure Firewall inspecionando a saída e um jump box atrás do Azure Bastion para administração. Vale notar que a referência usa Application Gateway, não Front Door.

Onde o dado realmente mora

Fechadas as três fronteiras, sobra a pergunta de compliance: o estado do agente fica onde? No setup padrão, a resposta é “no seu tenant”, porque ele exige três recursos BYO — e os três, não dois:

Não é opcional nem parcial: tentar criar um agente padrão seguro sem os três devolve erro de capability host reclamando que a propriedade de conexão precisa de um valor. O Cosmos DB precisa ser NoSQL, e o dimensionamento inicial é 3.000 RU/s — cinco containers de 1.000 RU/s no banco enterprise_memory.

Duas restrições de topologia que mudam custo e desenho: o recurso Foundry precisa estar na mesma região da VNet; Cosmos DB, AI Search e Storage podem estar em outra, com o custo de tráfego entre regiões que isso implica. E, para chave gerenciada pelo cliente (CMK), a migração é de mão única — dá para sair de chave gerenciada pela Microsoft para CMK, não dá para voltar.

Os erros que aparecem quando falta uma peça

Vale conhecer os sintomas antes de encontrá-los às três da manhã:

• 403 logo depois de atribuir um papel. Atribuição de papel leva até cinco minutos para valer. Espere antes de investigar.
• 401 com identidade gerenciada aparentemente correta. Autenticação via Entra ID exige subdomínio customizado no recurso. Endpoint regional não serve.
• Erro de delegação de sub-rede ao excluir o ambiente. A ordem de exclusão importa: apague e purgue o recurso Foundry antes da rede virtual.
• Capability host que não aceita alteração. Ele não é atualizável. Mudou a configuração, o caminho é recriar o projeto.
• Agente hospedado que não puxa imagem do ACR privado. O suporte a ACR atrás de rede privada depende da data de criação do projeto: projetos criados depois de 25 de junho de 2026 suportam; anteriores exigem o ACR alcançável pelo endpoint público.
• Code Interpreter sem arquivo. Em configuração privada com BYO, ele só funciona em cenários sem upload e download; o contorno com container_id existe só via SDK, não pelo portal.

Boas práticas para produção

• Trate a topologia de rede como decisão de dia zero. Injeção de VNet para agente hospedado e delegação de sub-rede não são reversíveis por edição.
• Provisione as três zonas de DNS desde o começo, mesmo que o código de hoje use só um SDK.
• Vincule a zona à VNet e teste com nslookup de dentro da rede. Zona criada e não vinculada é o defeito mais comum e o de diagnóstico menos óbvio.
• Desligue a chave cedo, no ambiente de desenvolvimento, e conte com propagação de até horas antes de considerar o corte efetivo.
• Use o GUID do papel em automação, não o nome, enquanto a renomeação circula.
• Escolha Foundry Agent Consumer para quem só consome. É o menor privilégio disponível e quase ninguém usa.
• Escreva a lista de destinos de saída permitidos como artefato versionado. Se ninguém consegue produzir essa lista, o egresso não está sob controle.
• Confirme que não há inspeção de TLS no caminho do agente.
• Dimensione a sub-rede do agente por sessão concorrente, não por número de agentes: o padrão é um IP utilizável por sessão simultânea.
• Planeje o acesso administrativo antes de desligar o público. Com acesso público desabilitado, o portal e o playground exigem VPN, ExpressRoute ou jump box atrás do Bastion.

O que precisa estar de pé

Fundação — a autoridade sobre o caminho. A VNet existe com sub-redes dimensionadas e delegadas, as zonas de DNS estão vinculadas, o acesso público está desabilitado no recurso Foundry e nos três recursos dependentes, e cada um deles tem private endpoint próprio. Ninguém alcança nada pela internet, e o nome resolve para IP privado de dentro da rede.

Está de pé quando um nslookup a partir da VNet devolve endereço privado para todos os FQDNs, e o mesmo comando fora dela não abre conexão.

Produção com contexto — a identidade virando autorização. A chave está desligada, toda chamada carrega identidade do Entra ID, os papéis do Foundry estão atribuídos no escopo certo — projeto para quem constrói, agente para quem só consome — e a identidade gerenciada do projeto tem exatamente os papéis de dados que precisa em Storage, Cosmos DB e AI Search. Nenhuma credencial estática sobrevive em variável de ambiente.

Está de pé quando remover uma atribuição de papel derruba o acesso de alguém — prova de que o acesso vinha do papel, e não de uma chave esquecida.

Escala e eficiência — a plataforma como produto. O egresso é negado por padrão e liberado por lista explícita e versionada; a criação de ambiente novo é template, não roteiro manual; e a topologia suporta mais um projeto sem redesenho, com o consumo de IP da sub-rede acompanhado como capacidade.

Está de pé quando adicionar um destino externo novo exige alterar um arquivo revisado em pull request, e não abrir um chamado de firewall.

A ordem é causal, não cronológica. Não se distribui papel com sentido antes de haver caminho definido, e não se controla saída antes de saber quem está falando.

Perguntas frequentes (FAQ)

Private endpoint sozinho já protege minha carga de IA?

Não. Ele fecha o ingresso ao recurso. Não autentica ninguém — isso é Entra ID — e não controla para onde o agente escreve depois, o que exige controle de egresso em camada 7.

Por que três zonas de DNS para um recurso só?

Porque o recurso Foundry expõe três sufixos de endpoint — cognitiveservices.azure.com, openai.azure.com e services.ai.azure.com — e o SDK escolhido determina qual deles é usado. Configure todos os que o seu workload puder usar.

Posso adicionar isolamento de rede a um recurso Foundry que já existe?

Para agentes hospedados, não: a injeção de rede precisa entrar na criação da conta. Private endpoint de entrada pode ser adicionado depois, mas a injeção de VNet, não.

Qual o tamanho de sub-rede que eu preciso?

O mínimo aceito é /27 e o recomendado para produção é /24. Dimensione por sessões concorrentes, já que o padrão é um IP utilizável por sessão, e lembre que a sub-rede do agente não pode ser compartilhada entre recursos Foundry.

Desligar a chave de API quebra alguma coisa?

Quebra qualquer cliente que ainda autentique por chave — e não de imediato, porque a propagação pode levar horas. Migre os clientes para identidade gerenciada primeiro, confirme nos logs que não há mais chamada por chave e só então desligue.

NSG não basta para controlar a saída?

Não. NSG opera em camada 4 e decide porta e faixa de IP. Restringir por nome de destino exige firewall com regra de FQDN — no modo de saída aprovada ou com Azure Firewall na sua própria VNet.

Conclusão

A arquitetura segura de uma carga de IA não é um cadeado, são três: quem alcança, quem pode e para onde vai — mais a pergunta de onde o dado repousa. Private endpoint com DNS resolvido fecha a primeira. Entra ID com a chave desligada fecha a segunda. Egresso negado por padrão fecha a terceira, e é a que fica aberta na maioria dos projetos que já passaram por revisão de segurança. Recursos BYO respondem a quarta.

O sinal de maturidade é simples e desconfortável de verificar: peça a alguém a lista dos destinos externos que os seus agentes podem alcançar. Se a resposta for um documento versionado, a fronteira de saída existe. Se for “eles chamam o que precisarem”, o que existe é uma rede privada em volta de uma porta aberta.

👉 Se você está levando agentes para produção em ambiente regulado — especialmente em banco, seguradora ou saúde, onde a pergunta do auditor não é se o dado está criptografado, mas por onde ele pode sair, este é o ponto de partida.
Quer trocar ideia sobre isolamento de rede e identidade para cargas de IA? Me chama no LinkedIn.