Governança MCP Empresarial: Como Controlar, Auditar e Proteger o Acesso a Servidores MCP em Escala

Pergunte à sua equipe de segurança quantos servidores MCP estão em execução em sua organização agora mesmo. Se eles puderem responder com confiança, você está à frente da maioria das empresas. Se não puderem, você tem um problema de governança que já está em produção.

A adoção de MCP avançou rapidamente. As equipes conectaram agentes a GitHub, Slack, bancos de dados internos e APIs de terceiros através de servidores MCP, muitas vezes sem revisão de TI, sem uma política de credenciais e sem qualquer forma de a equipe de segurança ver o que esses servidores podiam acessar. O protocolo é útil precisamente porque facilita as conexões de ferramentas. Essa facilidade é também o que torna as implantações de MCP não governadas uma verdadeira exposição de segurança.

Servidores MCP não são APIs passivas. Eles dão aos agentes de IA acesso direto e programático a sistemas sensíveis. Esses agentes atuam com base em raciocínio autônomo, não em caminhos de código revisados. Como um líder de segurança corporativa da Medtronic afirmou: "MCP abre muitas oportunidades para causar muitos danos muito rapidamente." A Gartner projeta que 70% das equipes de engenharia de software que constroem aplicações multimodais usarão gateways de IA até 2028, um aumento de 25% em 2025. As equipes que estão construindo a governança agora são as que conseguirão escalar com segurança.

Este guia aborda o que a governança de MCP corporativa exige, por que as ferramentas de segurança padrão são insuficientes, como construir a estrutura de quatro pilares na qual as equipes de conformidade podem confiar, e como a TrueFoundry implementa tudo isso dentro da sua própria nuvem.

O Que a Governança de MCP Corporativa Exige

A governança de MCP corporativa é a estrutura operacional completa para gerenciar quais servidores MCP existem em sua organização, quem pode acessá-los, o que eles têm permissão para fazer e o que é registrado quando são usados. Não é um documento de política. É uma infraestrutura aplicada.

A maioria das equipes subestima o escopo. A governança abrange todos os servidores MCP no ambiente: ferramentas de terceiros que os desenvolvedores conectaram sem revisão de TI, ferramentas internas que as equipes de produto construíram e implantaram, e servidores MCP incorporados em configurações de IDE em Cursor, Claude Code e ferramentas semelhantes. Se um servidor MCP pode alcançar um sistema de produção, ele está dentro do escopo.

A governança de MCP também é diferente da governança de API padrão de uma forma que importa para como você a constrói. Uma chamada de API REST executa um caminho de código determinístico que um desenvolvedor escreveu e revisou. Uma invocação de ferramenta MCP é uma decisão autônoma tomada por um agente de IA em tempo de execução com base em seu raciocínio. O modelo de ameaça, os requisitos de auditoria e os controles necessários para manter a responsabilidade são todos diferentes. Tratar o MCP como uma integração de API convencional é como as organizações acabam com lacunas de auditoria que não conseguem explicar a um regulador.

• Escopo: Todos os servidores MCP. Isso inclui servidores internos construídos por equipes de produto, servidores em execução em pipelines de CI/CD, e qualquer coisa que um desenvolvedor configurou localmente em sua IDE.

• Mecanismo: Um gateway centralizado entre todos os clientes e todos os servidores MCP. O gateway aplica as políticas. Servidores MCP individuais não implementam seus próprios controles de acesso, o que torna essa abordagem escalável para centenas de servidores.

• Resultado: Cada invocação de ferramenta é autorizada contra uma identidade verificada e registrada em um formato estruturado e consultável que resiste à revisão de conformidade e à investigação de incidentes.

Riscos de Segurança de MCP Que as Empresas Não Podem Ignorar

Servidores MCP operam dentro do ciclo de raciocínio de um agente de IA. Uma chamada de API tradicional é acionada deterministicamente pelo código da aplicação. Uma invocação de ferramenta MCP, por outro lado, é acionada quando um agente determina em tempo de execução que uma ferramenta é apropriada para uma determinada tarefa. Essa decisão é influenciada pelo raciocínio do modelo, em vez de um fluxo de controle explicitamente definido, o que reduz a visibilidade que os desenvolvedores geralmente têm sobre como e por que uma ferramenta é invocada. Nesse modelo, o raciocínio efetivamente se torna parte do caminho de controle, mas não é diretamente observável através das ferramentas de segurança de aplicações padrão.

