O Agent 365 agora pode bloquear as ferramentas MCP que um agente chama. A política se torna real no gateway

Uma lista dos seus agentes não é um controle. Controle é conseguir impedir que um agente chame uma ferramenta numa quarta-feira à tarde, sem fazer um novo deploy do agente e sem pedir autorização ao time que o construiu. A maioria dos programas de governança de agentes hoje tem a lista.

Em 9 de outubro, a Microsoft juntou as duas metades. Um preview público conecta o Agent 365, o produto de governança de agentes dela, ao Azure API Management para o tráfego destinado a servidores e ferramentas MCP. A Microsoft descreve a divisão sem rodeios: “O Agent 365 define a intenção de governança, mantém o inventário e gerencia as decisões de acesso”, enquanto “o Azure API Management aplica essas decisões de forma inline para o tráfego destinado a servidores e ferramentas MCP”.

Essa frase descreve uma arquitetura que vale a pena copiar, seja qual for o fornecedor que você use.

Dois planos, dois donos

O time que decide o que os agentes podem fazer raramente é o time que opera esses agentes. Times de identidade e segurança definem a política de acesso; times de plataforma operam os gateways; times de produto constroem agentes no framework que for mais conveniente. Até agora, os produtos de governança de agentes ficavam quase sempre no primeiro lado: inventários, scores de risco, políticas escritas. A aplicação dependia da configuração de cada agente.

Aqui, a decisão e a aplicação ficam em sistemas diferentes, com donos diferentes, unidos por uma integração. Agentes já configurados para acessar ferramentas pelo gateway mantêm a conexão, os servidores MCP permanecem nas assinaturas do Azure do cliente, e a descoberta exige um consentimento único no nível do tenant. Um agente não precisa ser reconstruído no runtime da Microsoft para ser governado, desde que o tráfego de ferramentas dele passe pelo API Management.

Quem decide, quem aplica

Agent 365

• Inventário MCP
• Intenção de governança
• Decisões de acesso

Pertence à governança e à segurança

Azure API Management

• Aplicação inline em cada chamada de ferramenta

Pertence ao time de plataforma

Defender e Purview (tier AI Gateway)

• Avaliar requisições de ferramentas
• Avaliar resultados de ferramentas

Servidores e ferramentas MCP

• Nas assinaturas do Azure do cliente

Leia o tier antes da manchete

O que você consegue aplicar depende do tier do API Management que você usa. A Microsoft afirma que os tiers v2 suportam “inventário centralizado de MCP e bloqueio e desbloqueio no nível do servidor por meio do Agent 365”. O tier AI Gateway acrescenta “bloqueio de ferramentas individuais, observabilidade da atividade das ferramentas e proteção contra ameaças em ferramentas”, sendo que o próprio bloqueio de ferramentas individuais está rotulado como preview.

A diferença é maior do que parece. Bloquear um servidor inteiro é um disjuntor: útil em um incidente, grosseiro na operação do dia a dia. O privilégio mínimo exige o controle mais fino, em que um agente mantém as ferramentas de leitura em um servidor de CRM e perde a que atualiza registros. Esse controle está no tier AI Gateway.

A proteção contra ameaças funciona em duas direções. O Defender e o Purview avaliam requisições e resultados de ferramentas em busca de conteúdo malicioso, prompt injection e informações sensíveis. Com o bloqueio configurado, “a avaliação pré-invocação pode impedir a execução de uma chamada não permitida”, e “a avaliação pós-invocação pode reter resultados inseguros antes que cheguem ao agente”. A segunda direção merece atenção: a resposta de uma ferramenta é por onde instruções injetadas entram em um agente, e poucos times inspecionam isso hoje.

O anúncio não cobre licenciamento, preços, regiões nem limites numéricos. Consulte a documentação antes de planejar em cima disso e lembre-se de que tudo isso é preview.

O que o gateway não consegue ver

A aplicação inline governa o tráfego que passa inline. Um agente que tem a própria credencial para um servidor MCP, que chama uma ferramenta local ou que navega na web fica fora desse controle, e o dashboard não vai dizer isso. Como argumentamos quando a conectividade MCP ultrapassou a governança de MCP, o protocolo conecta; ele não governa.

O trabalho de design, portanto, é fazer do gateway a única rota:

• Credenciais que só funcionam pelo gateway. Se uma ferramenta aceita um token que o agente poderia usar diretamente, o gateway é opcional.
• Regras de egress para cargas de trabalho de agentes, para que um caminho direto até um servidor de ferramentas falhe na rede.
• Reconciliação do inventário com o tráfego. Agentes que aparecem no Agent 365 mas nunca enviam tráfego pelo API Management ou estão ociosos ou estão contornando o gateway. Os dois casos merecem uma pergunta.

Esse é o padrão que descrevemos para o AI gateway como ponto de aplicação de política, agora aplicado a ferramentas em vez de modelos. Ele também mantém separadas duas das seis autoridades que governam um agente: as pessoas que concedem acesso a ferramentas não são as pessoas que podem desligar a aplicação.

Três perguntas valem a pena antes de um piloto. Quais ferramentas dos nossos agentes podem ser bloqueadas individualmente hoje, e em qual tier? Que tráfego chega às ferramentas sem passar pelo gateway? E quando a segurança decide cortar o acesso de um agente a uma ferramenta, quantos minutos isso leva, e quem precisa concordar?