Em dez dias, o Model Context Protocol deixou de ser assunto de desenvolvedor e virou infraestrutura corporativa. Três movimentos, em sequência:
- 06/07 — a extensão Enterprise-Managed Authorization (EMA) foi promovida a estável, com suporte de Anthropic, Microsoft e Okta. A empresa passa a aprovar centralmente, via identity provider, em quais servidores MCP seus usuários podem se conectar.
- 09/07 — a Citrix lançou o MCP Gateway no NetScaler: roteamento, autenticação, rate limit por ferramenta, allow/block list de servidores e observabilidade do tráfego de agentes.
- 28/07 — entra em vigor a spec MCP 2026-07-28, que torna o protocolo stateless: adeus sticky session e session store; o servidor roda atrás de um load balancer comum.
Steve Shah, da Citrix, resumiu o momento com uma frase que vale colar na parede do time de plataforma: "consultar sistemas de registro via MCP vai virar a nova chamada de API".
Os números acompanham a retórica: 78% dos times de IA enterprise já têm agentes com MCP em produção, 28% das Fortune 500 rodam servidores MCP, e os SDKs somam cerca de 97 milhões de downloads mensais.
Aqui está o problema. A leitura fácil dessas três notícias é: "ótimo, a governança de agentes foi resolvida". Não foi. O próprio time do MCP avisa, na documentação da extensão, que EMA não é autorização em runtime. Ela decide se um usuário pode conectar em determinado servidor. Ela não decide o que o agente pode fazer depois que entrou.
A porta ganhou fechadura. O que acontece dentro da casa continua sendo problema seu.
1. O que é MCP — e por que ele virou "a nova chamada de API"
O Model Context Protocol é um protocolo aberto que padroniza como um modelo de linguagem descobre e invoca ferramentas, recursos e dados externos. Antes dele, cada integração agente↔sistema era um adaptador artesanal. Com ele, um servidor MCP expõe capacidades de forma declarada, e qualquer cliente compatível consegue usá-las.
A analogia com API não é retórica — é estrutural. Nos anos 2010, a API REST virou a superfície padrão pela qual sistemas conversavam entre si. O MCP está virando a superfície padrão pela qual agentes conversam com sistemas. E isso muda a natureza do consumidor: uma API REST é chamada por código que alguém escreveu, revisou e versionou. Um servidor MCP é chamado por um agente que decide sozinho, em runtime, qual ferramenta invocar e com quais argumentos.
Essa diferença é a origem de todos os problemas de governança que vêm a seguir.
2. As três mudanças de julho de 2026
06/07 — EMA vira estável
Antes do EMA, cada servidor MCP negociava seu próprio consentimento com o usuário. O resultado era o que se poderia chamar de inferno de OAuth: dezenas de telas de "autorizar acesso", nenhuma visão central, nenhuma capacidade de revogar em massa.
Com o EMA, a empresa pluga o MCP no seu identity provider (o fluxo é baseado em ID-JAG, identity assertion authorization grant). O IdP passa a ser a autoridade: ele diz quais servidores MCP são aprovados, quem pode conectar em cada um, e emite os tokens. Login único, revogação central, inventário de servidores aprovados. É uma melhoria real e substancial.
09/07 — Citrix MCP Gateway
Um gateway dedicado ao tráfego de agentes, entregue como funcionalidade do NetScaler. O que ele traz: roteamento centralizado (todo tráfego MCP passa por um ponto), allow/block list de servidores, rate limit por ferramenta (não só por endpoint) e observabilidade — logs do que está sendo invocado, por quem, com que frequência.
Ele importa menos pelo produto e mais pelo sinal: quando um fornecedor de infraestrutura de rede lança um gateway para um protocolo, esse protocolo passou a ser tratado como tráfego de produção.
28/07 — a spec fica stateless
A versão 2026-07-28 do MCP remove a exigência de sessão persistente. Na prática: o servidor MCP deixa de precisar de sticky session, session store distribuído ou afinidade de conexão. Ele roda atrás de um load balancer comum, escala horizontalmente como qualquer serviço HTTP e sobrevive a restart de pod sem perder contexto.
É a mudança menos glamourosa das três e provavelmente a mais importante para operação: ela transforma servidor MCP em workload normal.
3. O que o EMA resolve — e o que ele explicitamente não resolve
Vale ser cirúrgico aqui, porque a confusão entre essas duas camadas é o que vai gerar incidente.
| Camada | Pergunta que responde | Resolvido por EMA? |
|---|---|---|
| Conexão | Este usuário pode se conectar a este servidor MCP? | ✅ Sim |
| Ação (runtime) | Este agente pode invocar esta ferramenta com estes argumentos, neste momento? | ❌ Não |
Um exemplo torna a diferença concreta. Suponha um servidor MCP que expõe o seu ERP. O EMA garante que só funcionários do time financeiro consigam conectar nele. Ótimo. Mas depois de conectado, o agente do time financeiro tem acesso a todas as ferramentas que aquele servidor expõe — inclusive, digamos, cancelar_pedido ou atualizar_preco. Nada no EMA distingue "ler saldo" de "estornar lançamento". Essa distinção é autorização em runtime, e ela vive na sua camada de aplicação — ou não vive em lugar nenhum.
Vale lembrar por que isso é mais grave com agentes do que com código tradicional: o agente escolhe a ferramenta. Um bug de prompt, um dado envenenado no contexto ou uma instrução ambígua podem levá-lo a invocar algo que ninguém previu. Com API REST, o caminho de execução foi escrito por um humano e passou por code review. Com MCP, o caminho de execução é decidido em tempo de inferência.
4. Os cinco buracos de governança que sobram
- Proliferação de servidores. Quantos servidores MCP existem hoje na sua empresa? Quem os subiu? Estão em qual ambiente? A resposta honesta, na maioria das organizações, é "não sei" — e servidores MCP são triviais de subir, o que é exatamente o problema.
- Escopo por ação, não por servidor. Conectar ao servidor do ERP não deveria ser a mesma coisa que poder escrever nele. Cada ferramenta exposta precisa do seu próprio escopo, amarrado à identidade de quem — ou do quê — está chamando.
- Rate limit por ferramenta. Um agente em loop pode invocar a mesma ferramenta milhares de vezes em segundos. Rate limit por IP ou por token não protege: o problema não é volume de rede, é volume de efeito colateral.
- Dado sensível no contexto. Tudo o que o servidor MCP devolve entra no contexto do modelo. Um retorno generoso demais coloca CPF, cartão ou dado de saúde dentro de uma janela de contexto que pode ser logada, cacheada ou enviada a um provedor terceiro. Minimização de dado na resposta da ferramenta deixa de ser boa prática e vira requisito de LGPD.
- Trilha de auditoria por ação. A pergunta que a auditoria vai fazer não é "qual usuário conectou no servidor". É "qual agente alterou este pedido, às 3h07, e com base em qual instrução". Se você não consegue responder isso, você não tem trilha — tem log de acesso.
O contexto que dá peso a essa lista: o Gartner mediu que 60% das provas de conceito de IA generativa foram abandonadas em 2024, com projeção de queda para 35% até 2029. Governança e dado não-pronto lideram a lista de motivos. Escalar agentes sem resolver as cinco perguntas acima não é ousadia — é escolher entrar nessa estatística.
5. A camada que fecha a conta
O desenho que funciona não é exótico. É a arquitetura de integração enterprise de sempre, aplicada a um novo tipo de consumidor:
- Gateway na frente. Todo tráfego de agente passa por um ponto controlado. Allow list de servidores, rate limit por ferramenta, quota por agente, kill switch.
- Identidade do agente, não só do usuário. O agente precisa ser um principal de primeira classe — com credencial própria, escopo próprio e ciclo de vida próprio. "O agente age em nome do João" é insuficiente quando o agente age sozinho às 3h da manhã.
- API-led connectivity. O servidor MCP não deve falar direto com o banco do ERP. Ele consome APIs de sistema já governadas, versionadas e com contrato — que é exatamente o que uma camada API-led (no espírito do MuleSoft e semelhantes) entrega.
- Eventos para o que é assíncrono e crítico. Escrita em sistema de registro passa por fila (Kafka ou RabbitMQ), com chave de idempotência e dead-letter queue. Assim, um agente que repete a chamada por timeout não duplica o lançamento.
- Auditoria imutável por ação. Quem (qual agente), o quê (qual ferramenta), com quais argumentos, quando, e qual foi o resultado. Append-only. É isso que a auditoria e a ANPD vão pedir.
Repare que nada disso depende de qual LLM você usa, nem de qual provedor de MCP. A camada é neutra por construção — e é justamente por isso que ela sobrevive à próxima troca de modelo.
6. Como a CCX ajuda: exposição governada de sistemas
Essa é literalmente a prática de Integrações & APIs Enterprise da CCX: conectividade entre sistemas via REST, GraphQL e gRPC, com arquitetura event-driven em Kafka e RabbitMQ, cobrindo ERPs (SAP, Protheus, Bling, Tiny), CRMs, gateways de pagamento e antifraude. É a mesma camada que um agente MCP precisa consumir — construída com contrato, idempotência e observabilidade desde o primeiro dia.
Do lado do controle, a prática de Security Engineering & Cybersecurity traz o que falta ao EMA: identity management, OAuth2, Vault, SIEM, WAF e security by design em cada camada — além de pentest para validar que o escopo que você acha que configurou é o escopo que existe de fato. E a prática de Observabilidade 360° (Datadog, Grafana, Prometheus, OpenTelemetry) fecha o ciclo com tracing distribuído: quando um agente altera um pedido, dá para reconstruir o caminho inteiro.
Não é sobre "adotar MCP". É sobre tratar o agente como o que ele é: um novo cliente da sua camada de integração — o mais imprevisível que você já teve.
Implementar IA no meu negócio → — ou conheça a prática de integrações enterprise API-led e o portfólio de soluções CCX.
7. Perguntas frequentes
O que é Enterprise-Managed Authorization (EMA) no MCP?
É a extensão do MCP, estável desde 06/07/2026, que permite à empresa aprovar centralmente — via identity provider, no fluxo ID-JAG — em quais servidores MCP seus usuários podem se conectar. Elimina o consentimento servidor a servidor e permite revogação central.
EMA resolve a segurança dos meus agentes?
Não. O próprio time do MCP é explícito: EMA não é autorização em runtime. Ela governa a conexão (quem pode plugar), não a ação (o que o agente pode fazer depois de conectado). Escopo por ferramenta, rate limit por ação e auditoria por ação continuam sendo responsabilidade da sua arquitetura.
O que muda com o MCP stateless (spec 2026-07-28)?
O servidor deixa de exigir sessão persistente. Ele passa a rodar atrás de um load balancer comum, escalar horizontalmente e sobreviver a restart sem session store. Operacionalmente, transforma servidor MCP em um workload HTTP normal.
Preciso de um MCP Gateway?
Se você tem mais de um servidor MCP em produção, precisa de alguma forma de gateway — seja o produto da Citrix, um API gateway existente adaptado, ou um serviço próprio. O que não é opcional é o ponto único de controle: allow list, rate limit por ferramenta e log centralizado.
Qual o maior risco de escalar agentes sem essa camada?
Ação não autorizada em sistema de registro sem trilha que permita reconstruir o que aconteceu. Em segundo lugar, exposição de dado sensível via retorno de ferramenta para dentro do contexto do modelo — que é um problema de LGPD, não só de arquitetura.