Pesquisadores de segurança documentaram isso em produção. Ataques de injeção de prompt entregues através de descrições de ferramentas MCP redirecionam o comportamento do agente sem tocar em uma linha de código. A exposição de credenciais através de servidores MCP mal configurados cria caminhos de acesso que os controles de perímetro nunca foram projetados para monitorar. Estes não são cenários de ataque teóricos de artigos de pesquisa. São incidentes documentados de implantações corporativas reais.

Implantações de Servidores MCP Sombra Podem Contornar o Controle de Acesso Padrão

Quando os desenvolvedores implementam ou se conectam a servidores MCP sem revisão de TI, eles ignoram todos os controles que normalmente se aplicam a uma nova integração de sistema: avaliação de segurança do fornecedor, classificação de acesso a dados e fluxos de trabalho de provisionamento de acesso. O servidor entra em produção sem nenhuma da documentação, monitoramento ou restrições que todos os outros sistemas corporativos possuem.

Sem um registro central, perguntas básicas de segurança não têm respostas confiáveis. Quais servidores MCP estão em execução? Quais credenciais eles possuem? Quais bancos de dados eles podem consultar? Quais serviços externos eles podem chamar? Essa invisibilidade mantém esses servidores completamente fora do escopo de avaliações de vulnerabilidade, revisões de risco de fornecedores e testes de penetração.

Um único servidor MCP não aprovado com acesso de leitura a um CRM interno ou repositório de código é um caminho de dados não auditado que os controles de perímetro não detectarão. O tráfego se origina de dentro da rede, de uma máquina de desenvolvedor que deveria estar lá.

Envenenamento de Descrição de Ferramentas Contorna Defesas da Camada de Rede

Quando um agente se conecta a um servidor MCP e chama tools/list, o servidor responde com nomes de ferramentas, descrições e esquemas de parâmetros. O agente usa esses metadados para decidir quais ferramentas invocar e como chamá-las. Manipule esses metadados e você redireciona o comportamento do agente sem explorar nenhuma vulnerabilidade de código.

O envenenamento de descrição de ferramentas incorpora instruções maliciosas dentro dos metadados da ferramenta que fazem o agente realizar ações não intencionais: exfiltrar dados, invocar ferramentas fora de seu escopo pretendido ou contornar verificações de segurança enquanto parece executar sua tarefa atribuída. O conteúdo malicioso viaja dentro do corpo da resposta HTTP do servidor MCP, especificamente dentro do payload tools/list. Firewalls de aplicativos web padrão e ferramentas de segurança de API têm visibilidade dos corpos de resposta HTTP, mas não conseguem detectar este ataque porque o conteúdo malicioso é linguagem natural semanticamente incorporada, não uma anomalia sintática como uma assinatura de exploit conhecida ou um cabeçalho malformado. O ataque é bem-sucedido na camada de raciocínio, onde o agente interpreta as descrições das ferramentas como instruções legítimas e age de acordo.

Os guardrails MCP Pre Tool da TrueFoundry inspecionam os parâmetros da ferramenta e os argumentos de chamada antes da execução usando detecção de Injeção de Prompt baseada em modelo. Se os argumentos de chamada da ferramenta contiverem instruções redirecionadas, a execução é bloqueada antes que a ferramenta seja executada e a detecção é registrada no rastreamento da solicitação.

Credenciais Compartilhadas de Servidor MCP Eliminam a Responsabilidade de Conformidade

Servidores MCP que usam chaves de API compartilhadas ou tokens de conta de serviço não podem produzir os registros de auditoria atribuíveis que as estruturas de conformidade exigem. Se dez agentes compartilham um conjunto de credenciais, não há como vincular uma chamada de ferramenta específica a um usuário, instância de agente ou equipe específica. Em um ambiente regulamentado, essa lacuna não é um inconveniente. É uma falha direta de conformidade.

