MCP e AGT: o fim da integração e o início da governança confiável de agentes de IA

O MCP nasceu para resolver um problema prático: como fazer agentes de IA descobrirem e usarem ferramentas externas sem reinventar a roda a cada integração. Ao padronizar esse caminho, ele acelerou a adoção de agentes em ambientes corporativos, facilitou a conexão com servidores de ferramentas e reduziu a fragmentação técnica. Mas uma lacuna permaneceu aberta — e ela ficou maior justamente quando os agentes passaram a tocar dados sensíveis, sistemas críticos e fluxos com impacto real: quem decide, de forma confiável, se uma chamada de ferramenta pode ou não acontecer?

É nessa lacuna que entra o Agent Governance Toolkit (AGT), apresentado pela Microsoft como uma camada de runtime para colocar política e controle entre clientes MCP e servidores de ferramentas. Em vez de confiar apenas na intenção do modelo, a proposta é inserir um ponto determinístico de governança antes da execução: escanear definições de ferramentas, aplicar políticas, inspecionar respostas, validar identidade criptográfica, registrar trilhas auditáveis e bloquear chamadas com base em privilégios.

Na prática, isso muda o centro de gravidade da segurança em agentes. O debate deixa de ser apenas “o prompt está bem escrito?” e passa a ser “o sistema de execução consegue autorizar, negar, auditar e conter cada tool call com base em regras verificáveis?”. Essa diferença é decisiva em cenários corporativos, onde o risco não está só na resposta do modelo, mas no que ele pode acionar no mundo externo.

O ponto mais importante aqui é estrutural. O MCP padroniza descoberta e execução de ferramentas, mas não define um plano de governança antes da chamada. Isso significa que, sem uma camada adicional, o agente pode até operar de forma elegante e interoperável, mas ainda assim agir com confiança excessiva em ambientes onde confiança automática é exatamente o que não se pode ter. Em especial quando entram em cena vetores como tool poisoning, supply chain comprometida, definição maliciosa de ferramentas e exposição indevida de recursos sensíveis.

O que o AGT propõe na prática

O AGT tenta transformar governança de agentes em algo operacional, e não apenas conceitual. A lógica é simples de entender, mas poderosa: toda chamada de ferramenta precisa passar por uma decisão intermediária antes de ser executada. Essa decisão pode permitir, negar ou exigir aprovação, com base em políticas declarativas e sinais de contexto.

Entre os recursos descritos estão:

• Varredura de definições de ferramentas, para identificar superfícies suspeitas antes do uso;
• Enforcement por política, com regras aplicadas no momento da chamada;
• Inspeção de respostas, para observar o que a ferramenta devolve;
• Identidade criptográfica, associando o agente a credenciais verificáveis;
• Logs auditáveis, com trilha de execução adequada para compliance;
• Bloqueio por privilégios, reduzindo o que cada agente pode acessar.

Do ponto de vista de arquitetura, a mudança é relevante porque desloca o controle de segurança do nível de prompt para um plano determinístico de execução. Isso reduz a dependência de instruções vagas e torna a autorização verificável. Em ambientes corporativos, essa é exatamente a classe de mecanismo que times de segurança e plataforma costumam pedir: controle explícito, observável e compatível com policy-as-code.

Por que isso importa agora

A Microsoft está respondendo a uma tensão que ficou cada vez mais evidente com a expansão dos agentes: a IA pode até raciocinar bem, mas o verdadeiro risco está no acesso que ela ganha quando conecta ferramentas reais. Um agente com acesso a banco de dados, sistemas internos, repositórios, APIs administrativas ou fluxos de aprovação deixa de ser apenas um gerador de texto. Ele passa a ser um executor de ações.

Isso eleva a exigência de segurança para outro patamar. Já não basta confiar que o modelo “vai obedecer ao sistema” ou que o prompt de segurança vai segurá-lo em situações adversas. Segundo o benchmark interno citado, a confiança apenas em instruções ao modelo mostrou insuficiência — e esse dado ajuda a sustentar o argumento de que governança de execução precisa existir fora do próprio modelo.