A HIPAA exige trilhas de auditoria atribuíveis a um usuário ou serviço identificável para cada acesso a informações de saúde protegidas. O SOC2 CC6 exige controles de acesso com evidências de aplicação. O princípio de responsabilidade do GDPR exige que as organizações demonstrem que o processamento de dados foi autorizado e documentado. Implantações de MCP com credenciais compartilhadas não podem satisfazer nenhuma dessas exigências. A TrueFoundry substitui credenciais compartilhadas por Tokens de Acesso Pessoal (PATs) vinculados a usuários individuais e Tokens de Conta Virtual (VATs) para acesso em nível de aplicativo, de modo que cada chamada de ferramenta carrega uma identidade verificável.

Os Quatro Pilares da Governança de MCP Corporativa

Uma estrutura completa de governança de MCP corporativa exige quatro capacidades que funcionam em conjunto: um catálogo centralizado, controles de acesso baseados em identidade, registro de auditoria estruturado e aplicação de políticas em tempo real. Cada um depende dos outros. Você não pode aplicar políticas de acesso antes de saber quais servidores existem. Você não pode construir uma trilha de auditoria sem atribuição de identidade. E logs de auditoria post-hoc sem aplicação em tempo real são registros forenses, não controles de segurança.

Quatro Pilares: Função Principal, Implementação TrueFoundry e Cobertura de Conformidade

Pilar 1: Um Catálogo Centralizado de Servidores MCP

O catálogo é o registro autoritário de cada servidor MCP aprovado em sua organização. Cada entrada contém as informações que as equipes de segurança da informação precisam para avaliar o risco: nome do servidor, equipe proprietária, escopo de acesso a dados, método de autenticação, status de aprovação, parâmetros de conexão e quaisquer restrições de uso, como grupos de usuários aprovados ou limites de taxa.

Novos servidores entram por meio de um fluxo de trabalho de verificação. A revisão da descrição da ferramenta verifica riscos de envenenamento antes que o servidor chegue aos ambientes de desenvolvedor. A avaliação de acesso a dados determina o que o servidor pode acessar. Uma aprovação explícita libera a distribuição. Nada disso exige alterações no próprio servidor MCP. Isso acontece na camada do catálogo, e as implementações individuais dos servidores permanecem intocadas.

O catálogo também gerencia a distribuição. Os desenvolvedores puxam configurações de servidor pré-aprovadas diretamente para suas integrações de IDE, em vez de configurar servidores manualmente. Apenas servidores aprovados pelo catálogo chegam às máquinas dos desenvolvedores. O recurso de Servidor MCP Virtual da TrueFoundry estende isso: equipes de plataforma compõem subconjuntos de ferramentas selecionados a partir de vários servidores registrados, expondo apenas o que uma equipe ou caso de uso específico exige, sem implantar nova infraestrutura.

Pilar 2: SSO e Controle de Acesso a Servidores MCP na Camada de Gateway

O acesso MCP precisa passar pelo mesmo provedor de identidade que governa todo o resto na organização. A TrueFoundry suporta fluxos OAuth2 de duas e três pernas, SAML 2.0 e integração direta com Okta, Azure Active Directory, Auth0, Cognito e qualquer IdP compatível com JWKS. O acesso MCP é provisionado e desprovisionado através dos mesmos fluxos de trabalho de integração e desligamento que cobrem e-mail, repositórios e consoles de nuvem. Quando um desenvolvedor sai, o acesso MCP é automaticamente revogado.

O gateway suporta três métodos de autenticação de entrada, dependendo de quem está chamando. Tokens de Acesso Pessoal (PATs) são gerados em Configurações > Chaves de API na UI da TrueFoundry, vinculados a usuários individuais, e são a escolha padrão para fluxos de trabalho de desenvolvimento. Tokens de Conta Virtual (VATs) são contas de serviço com permissões definidas, apropriadas para agentes de produção e fluxos de trabalho de servidor para servidor. Tokens de IdP externos permitem que usuários sem contas TrueFoundry se autentiquem usando seu próprio provedor de identidade, cobrindo SaaS B2B e implantações de agentes voltados para o cliente.

Para autenticação de saída para servidores MCP a jusante, o TrueFoundry gerencia o ciclo de vida completo das credenciais em seis padrões. Os fluxos de Código de Autorização OAuth lidam com o acesso por usuário a serviços como GitHub e Slack, com o gateway gerenciando o consentimento, o armazenamento de tokens e a atualização automática. Os fluxos de Credenciais de Cliente OAuth lidam com o acesso de servidor para servidor. Os modos de chave de API compartilhada e individual cobrem casos mais simples onde o gateway injeta a credencial correta por solicitação. O Passthrough de Token encaminha o token de entrada inalterado quando o servidor MCP pode validá-lo diretamente. O Encaminhamento de Token via cabeçalho x-tfy-mcp-headers lida com cenários onde o servidor MCP usa um sistema de credenciais separado.

Controle de Acesso ao Servidor MCP: Padrões de Autenticação em Cenários Empresariais Comuns

As políticas RBAC determinam quais equipes ou indivíduos podem invocar quais servidores e ferramentas. Essas políticas residem no gateway, e não em servidores MCP individuais, de modo que uma atualização de política entra em vigor em todos os clientes imediatamente, sem a necessidade de reimplantar o servidor. Uma equipe de ciência de dados obtém acesso a ferramentas de análise, mas não a servidores de implantação. Uma equipe de segurança obtém acesso somente leitura a todos os servidores para fins de auditoria.

Pilar 3: Registro de Auditoria Estruturado Vinculado a Cada Chamada de Ferramenta

Cada chamada de ferramenta MCP precisa de uma entrada de log que capture o contexto completo da invocação: carimbo de data/hora, identidade do chamador, identificador do servidor MCP, nome da ferramenta, parâmetros de entrada, resumo da resposta, decisão da política com justificativa, resultados do guardrail por hook mostrando tempo de execução e descobertas, e latência total. Esses campos precisam ser JSON estruturado para que sistemas SIEM e ferramentas de relatórios de conformidade possam consultá-los.

O TrueFoundry controla o registro em dois níveis. No nível da solicitação, o cabeçalho X-TFY-LOGGING-CONFIG com enabled: true captura a solicitação completa. No nível do gateway em implantações auto-hospedadas, a variável de ambiente REQUEST_LOGGING_MODE define o comportamento global: ALWAYS registra cada solicitação independentemente dos cabeçalhos, o que é a configuração correta para ambientes de produção regulamentados. HEADER_CONTROLLED delega às configurações por solicitação. NEVER suprime todo o registro para ambientes onde isso é apropriado.

Os logs de solicitação são visíveis na UI do TrueFoundry em AI Gateway > Monitor > Requests. Os spans de execução de guardrail individuais aparecem em AI Gateway > Monitor > Request Traces, mostrando quais guardrails foram executados em qual hook, status de aprovação/reprovação, tempo de execução e mutações aplicadas. Para organizações que roteiam logs para sua própria infraestrutura, o TrueFoundry exporta via OpenTelemetry para Grafana, Datadog, Splunk e qualquer destino compatível com OTLP. Em implantações auto-hospedadas, os dados de log são gravados em seu próprio armazenamento AWS S3, GCS ou Azure Blob no formato Parquet, consultável via Spark, DuckDB ou Athena.

A HIPAA exige a retenção de documentação relacionada à segurança por seis anos. Na prática, os logs de auditoria são frequentemente retidos por uma duração semelhante para apoiar a conformidade e a investigação de incidentes. Muitos registros financeiros seguem um padrão de retenção de sete anos. Os logs devem ser à prova de adulteração, com controles de acesso que impeçam a modificação pelas equipes que os geram. As opções de implantação auto-hospedada do TrueFoundry mantêm todos os dados de log dentro da conta de nuvem do cliente, suportando os requisitos de retenção e de prova de adulteração.

Pilar 4: Aplicação de Políticas MCP em Tempo Real Antes da Execução da Ferramenta

Registrar o que aconteceu não é o mesmo que prevenir. A aplicação da política precisa agir no momento da invocação, antes que a chamada da ferramenta chegue ao servidor MCP, para que o acesso não autorizado seja bloqueado em vez de documentado após o fato.