O debate, portanto, não é sobre adicionar mais um filtro. É sobre instituir uma camada de decisão capaz de responder perguntas concretas:

• Essa ferramenta pode ser chamada por este agente?
• Esse tipo de dado pode ser acessado agora?
• Essa ação está dentro do privilégio concedido?
• O servidor de ferramentas é confiável e íntegro?
• O output recebido está dentro do comportamento esperado?

Da política no papel à política no runtime

Um dos elementos mais interessantes da proposta é o alinhamento com policy-as-code. O toolkit suporta políticas declarativas em formatos como YAML, OPA/Rego ou Cedar, o que facilita a integração com stacks corporativas já acostumadas a controle programável. Essa escolha é estratégica porque move a governança para o mesmo território em que já vivem firewall rules, IAM policies, admission controls e regras de compliance automatizáveis.

Em vez de depender de revisão manual ou de lógica distribuída em múltiplos pontos, a organização pode centralizar decisões em um conjunto de regras verificáveis. Isso melhora consistência, reduz erro operacional e abre espaço para auditoria real. Para equipes de segurança, o valor é claro: dá para revisar, versionar, testar e aprovar a política que governa os agentes da mesma forma que se governa infraestrutura.

Há também um benefício organizacional importante. Quando a governança entra no runtime, ela deixa de ser uma recomendação e se torna uma barreira de execução. Isso reduz o risco de que times diferentes implementem controles inconsistentes para o mesmo tipo de agente ou ferramenta. Em empresas grandes, onde múltiplos times adotam MCP ao mesmo tempo, essa uniformização pode ser decisiva.

Identidade, privilégios e trilha de confiança

Outro ponto forte do AGT é a tentativa de ampliar a noção de identidade do agente. A proposta menciona integração com SPIFFE e uso de chaves criptográficas como Ed25519 e ML-DSA-65, além de trust score e privilege rings. Isso indica uma visão mais madura: o agente não é apenas um processo que faz chamadas; ele é uma entidade com identidade, nível de confiança e escopo limitado.

Essa abordagem conversa diretamente com ambientes corporativos modernos, que já usam segmentação por privilégios e modelos de confiança graduais. Ao conectar o agente a uma identidade verificável, a governança deixa de ser genérica e passa a ser contextual. Um agente de baixa confiança não deveria ter o mesmo acesso que um agente validado, e um agente em ambiente sensível não deveria operar sob o mesmo regime de permissões de um ambiente de teste.

Os logs auditáveis reforçam essa lógica. Em segurança, não basta bloquear ou permitir. É preciso conseguir responder depois: o que aconteceu, quem decidiu, com base em qual política, em que momento e com qual resultado. O uso de logs hash-chained aumenta a integridade dessa trilha e melhora a qualidade de auditoria, especialmente quando há exigências regulatórias ou investigações internas.

O que muda para o mercado

O anúncio também tem um efeito de mercado muito claro: a Microsoft está tentando posicionar governança de agentes como categoria de produto, e não como detalhe técnico ou ajuste de prompt. Isso é relevante porque, quando uma grande plataforma faz esse movimento, ela ajuda a definir o vocabulário do setor.

Ao tratar segurança para MCP como uma necessidade de plataforma, o lançamento sugere que o ciclo de adoção de agentes entrou em uma nova fase. Não basta conectar ferramentas. É preciso governar essa conexão. Em outras palavras, a pergunta já não é “como eu integro o agente?”, mas “como eu controlo o que ele pode executar de forma verificável?”.

O fato de o toolkit ser open source e vir com integrações com mais de 20 frameworks aumenta seu potencial de adoção transversal em ambientes multi-stack. Isso é especialmente importante em empresas que não querem prender a governança a um único fornecedor de orquestração, biblioteca ou runtime. Se a peça de controle funcionar como camada intermediária, ela pode servir como ponto de unificação entre diferentes implementações de agentes.