O sistema de guardrails do TrueFoundry implementa dois hooks por chamada de ferramenta. Os guardrails MCP Pré-Ferramenta são executados antes da execução da ferramenta. Se algum deles falhar, a ferramenta nunca é executada, evitando completamente o custo, os efeitos colaterais e a exposição de dados de uma chamada inadequada. Os guardrails pré-ferramenta integrados incluem: SQL Sanitizer, que detecta DROP, TRUNCATE, DELETE e UPDATE sem WHERE, e padrões de interpolação de string que indicam risco de injeção; detecção de Injeção de Prompt usando análise baseada em modelo para tentativas de jailbreak e injeção em parâmetros de chamada de ferramenta; Detecção de Segredos, que captura chaves de API, credenciais AWS, tokens JWT e chaves privadas antes que cheguem aos serviços de backend; e guardrails de política Cedar e OPA para controle de acesso declarativo e granular até argumentos específicos da ferramenta.

Os guardrails MCP Pós-Ferramenta são executados após o retorno da ferramenta, antes que o resultado chegue ao agente. Os guardrails pós-ferramenta integrados incluem Code Safety Linter, que sinaliza eval, exec, os.system, chamadas de subprocesso e comandos de shell perigosos na saída da ferramenta; Detecção de PII, que encontra e redige informações pessoais com categorias de entidade configuráveis; e Correspondência de Padrões Regex para padrões personalizados que cobrem cartões de pagamento, identificadores internos e dados sensíveis específicos do domínio. Provedores externos, incluindo AWS Bedrock Guardrail, Azure Content Safety, Azure Prompt Shield, CrowdStrike e Google Model Armor, todos se integram através do mesmo sistema de hooks.

As estratégias de aplicação são configuráveis por guardrail. Enforce bloqueia em caso de violação e em caso de erro do guardrail. Enforce But Ignore On Error bloqueia em caso de violação, mas permite que as solicitações passem se o provedor do guardrail estiver indisponível, o que é o padrão recomendado para produção. Audit registra violações sem bloquear, o modo correto durante a implantação inicial. A sequência recomendada é Audit primeiro, depois Enforce But Ignore On Error, e então Enforce completo à medida que a confiança aumenta.

Implantando um Gateway MCP Empresarial: Um Plano de Implementação em Quatro Etapas

A governança MCP é um programa sequenciado. Cada etapa se baseia na anterior. Você não pode aplicar políticas de acesso antes de saber quais servidores existem. Você não pode construir um rastro de auditoria significativo antes que a atribuição de identidade esteja em vigor.

Etapa 1: Inventariar Todas as Implantações MCP Existentes

Comece com uma auditoria completa de cada servidor MCP em execução em ambientes de desenvolvimento, pipelines de CI/CD, implantações de agentes de produção e configurações de IDE. Isso inclui servidores que os desenvolvedores configuraram localmente no Cursor ou Claude Code sem envolvimento da TI. A combinação de varredura automatizada de ambientes de nuvem com um processo de auto-relato para configurações de desenvolvedores locais oferece a imagem mais completa para grandes organizações.

Registre para cada servidor: nome e finalidade, equipe proprietária, escopo de acesso a dados, método de autenticação (se houver) e há quanto tempo está em execução. O objetivo é ter uma imagem precisa do que existe antes da implementação da governança, e não uma lista selecionada de itens já aprovados.

Etapa 2: Construir o Catálogo de Servidores MCP Aprovados

Antes de migrar qualquer servidor, defina o esquema de metadados e o fluxo de trabalho de aprovação. Decisões-chave: quem tem autoridade de aprovação para diferentes níveis de risco, o que a lista de verificação de revisão abrange e quais descobertas bloqueiam o registro no catálogo. Estabeleça esses critérios antes de categorizar os servidores para que sejam aplicados de forma consistente.

Analise o inventário e categorize cada servidor como aprovado para catálogo, pendente de revisão ou bloqueado aguardando remediação. Defina uma data limite até a qual todos os servidores de produção devem estar registrados no catálogo e comunique claramente que os servidores não catalogados serão bloqueados no gateway após essa data. O prazo cria a urgência que leva as equipes a se engajarem.

Passo 3: Implante o Gateway MCP e Aplique o SSO

Encaminhe todo o tráfego MCP através do gateway antes de aplicar as políticas de bloqueio. Comece com REQUEST_LOGGING_MODE definido como ALWAYS. Todo o tráfego passa, todas as invocações são registradas, nada é bloqueado ainda. Executar neste modo por duas a quatro semanas fornece uma linha de base dos padrões de tráfego reais antes que a aplicação comece.

Integre o gateway com seu IdP corporativo através de Acesso > Autenticação Externa > Provedor de Identidade na UI do TrueFoundry. Para Okta usando o servidor de autorização padrão, o URI JWKS é https://your-org.okta.com/oauth2/v1/keys. Organizações que usam um servidor de autorização Okta personalizado devem usar https://your-org.okta.com/oauth2/{authServerId}/v1/keys em vez disso. Para Azure AD, é https://login.microsoftonline.com/your-tenant-id/discovery/v2.0/keys, com ID de locatário e ID de cliente configurados como emissor e público. Verifique se cada invocação no log de auditoria mostra uma identidade de usuário ou agente específica antes de passar para a aplicação. Identidades de contas de serviço compartilhadas nos logs significam que a atribuição de identidade está incompleta.

Passo 4: Habilite a Aplicação e Configure Alertas

Após o período de linha de base, habilite a aplicação de políticas: bloqueie servidores MCP não catalogados, ative políticas RBAC e aplique limites de taxa. Comunique a data de aplicação às equipes de desenvolvimento com tempo suficiente para agilizar o registro de ferramentas legítimas no catálogo.

Configure alertas nos dados exportados do OpenTelemetry para padrões anômalos: volumes de chamadas incomuns de uma única identidade de agente, acesso a ferramentas de alta sensibilidade fora do horário aprovado, violações de política de identidades que não deveriam ter acesso MCP. Os resultados do guardrail em AI Gateway > Monitor > Request Traces fornecem os detalhes necessários para ajustar os limites ao longo do tempo. Revise as regras de alerta trimestralmente à medida que sua implantação MCP cresce.

Requisitos de Segurança Empresarial MCP por Indústria

Três requisitos aparecem consistentemente em todos os ambientes regulamentados: registros de acesso atribuíveis vinculados a identidades verificadas, controles de residência de dados mantendo dados sensíveis dentro de limites definidos e documentação de risco de fornecedor para a própria infraestrutura de governança.

• Saúde (HIPAA): Qualquer servidor MCP que possa receber informações de saúde protegidas em parâmetros ou respostas requer um gateway isolado por VPC. Invocações de ferramentas envolvendo PHI precisam de logs com identificadores de pacientes substituídos por tokens de referência, e o acesso deve ser provisionado através de gerenciamento de identidade clínica. A implantação auto-hospedada da TrueFoundry no AWS GovCloud suporta cargas de trabalho alinhadas com HIPAA. A Innovaccer processa aproximadamente 17 milhões de solicitações de inferência de IA clínica por mês inteiramente dentro de seu limite AWS GovCloud usando TrueFoundry, com OpenTelemetry alimentando painéis Grafana e sem dados sensíveis saindo de seu perímetro de nuvem.

• Serviços Financeiros (SOC2, FINRA): A infraestrutura de governança MCP está no escopo das auditorias SOC2 Tipo II se ela lida com dados financeiros ou tem acesso a sistemas de registro. Os controles exigidos incluem criptografia em trânsito e em repouso, revisões de acesso trimestrais com evidências documentadas e procedimentos de resposta a incidentes cobrindo modos de falha específicos do MCP. A TrueFoundry possui certificação SOC2 Tipo II e exporta logs de auditoria MCP estruturados no formato que os auditores exigem para produzir evidências de controle CC6.