Há ainda um argumento forte para times de compliance e risco: a cobertura mapeada contra o OWASP MCP Top 10 cria uma narrativa de compra concreta. Em vez de vender apenas “segurança de IA”, a proposta se alinha a riscos nomeados e reconhecíveis, com linguagem que áreas técnicas e jurídicas conseguem discutir.

Onde a proposta ainda não fecha a conta

Apesar do avanço, o próprio desenho expõe limites importantes. O primeiro é que o AGT está em Public Preview, o que significa que recursos e APIs ainda podem mudar. Em um tema sensível como governança, estabilidade importa muito, porque a confiança da empresa depende justamente da previsibilidade do controle.

Outro limite é a cobertura parcial de três riscos do OWASP MCP Top 10: token mismanagement, intent flow subversion e shadow MCP servers. Em outras palavras, o toolkit avança bastante, mas não cobre tudo. E isso é normal em uma proposta inicial, mas relevante para decisões de adoção em produção.

Talvez a limitação mais importante seja esta: o AGT governa chamadas individuais, mas ainda não correlaciona sequências de ações que formam workflows maliciosos. Isso deixa espaço para ataques por composição. Uma ação isolada pode parecer legítima, mas uma sequência de ações permitidas pode, no conjunto, produzir um resultado indevido. Em segurança de agentes, esse é um ponto crítico: o perigo nem sempre está em uma única tool call, e sim no encadeamento delas.

Também vale observar que os números de cobertura e latência vêm da própria equipe. Isso não invalida os dados, mas exige leitura cuidadosa. Benchmark interno, por definição, não substitui validação independente. O mesmo vale para o exemplo de 60 prompts e a taxa de violação citada: é um indicativo importante, mas não uma prova universal.

O que essa mudança sinaliza para quem já usa MCP

Para empresas que já adotaram MCP, a mensagem é direta: a camada de integração de ferramentas já não basta sozinha. Se agentes estão conectados a sistemas reais, a organização precisa de um plano de controle entre a intenção do modelo e a execução efetiva da ação.

Na prática, isso pode significar uma nova disciplina interna para equipes de IA, segurança e plataforma:

• definir políticas por tipo de ferramenta, ambiente e sensibilidade de dados;
• mapear privilégios mínimos por agente;
• auditar chamadas em tempo real com trilha íntegra;
• validar identidade de agente e de servidor de ferramenta;
• monitorar respostas suspeitas e comportamento fora do padrão;
• revisar riscos de composição entre múltiplas chamadas permitidas.

Esse é o tipo de governança que coloca agentes de IA mais próximos de uma arquitetura corporativa séria. Sem isso, a promessa de automação pode virar apenas uma nova superfície de risco.

O paradigma que muda: de agente capaz para agente governado

A contribuição mais relevante do AGT talvez não esteja apenas nos controles específicos, mas na tese que ele consolida: o próximo passo dos agentes não é só aumentar capacidade, é aumentar governabilidade. O MCP resolveu a porta de entrada. O AGT tenta resolver a portaria.

Essa transição é importante porque indica maturidade do mercado. Ferramentas de IA deixam de ser protótipos empolgantes e passam a ser sistemas que exigem responsabilidade operacional. Quando isso acontece, identidade, política, auditoria e enforcement deixam de ser luxo e passam a ser requisito.

No fim, a discussão não é sobre um toolkit isolado. É sobre a direção da própria infraestrutura de agentes. Se o MCP tornou fácil conectar ferramentas, a nova fronteira é tornar essa conexão controlável, auditável e segura por padrão. E essa é uma mudança de paradigma que tende a influenciar não só a Microsoft, mas todo o ecossistema em torno de agentes de IA.

O recado é claro: confiar no modelo já não basta. Em ambientes reais, a confiança precisa ser construída no runtime, na política e na trilha de execução. É aí que a governança deixa de ser um complemento e passa a ser parte central da arquitetura.