• Seguros e Empresas Globais (GDPR, Residência de Dados): Organizações cobertas pelo GDPR devem manter um Registro de Atividades de Processamento sob o Artigo 30 que abranja o processamento assistido por IA, incluindo invocações de ferramentas MCP. Este registro é um documento de conformidade estruturado que descreve as finalidades do processamento, categorias de dados, transferências e salvaguardas. Os logs de auditoria do gateway MCP fornecem os dados de evento subjacentes que alimentam este registro, mas o próprio RoPA deve ser mantido separadamente pela função de proteção de dados da organização. Os logs do gateway também precisam capturar metadados suficientes para suportar solicitações de acesso de titulares de dados e para documentar quaisquer transferências transfronteiriças que ocorram através de invocações de ferramentas. Os requisitos de residência de dados podem proibir o tráfego MCP de sair de regiões geográficas específicas, exigindo implantações de gateway regionais.

Como a TrueFoundry Oferece Governança MCP Empresarial

O MCP Gateway da TrueFoundry entrega os quatro pilares de governança a partir de um único plano de controle implantado na própria conta de nuvem do cliente. As equipes de plataforma gerenciam toda a pilha de governança através de uma única interface, sem modificar as implementações individuais dos servidores MCP. Nenhum tráfego MCP sai do perímetro da empresa.

Empresas como NVIDIA, Zscaler, Siemens Healthineers e Automation Anywhere usam a TrueFoundry para passar de implantações MCP ad-hoc para ambientes controlados e governados. Para empresas que executam cargas de trabalho de agentes de IA em escala, os controles de custo impostos por políticas, os limites de orçamento e a camada de cache da TrueFoundry proporcionaram reduções significativas nos gastos mensais com inferência e invocação de ferramentas. Entre em contato com a TrueFoundry para obter números específicos do seu caso, com base no seu volume real de invocações e mix de modelos.

• Catálogo MCP centralizado com fluxo de trabalho de verificação: O plano de controle da TrueFoundry mantém o registro autoritativo de servidores MCP aprovados com metadados, status de aprovação e parâmetros de conexão. Novos servidores passam por um processo de verificação que inclui a revisão da descrição da ferramenta para riscos de envenenamento antes da distribuição para as configurações de IDE dos desenvolvedores. O recurso de Servidor MCP Virtual permite que as equipes de plataforma componham subconjuntos de ferramentas selecionados a partir de múltiplos servidores registrados, expondo apenas o que uma equipe específica precisa, sem implantar nova infraestrutura.

• OAuth2 e RBAC em cada chamada de ferramenta: Cada invocação MCP é autenticada via OAuth2 com a identidade corporativa do chamador. O gateway lida com todos os seis padrões de autenticação de saída e gerencia o ciclo de vida completo do token para fluxos de Código de Autorização, fluxos de Credenciais de Cliente e injeção de chave de API. As políticas RBAC aplicadas no gateway são aplicadas imediatamente a todos os clientes quando atualizadas, sem a necessidade de reimplantar o servidor.

• Políticas de metadados configuráveis por invocação: A TrueFoundry aplica mascaramento de dados via Detecção de PII e guardrails de Regex, limites de taxa por equipe, limites de custo por sessão de agente e regras de bloqueio para categorias de ferramentas restritas via políticas Cedar ou OPA. Tudo configurado na interface de gerenciamento. Nenhuma alteração no código do servidor MCP é necessária.

• Logs de auditoria transmitidos para o seu SIEM: Logs de auditoria JSON estruturados para cada invocação MCP são exportados via OpenTelemetry para Grafana, Datadog, Splunk ou qualquer destino compatível com OTLP. Em implantações auto-hospedadas, os logs são gravados no seu próprio armazenamento AWS S3, GCS ou Azure Blob em formato Parquet, consultáveis via Spark, DuckDB ou Athena. REQUEST_LOGGING_MODE: ALWAYS garante a captura completa para ambientes regulamentados.

• Implantação isolada por VPC com quatro opções: SaaS totalmente gerenciado sem sobrecarga de infraestrutura; gateway SaaS com armazenamento de dados de propriedade do cliente; plano de gateway auto-hospedado com plano de controle TrueFoundry a aproximadamente US$ 600 por mês em custo de infraestrutura; plano de controle totalmente auto-hospedado mais gateway a aproximadamente US$ 800 a US$ 1.000 por mês. As duas últimas opções garantem que nenhum tráfego de invocação MCP saia do seu perímetro para alcançar a infraestrutura da TrueFoundry.

‍