Agentes de IA estão rapidamente evoluindo de demonstrações de pesquisa para aplicações empresariais reais, conectando modelos de linguagem grandes (LLMs) com dados e serviços corporativos. Uma abordagem comum é usar ferramentas ou plugins para permitir que um LLM busque contexto ou execute ações – mas alguns descartam isso como apenas \"chamadas de API glorificadas\". Na realidade, integrar IA com segurança aos sistemas de negócios é muito mais complexo. É aqui que entra o Model Context Protocol (MCP), e por que uma arquitetura de proxy robusta com identidade OpenID Connect (OIDC) é crucial para implantações em escala empresarial.
\n\ngraph TB\n User[Usuário] --> |interage com| AIAgent[Agente de IA]\n AIAgent --> |requisições MCP| Proxy[Gateway de API/Proxy]\n Proxy --> |autentica via| OIDC[Provedor de Identidade/OIDC]\n Proxy --> |roteia para| Tools[Ferramentas/Servidores MCP]\n Tools --> |acessa| Backend[Sistemas Backend]\n \n subgraph \"Perímetro de Segurança\"\n Proxy\n OIDC\n end\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class Proxy,OIDC security;\nO diagrama acima ilustra a arquitetura de alto nível de uma implementação MCP segura. Em seu núcleo, esta arquitetura coloca um Gateway de API/Proxy como o ponto central de controle de segurança entre agentes de IA e ferramentas MCP. O proxy trabalha em conjunto com um Provedor de Identidade que suporta OIDC para criar um perímetro de segurança que impõe autenticação, autorização e controles de acesso. Isso garante que todas as requisições MCP de agentes de IA sejam devidamente autenticadas e autorizadas antes de alcançar as ferramentas MCP reais, que por sua vez acessam vários sistemas backend.
\n\nMCP é um padrão aberto (originalmente introduzido pela Anthropic) que fornece uma maneira consistente para assistentes de IA interagirem com fontes de dados externas e ferramentas. Em vez de integrações personalizadas para cada sistema, o MCP atua como um conector universal, permitindo que modelos de IA recuperem contexto ou executem tarefas através de uma interface JSON-RPC padronizada. Importante ressaltar que o MCP foi construído com segurança em mente – nada é exposto à IA por padrão, e ela só ganha acesso ao que você explicitamente permite. Na prática, no entanto, garantir esse princípio de \"lista de permissões\" em muitas ferramentas e usuários requer infraestrutura cuidadosa. Um gateway de API (proxy) de nível de produção pode servir como guardião entre agentes de IA (clientes MCP) e as ferramentas ou fontes de dados (servidores MCP), impondo regras de autenticação, autorização e roteamento.
\n\nAntes de mergulhar na solução, uma nota rápida sobre o Envoy: existem propostas ativas para usar o Envoy Proxy como implementação de referência de um gateway MCP. O rico roteamento L7 e extensibilidade do Envoy o tornam um forte candidato, e ele pode em breve incluir suporte MCP de primeira classe. Dito isso, o padrão que discutimos aqui é agnóstico de proxy – qualquer proxy reverso HTTP moderno ou gateway de API (Envoy, NGINX, HAProxy, Kong, etc.) que ofereça capacidades similares pode ser usado. O objetivo é delinear uma arquitetura segura para MCP, em vez das especificidades da configuração do Envoy.
\n\nÀ primeira vista, usar uma ferramenta de IA via MCP pode parecer tão simples quanto chamar uma API web. Em uma demonstração básica, um agente LLM poderia acessar um endpoint REST, obter algum JSON, e pronto. Mas em um cenário empresarial real, muito mais está acontecendo nos bastidores:
\n\ngraph LR\n subgraph \"Chamada de API Simples\"\n A[Cliente] -->|Requisição| B[API]\n B -->|Resposta| A\n end\n \n subgraph \"Realidade MCP Empresarial\"\n C[Usuário] -->|Interage| D[Agente de IA]\n D -->|Requisição MCP com Identidade| E[Gateway de API]\n E -->|Validar Token| F[Provedor de Identidade]\n E -->|Rotear Requisição| G[Registro de Ferramentas]\n E -->|Requisição Autorizada| H[Ferramenta MCP]\n H -->|Consulta com Contexto do Usuário| I[Sistema Backend]\n I -->|Dados| H\n H -->|Resposta| E\n E -->|Resposta Filtrada| D\n D -->|Resultado| C\n \n J[Monitoramento de Segurança] -..->|Auditoria| E\n end\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class E,F,G,J security;\nEste diagrama contrasta uma chamada de API simples com a realidade complexa das implementações MCP empresariais. No caso simples, um cliente faz uma requisição direta a uma API e recebe uma resposta. No entanto, na realidade MCP empresarial, o fluxo é muito mais complexo:
\n\nDurante todo esse processo, sistemas de monitoramento de segurança auditam as interações no nível do gateway. Este fluxo abrangente garante que a identidade do usuário, permissões e políticas de segurança sejam aplicadas em cada etapa, muito além do que uma simples chamada de API envolveria.
\n\nEm resumo, uma empresa deve tratar integrações de ferramentas de IA com o mesmo rigor que qualquer integração de serviço de produção – se não mais. Uma camada de gateway adequada ajuda a abordar essas preocupações atuando como um ponto de controle central. Em vez de codificar confiança em cada agente de IA ou ferramenta, o proxy impõe políticas de segurança em toda a organização. Esta abordagem nos move além da mentalidade \"apenas chame uma API\" para um modelo estruturado onde cada chamada MCP é autenticada, autorizada, monitorada e auditada.
\n\nVamos examinar alguns desafios de segurança específicos que surgem ao implantar MCP em escala, e por que eles importam:
\n\ngraph TD\n A[Envenenamento de Contexto] --> |mitigado por| B[Filtragem de Conteúdo]\n A --> |mitigado por| C[Verificação de Ferramentas]\n \n D[Propagação de Identidade] --> |resolvido com| E[Autenticação Baseada em Token]\n D --> |resolvido com| F[Cadeias de Delegação]\n \n G[Provisionamento Dinâmico de Ferramentas] --> |gerenciado por| H[Registro de Ferramentas]\n G --> |gerenciado por| I[Fluxos de Aprovação]\n G --> |gerenciado por| J[Rastreamento de Versão]\n \n K[Mudanças MCP Remotas] --> |controlado por| L[Governança de Proxy]\n \n subgraph \"Controles de Segurança do Proxy\"\n B\n C\n E\n F\n H\n I\n J\n L\n end\n \n classDef challenge fill:#f66,stroke:#333,stroke-width:2px;\n classDef solution fill:#6f6,stroke:#333,stroke-width:2px;\n \n class A,D,G,K challenge;\n class B,C,E,F,H,I,J,L solution;\nEste diagrama mapeia os principais desafios de segurança em fluxos de trabalho MCP (mostrados em vermelho) para suas soluções correspondentes (mostradas em verde) que podem ser implementadas dentro dos controles de segurança do proxy. O diagrama ilustra como:
\n\nAo implementar esses controles dentro da camada de proxy, as organizações podem abordar esses desafios de segurança de maneira centralizada e consistente, em vez de tentar resolvê-los individualmente para cada ferramenta ou agente.
\n\nsequenceDiagram\n participant User as Usuário\n participant AIAgent as Agente de IA\n participant Proxy as Gateway de API\n participant IdP as Provedor de Identidade\n participant Tool as Ferramenta MCP\n participant Backend as Sistema Backend\n \n User->>IdP: 1. Autenticar (usuário/senha)\n IdP->>User: 2. Emitir token OIDC\n User->>AIAgent: 3. Interagir com IA (token anexado)\n AIAgent->>Proxy: 4. Requisição MCP com token\n Proxy->>IdP: 5. Validar token\n IdP->>Proxy: 6. Token válido, contém claims/escopos\n \n alt Token Válido com Permissões Necessárias\n Proxy->>Tool: 7. Encaminhar requisição com contexto do usuário\n Tool->>Backend: 8. Consultar com autenticação delegada\n Backend->>Tool: 9. Retornar dados (filtrados por permissões do usuário)\n Tool->>Proxy: 10. Retornar resultado\n Proxy->>AIAgent: 11. Retornar resposta autorizada\n AIAgent->>User: 12. Apresentar resultado\n else Token Inválido ou Permissões Insuficientes\n Proxy->>AIAgent: 7. Rejeitar requisição (401/403)\n AIAgent->>User: 8. Reportar acesso negado\n end\nEste diagrama de sequência ilustra o fluxo de autenticação e autorização em um sistema MCP usando OIDC. O processo começa com o usuário se autenticando em um Provedor de Identidade e recebendo um token OIDC. Este token é então anexado às interações do usuário com o agente de IA. Quando o agente faz uma requisição MCP, ele inclui este token, que o Gateway de API valida com o Provedor de Identidade.
\n\nSe o token for válido e contiver as permissões necessárias (claims/escopos), a requisição é encaminhada para a ferramenta MCP apropriada junto com o contexto do usuário. A ferramenta pode então consultar sistemas backend usando autenticação delegada, garantindo que os dados retornados sejam filtrados de acordo com as permissões do usuário. O resultado flui de volta através do sistema para o usuário.
\n\nSe o token for inválido ou não tiver permissões suficientes, a requisição é rejeitada no nível do gateway com um código de erro apropriado (401 Não Autorizado ou 403 Proibido), e o agente de IA reporta essa negação de acesso ao usuário.
\n\nEste fluxo garante que a identidade e permissões do usuário sejam consistentemente aplicadas em toda a cadeia de interação, prevenindo acesso não autorizado a dados ou operações sensíveis.
\n\nsequenceDiagram\n participant Admin as Administrador\n participant Registry as Registro de Ferramentas\n participant Proxy as Gateway de API\n participant Tool as Nova Ferramenta MCP\n participant AIAgent as Agente de IA\n \n Admin->>Tool: 1. Desenvolver nova ferramenta MCP\n Admin->>Registry: 2. Registrar ferramenta (metadados, endpoints, requisitos de autenticação)\n Registry->>Registry: 3. Validar configuração da ferramenta\n Registry->>Proxy: 4. Atualizar configuração de roteamento\n \n Note over Registry,Proxy: Ferramenta agora registrada mas ainda não aprovada\n \n Admin->>Registry: 5. Aprovar ferramenta para grupos de usuários específicos\n Registry->>Proxy: 6. Atualizar políticas de acesso\n \n Note over AIAgent,Proxy: Ferramenta agora disponível para usuários autorizados\n \n AIAgent->>Proxy: 7. Descobrir ferramentas disponíveis\n Proxy->>AIAgent: 8. Retornar ferramentas aprovadas para o usuário\n AIAgent->>Proxy: 9. Chamar nova ferramenta\n Proxy->>Tool: 10. Rotear requisição se autorizado\nEste diagrama de sequência ilustra o fluxo de trabalho de registro e aprovação de ferramentas em um ambiente MCP seguro. O processo começa com um administrador desenvolvendo uma nova ferramenta MCP e registrando-a no Registro de Ferramentas, fornecendo metadados, endpoints e requisitos de autenticação. O registro valida a configuração da ferramenta e atualiza a configuração de roteamento no Gateway de API.
\n\nNeste ponto, a ferramenta está registrada mas ainda não aprovada para uso. O administrador deve explicitamente aprovar a ferramenta para grupos de usuários específicos, o que aciona uma atualização nas políticas de acesso no Gateway de API. Só então a ferramenta se torna disponível para usuários autorizados.
\n\nQuando um agente de IA descobre ferramentas disponíveis através do proxy, ele recebe apenas informações sobre ferramentas que foram aprovadas para o usuário atual. Quando o agente chama a nova ferramenta, o proxy roteia a requisição para a ferramenta apenas se o usuário estiver autorizado a acessá-la.
\n\nEste fluxo de trabalho garante que novas ferramentas passem por verificação e aprovação adequadas antes de poderem ser usadas, e que o acesso seja restrito apenas a usuários autorizados. Também centraliza o processo de governança de ferramentas, facilitando o gerenciamento do ciclo de vida das ferramentas MCP de maneira segura.
\n\nAo reconhecer esses desafios, engenheiros e arquitetos de segurança podem projetar defesas antes que problemas ocorram. A seguir, veremos como um proxy com reconhecimento de identidade pode fornecer essas defesas de maneira limpa e centralizada.
\n\nUm design comprovado em arquiteturas de nuvem é colocar um proxy reverso (frequentemente chamado de gateway de API) na frente de seus serviços. Sistemas de IA baseados em MCP não são exceção. Ao introduzir um proxy inteligente entre agentes de IA (clientes) e os servidores MCP (ferramentas/backends), criamos um funil controlado através do qual todo o tráfego de ferramentas de IA passa. Este proxy pode operar na Camada 7 (camada de aplicação), o que significa que ele entende HTTP e até payloads JSON, permitindo controle refinado. Abaixo, delineamos os papéis-chave que tal proxy desempenha na segurança do MCP:
\n\ngraph TB\n subgraph \"Lado do Cliente\"\n User[Usuário]\n AIAgent[Agente de IA]\n User -->|interage| AIAgent\n end\n \n subgraph \"Camada de Segurança\"\n Proxy[Gateway de API/Proxy]\n Auth[Autenticação]\n RBAC[Autorização/RBAC]\n Registry[Registro de Ferramentas]\n Audit[Log de Auditoria]\n \n Proxy -->|usa| Auth\n Proxy -->|aplica| RBAC\n Proxy -->|consulta| Registry\n Proxy -->|gera| Audit\n end\n \n subgraph \"Ferramentas MCP\"\n Tool1[Busca de Documentos]\n Tool2[Consulta de Banco de Dados]\n Tool3[Operações de Arquivo]\n Tool4[API Externa]\n end\n \n subgraph \"Sistemas Backend\"\n DB[(Bancos de Dados)]\n Storage[Armazenamento de Arquivos]\n APIs[APIs Internas]\n External[Serviços Externos]\n end\n \n AIAgent -->|requisições MCP| Proxy\n Proxy -->|roteia para| Tool1\n Proxy -->|roteia para| Tool2\n Proxy -->|roteia para| Tool3\n Proxy -->|roteia para| Tool4\n \n Tool1 -->|lê| DB\n Tool1 -->|lê| Storage\n Tool2 -->|consulta| DB\n Tool3 -->|gerencia| Storage\n Tool4 -->|chama| APIs\n Tool4 -->|chama| External\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class Proxy,Auth,RBAC,Registry,Audit security;\nEste diagrama fornece uma visão detalhada do padrão de proxy com reconhecimento de identidade para MCP. A arquitetura é dividida em quatro camadas principais:
\n\nTodas as requisições MCP de agentes de IA devem passar pelo proxy, que autentica as requisições, aplica políticas RBAC, consulta o registro de ferramentas para determinar o roteamento e gera logs de auditoria. O proxy então roteia requisições autorizadas para as ferramentas MCP apropriadas, que por sua vez interagem com os sistemas backend.
\n\nEsta arquitetura de segurança centralizada garante aplicação consistente de políticas de segurança em todas as interações MCP, independentemente de quais ferramentas estão sendo usadas ou quais sistemas backend estão sendo acessados.
\n\nDiferente de uma simples chamada de API sem estado, sessões MCP podem ser de longa duração e envolver streaming (Server-Sent Events para saída, etc.). O proxy deve garantir que todas as requisições e respostas pertencentes a uma determinada sessão ou conversa sejam tratadas consistentemente. Isso frequentemente significa implementar afinidade de sessão – se múltiplas instâncias de um servidor MCP estão rodando, o proxy roteará o tráfego de uma determinada sessão para a mesma instância cada vez. Isso previne problemas onde, digamos, o estado da ferramenta A (cache em memória, janela de contexto, etc.) é perdido porque a requisição 2 foi para uma instância diferente da requisição 1. Proxies modernos podem fazer balanceamento de carga com reconhecimento de sessão usando cabeçalhos HTTP ou rotas (por exemplo, mapeando um ID de sessão ou ID de cliente na URL para um backend específico). Além disso, o proxy pode lidar com conexões SSE graciosamente, para que respostas de streaming não sejam acidentalmente quebradas por intermediários de rede. Se uma sessão precisar ser retomada ou transferida, o gateway pode coordenar isso (como proposto em recursos futuros do Envoy para MCP). Em resumo, o proxy garante confiabilidade e consistência para as interações com estado do MCP, o que é crucial para a experiência do usuário e para manter o contexto correto.
\n\nsequenceDiagram\n participant User as Usuário\n participant AIAgent as Agente de IA\n participant Proxy as Gateway de API\n participant Instance1 as Instância de Ferramenta 1\n participant Instance2 as Instância de Ferramenta 2\n \n User->>AIAgent: Iniciar conversa\n AIAgent->>Proxy: Requisição MCP 1 (sessão=abc123)\n \n Note over Proxy: Roteamento de afinidade de sessão\n \n Proxy->>Instance1: Rotear para instância 1\n Instance1->>Proxy: Resposta com estado\n Proxy->>AIAgent: Retornar resposta\n \n User->>AIAgent: Continuar conversa\n AIAgent->>Proxy: Requisição MCP 2 (sessão=abc123)\n \n Note over Proxy: Mesmo ID de sessão roteia para mesma instância\n \n Proxy->>Instance1: Rotear para instância 1 (preserva estado)\n Instance1->>Proxy: Resposta com estado atualizado\n Proxy->>AIAgent: Retornar resposta\n \n Note over User,Instance2: Sem afinidade de sessão, requisição poderia ir para instância 2 e perder estado\nEste diagrama de sequência ilustra como a afinidade de sessão funciona em um ambiente MCP. Quando um usuário inicia uma conversa com um agente de IA, o agente faz uma requisição MCP para o Gateway de API com um identificador de sessão (neste caso, \"abc123\"). O gateway usa este ID de sessão para rotear a requisição para uma instância de ferramenta específica (Instância 1).
\n\nQuando o usuário continua a conversa, o agente faz outra requisição MCP com o mesmo ID de sessão. Como o gateway implementa afinidade de sessão, ele roteia esta requisição para a mesma instância (Instância 1), que preserva o estado da interação anterior. Isso garante uma experiência consistente e coerente para o usuário.
\n\nSem afinidade de sessão, a segunda requisição poderia ser roteada para uma instância diferente (Instância 2), que não teria as informações de estado da primeira requisição. Isso resultaria em uma experiência quebrada, pois a ferramenta não teria o contexto da interação anterior.
\n\nA afinidade de sessão é particularmente importante para MCP porque muitas interações de IA são com estado e dependentes de contexto. A capacidade do proxy de manter essa consistência de sessão é uma vantagem chave sobre abordagens de integração de API mais simples.
\n\nCada requisição atingindo o gateway MCP deve carregar um token de identidade válido – tipicamente um JSON Web Token (JWT) emitido por um Provedor de Identidade via OIDC (OpenID Connect). Ao exigir JWTs, o proxy descarrega a autenticação das próprias ferramentas e garante que apenas chamadas autenticadas e autorizadas passem. Na prática, isso significa que o agente de IA (ou a sessão do usuário com o agente) deve obter um token OIDC (por exemplo, um token de ID ou token de acesso) e anexá-lo a cada requisição MCP (frequentemente em um cabeçalho HTTP como Authorization: Bearer <token>). O proxy verifica este token, checa assinatura e claims (emissor, audiência, expiração, etc.), e rejeita qualquer requisição que não esteja devidamente autenticada. Desta forma, seus servidores MCP nunca veem uma chamada anônima – eles confiam que o gateway verificou a identidade.
sequenceDiagram\n participant User as Usuário\n participant App as Aplicação de IA\n participant IdP as Provedor de Identidade\n participant Proxy as Gateway de API\n participant Tool as Ferramenta MCP\n \n User->>App: Acessar aplicação de IA\n App->>IdP: Redirecionar para login\n User->>IdP: Autenticar\n IdP->>App: Código de autorização\n App->>IdP: Trocar código por tokens\n IdP->>App: Token de ID + token de acesso\n \n Note over App: Armazenar tokens com segurança\n \n User->>App: Requisitar usando ferramenta de IA\n App->>Proxy: Requisição MCP com token de acesso\n \n Proxy->>Proxy: Validar token (assinatura, expiração, audiência)\n Proxy->>Proxy: Extrair identidade e permissões do usuário\n \n alt Token Válido\n Proxy->>Tool: Encaminhar requisição com contexto do usuário\n Tool->>Proxy: Resposta\n Proxy->>App: Retornar resposta\n App->>User: Exibir resultado\n else Token Inválido\n Proxy->>App: 401 Não Autorizado\n App->>User: Sessão expirada, faça login novamente\n end\n \n Note over App,Proxy: Atualização de token acontece em segundo plano\n App->>IdP: Atualizar token quando necessário\n IdP->>App: Novo token de acesso\nEste diagrama de sequência ilustra o fluxo de autenticação OIDC em um ambiente MCP. O processo começa quando um usuário acessa a aplicação de IA, que redireciona para o Provedor de Identidade para autenticação. Após o usuário se autenticar, o Provedor de Identidade emite um código de autorização, que a aplicação troca por tokens de ID e acesso.
\n\nA aplicação armazena esses tokens com segurança e usa o token de acesso ao fazer requisições MCP através do agente de IA. Quando o proxy recebe uma requisição, ele valida o token verificando a assinatura, expiração, audiência e outros claims. Ele também extrai a identidade e permissões do usuário do token.
\n\nSe o token for válido, o proxy encaminha a requisição para a ferramenta MCP apropriada junto com o contexto do usuário. A ferramenta processa a requisição e retorna uma resposta, que flui de volta através do proxy para a aplicação e, finalmente, para o usuário.
\n\nSe o token for inválido (expirado, adulterado, etc.), o proxy retorna uma resposta 401 Não Autorizado, e a aplicação solicita que o usuário faça login novamente.
\n\nEm segundo plano, a aplicação pode usar um token de atualização para obter novos tokens de acesso quando necessário, sem exigir que o usuário se autentique novamente. Isso garante uma experiência de usuário suave enquanto mantém a segurança.
\n\nEsta integração OIDC fornece um mecanismo de autenticação robusto que é amplamente adotado em ambientes empresariais e se integra bem com sistemas de gerenciamento de identidade existentes.
\n\nEnquanto a discussão acima se concentra em autenticar o usuário humano, uma implantação MCP de nível de produção também deve identificar dois atores adicionais:
\n\nNosso post complementar \"OpenID Connect for Agents (OIDC-A) 1.0 Proposal\" ({{ site.baseurl }}/2025/04/28/oidc-a-proposal/) estende o OIDC Core 1.0 com um rico conjunto de claims para identidade de agente, atestação e cadeias de delegação. Na prática, isso significa:
\n\nagent_type, agent_model, agent_instance_id, delegator_sub, delegation_chain, etc.). Este token viaja junto com o token de acesso do usuário em cada requisição MCP.agent_capabilities, agent_trust_level, agent_attestation).Adotar OIDC-A traz vários benefícios:
\n\nemail:draft para invocar a ferramenta de Email).agent_attestation) permite que o gateway verifique a integridade e proveniência de agentes e ferramentas antes de rotear tráfego para eles.Para o restante deste artigo, sempre que nos referirmos a um \"token\" sendo validado pelo gateway, assuma que isso agora engloba o token do usuário, o token OIDC-A do agente e (opcionalmente) o token da ferramenta/recurso – todos avaliados em uma única etapa de decisão de política.
\n\nEste padrão já é amplamente usado em segurança de API: \"um Gateway de API pode implementar autenticação de forma segura e consistente... sem sobrecarregar as próprias aplicações.\" Em nosso contexto, o proxy MCP pode se integrar com seu SSO empresarial (Azure AD, Okta, etc.) via OIDC para lidar com fluxos de login de usuário e validação de token. Muitos gateways suportam OIDC nativamente, iniciando redirecionamentos para login de usuário se necessário e então armazenando o token resultante em um cookie para continuidade de sessão. Em um cenário de agente sem interface (onde a IA está chamando ferramentas servidor-para-servidor), o token pode ser provisionado fora de banda (por exemplo, o usuário fez login no aplicativo de IA, então o aplicativo injeta o token para o agente usar). De qualquer forma, o gateway impõe que sem token = sem acesso. Ele também pode mapear claims de token para papéis ou escopos para implementar autorização (por exemplo, apenas usuários com um escopo \"HR_read\" podem usar a ferramenta \"Banco de Dados de RH\"). Isso se alinha perfeitamente com o objetivo de design do MCP de conexões seguras – combinar MCP com OIDC e OIDC-A fornece um canal autenticado ponta a ponta para uso de ferramentas.
\n\nsequenceDiagram\n participant User as Usuário\n participant Agent as Agente LLM (OIDC-A)\n participant Proxy as Gateway de API\n participant Tool as Ferramenta MCP (OIDC-A)\n participant Backend as Sistema Backend\n\n User->>Agent: 1. Interagir (chat, formulário, etc.)\n Agent->>Proxy: 2. Requisição MCP\\nBearer token do usuário + token OIDC-A do agente\n Proxy->>Proxy: 3. Validar token do usuário (OIDC) & token do agente (OIDC-A)\n Proxy-->>Tool: 4. Encaminhar requisição mais *token de recurso* opcional para a ferramenta\n Tool->>Backend: 5. Consultar/agir usando autenticação delegada\n Backend-->>Tool: 6. Dados / resultado\n Tool-->>Proxy: 7. Resposta (pode incluir atestação)\n Proxy-->>Agent: 8. Resposta autorizada\n Agent-->>User: 9. Apresentar resultado\nUma vantagem poderosa do proxy é que ele pode tomar decisões de roteamento baseadas não apenas em URLs, mas em metadados dentro das requisições. Com MCP, requisições e respostas estão em formato JSON-RPC, que inclui campos como o nome do método da ferramenta, parâmetros e até anotações de ferramentas. Um proxy com reconhecimento de identidade pode ser configurado para inspecionar esses detalhes e aplicar regras de política. Por exemplo, você pode configurar regras como:
\n\ngraph TD\n subgraph \"Requisição MCP\"\n Request[Requisição JSON-RPC]\n Method[Método da Ferramenta]\n Params[Parâmetros]\n User[Identidade do Usuário]\n end\n \n subgraph \"Motor de Políticas\"\n Rules[Regras de Política]\n RBAC[Acesso Baseado em Papel]\n Audit[Log de Auditoria]\n Transform[Transformação de Resposta]\n end\n \n Request --> Method\n Request --> Params\n Request --> User\n \n Method --> Rules\n Params --> Rules\n User --> RBAC\n \n Rules --> Decision{Permitir/Negar}\n RBAC --> Decision\n \n Decision -->|Permitir| Forward[Encaminhar para Ferramenta]\n Decision -->|Negar| Reject[Rejeitar Requisição]\n \n Forward --> Audit\n Reject --> Audit\n \n Forward --> Tool[Ferramenta MCP]\n Tool --> Response[Resposta da Ferramenta]\n Response --> Transform\n Transform --> Filtered[Resposta Filtrada]\n \n classDef request fill:#bbf,stroke:#333,stroke-width:1px;\n classDef policy fill:#fbf,stroke:#333,stroke-width:1px;\n classDef action fill:#bfb,stroke:#333,stroke-width:1px;\n \n class Request,Method,Params,User request;\n class Rules,RBAC,Audit,Transform policy;\n class Decision,Forward,Reject,Filtered action;\nEste diagrama ilustra como a filtragem de metadados de ferramentas e aplicação de políticas funcionam em um proxy MCP. O processo começa com uma requisição MCP em formato JSON-RPC, que contém o método da ferramenta, parâmetros e informações de identidade do usuário. Esses componentes são extraídos e alimentados no motor de políticas.
\n\nO motor de políticas consiste em regras de política, controle de acesso baseado em papel (RBAC), log de auditoria e componentes de transformação de resposta. O método da ferramenta e parâmetros são avaliados contra as regras de política, enquanto a identidade do usuário é verificada contra permissões RBAC.
\n\nCom base nessas avaliações, o motor de políticas toma uma decisão de permitir/negar. Se a requisição for permitida, ela é encaminhada para a ferramenta MCP; se negada, ela é rejeitada. Em ambos os casos, a ação é registrada para fins de auditoria.
\n\nQuando uma requisição é permitida e processada pela ferramenta, a resposta pode passar por uma etapa de transformação antes de ser retornada ao cliente. Esta transformação pode filtrar ou modificar a resposta com base em políticas de segurança, como remover informações sensíveis que o usuário não deveria ver.
\n\nEsta aplicação de política refinada no nível de metadados permite controles de segurança sofisticados que vão muito além do simples roteamento baseado em URL. Por exemplo:
\n\ndelete_file e o usuário não estiver no grupo de Administradores de TI, negue a requisição.\"execute_sql em dias úteis entre 9h-17h, e registre todas as consultas.\"Isso é análogo a um firewall de aplicação web (WAF) ou um gateway de API realizando filtragem de conteúdo, mas adaptado para uso de ferramentas de IA. Na proposta Envoy MCP, isso corresponde a analisar mensagens MCP e usar filtros RBAC nelas. O proxy essencialmente entende a intenção de cada chamada de ferramenta e pode bloqueá-la apropriadamente. Ele também pode redigir ou transformar dados se necessário – por exemplo, removendo certos campos de uma resposta que o usuário não deveria ver, ou mascarando informações pessoalmente identificáveis. Ao centralizar isso no gateway, você evita ter que implementar verificações em cada serviço de ferramenta (que poderiam ser inconsistentes ou esquecidas). Auditoria é outro benefício: o proxy pode registrar cada invocação de ferramenta junto com identidade do usuário e parâmetros, alimentando sistemas SIEM para monitoramento. Dessa forma, se uma IA um dia fizer algo que não deveria, você tem um rastro claro de qual chamada de ferramenta estava envolvida e quem a solicitou. Em resumo, a filtragem baseada em metadados transforma o proxy em um ponto inteligente de aplicação de políticas, adicionando uma camada de segurança sobre as capacidades básicas do MCP.
\n\nEmpresas constantemente evoluem seus serviços – novas versões, testes A/B, implantações de staging vs. produção, etc. O proxy pode simplificar muito como os agentes de IA lidam com essas mudanças. Em vez da IA precisar saber qual versão de uma ferramenta chamar, o gateway pode implementar roteamento com reconhecimento de versão. Por exemplo, o endpoint MCP para uma ferramenta de \"Busca de Documentos\" poderia permanecer o mesmo para o agente, mas o proxy pode rotear 90% das requisições para v1 do serviço e 10% para uma nova v2 (para um lançamento canário). Ou rotear usuários internos para uma instância \"beta\" enquanto usuários externos vão para a estável. Isso é feito combinando atributos de requisição ou usando regras de roteamento que incluem audiência de usuário e identificadores de ferramenta.
\n\ngraph TB\n AIAgent[Agente de IA] -->|Requisição MCP| Proxy[Gateway de API]\n \n Proxy -->|\"90% do tráfego\"| V1[Ferramenta v1]\n Proxy -->|\"10% do tráfego\"| V2[Ferramenta v2 - Canário]\n \n Proxy -->|\"Usuários Internos\"| Beta[Versão Beta]\n Proxy -->|\"Usuários Externos\"| Stable[Versão Estável]\n \n Proxy -->|\"Requisições Pequenas\"| Standard[Instância Padrão]\n Proxy -->|\"Requisições Grandes\"| HighMem[Instância de Alta Memória]\n \n Proxy -->|\"Usuários dos EUA\"| US[Região EUA]\n Proxy -->|\"Usuários da UE\"| EU[Região UE]\n \n classDef proxy fill:#f96,stroke:#333,stroke-width:2px;\n classDef version fill:#bbf,stroke:#333,stroke-width:1px;\n classDef audience fill:#bfb,stroke:#333,stroke-width:1px;\n classDef size fill:#fbf,stroke:#333,stroke-width:1px;\n classDef region fill:#ff9,stroke:#333,stroke-width:1px;\n \n class Proxy proxy;\n class V1,V2 version;\n class Beta,Stable audience;\n class Standard,HighMem size;\n class US,EU region;\nEste diagrama ilustra as várias estratégias de roteamento que um Gateway de API pode implementar para requisições MCP. O gateway pode rotear tráfego com base em múltiplos fatores:
\n\nO agente de IA não precisa estar ciente dessas decisões de roteamento; ele simplesmente faz requisições para o nome lógico da ferramenta, e o gateway lida com a complexidade de rotear para o backend apropriado. Esta abstração simplifica a implementação do agente enquanto fornece capacidades operacionais poderosas.
\n\nDa mesma forma, o roteamento pode considerar contexto – por exemplo, direcionar requisições para o servidor regional mais próximo para menor latência se a localização do usuário for conhecida, ou escolher um backend diferente dependendo do tamanho da requisição (talvez uma instância especial de alta memória para arquivos muito grandes). Tudo isso é configurável no nível do proxy. O agente de IA simplesmente chama o nome lógico da ferramenta, e o gateway cuida de encontrar o backend certo. Isso não apenas facilita as operações (você pode atualizar ferramentas backend sem quebrar a interface da IA), mas também adiciona à segurança. Você poderia isolar certas versões para testes, ou garantir que ferramentas experimentais sejam acessíveis apenas sob certas condições. Ao controlar o fluxo de tráfego, o proxy ajuda a manter um princípio de menor privilégio em escala macro – a IA só alcança os backends que deveria, através de rotas apropriadas para o contexto atual.
\n\nAgora que cobrimos os principais padrões de segurança, vamos ver uma abordagem prática para implementar segurança MCP com um proxy com reconhecimento de identidade. Esta seção delineia os passos para configurar um ambiente MCP seguro, focando nos pontos de integração entre componentes.
\n\ngraph TB\n subgraph ImplementationSteps[\"Etapas de Implementação\"]\n Step1[1. Configurar Provedor de Identidade]\n Step2[2. Configurar Gateway de API]\n Step3[3. Implementar Registro de Ferramentas]\n Step4[4. Definir Políticas de Segurança]\n Step5[5. Integrar Agentes de IA]\n Step6[6. Monitorar e Auditar]\n \n Step1 --> Step2\n Step2 --> Step3\n Step3 --> Step4\n Step4 --> Step5\n Step5 --> Step6\n end\n \n classDef step fill:#beb,stroke:#333,stroke-width:1px\n class Step1,Step2,Step3,Step4,Step5,Step6 step\nEste diagrama delineia as seis etapas-chave na implementação de segurança MCP com um proxy. O processo segue uma progressão lógica:
\n\nCada etapa se baseia nas anteriores, criando uma implementação de segurança abrangente. As seções seguintes explorarão cada etapa em detalhes.
\n\nO primeiro passo é configurar seu provedor de identidade (IdP) para suportar os fluxos OIDC necessários para segurança MCP. Isso tipicamente envolve:
\n\nO IdP será responsável por autenticar usuários e emitir os tokens que serão usados para proteger requisições MCP. É importante configurar os escopos e claims apropriados para garantir que os tokens contenham as informações necessárias para decisões de autorização.
\n\nEm seguida, você precisará configurar seu gateway de API para atuar como o proxy MCP. Isso envolve:
\n\nsequenceDiagram\n participant Admin as Administrador\n participant Gateway as Gateway de API\n participant IdP as Provedor de Identidade\n \n Admin->>Gateway: 1. Configurar integração OIDC\n Gateway->>IdP: 2. Buscar documento de descoberta OIDC\n IdP->>Gateway: 3. Retornar endpoints e chaves\n \n Admin->>Gateway: 4. Configurar regras de roteamento MCP\n Admin->>Gateway: 5. Configurar políticas de segurança\n \n Note over Gateway: Gateway pronto para validar tokens e rotear tráfego MCP\nEste diagrama de sequência ilustra o processo de configuração de um Gateway de API para segurança MCP. O processo começa com um administrador configurando a integração OIDC no gateway. O gateway então busca o documento de descoberta OIDC do Provedor de Identidade, que retorna os endpoints e chaves necessários para validação de token.
\n\nEm seguida, o administrador configura regras de roteamento MCP, definindo como as requisições devem ser direcionadas para diferentes ferramentas MCP com base em vários critérios. O administrador também configura políticas de segurança, especificando quem pode acessar quais ferramentas e sob quais condições.
\n\nUma vez que essas configurações estejam completas, o gateway está pronto para validar tokens e rotear tráfego MCP de acordo com as regras e políticas definidas. Esta configuração estabelece o gateway como o ponto central de controle de segurança para todas as interações MCP.
\n\nAs etapas de configuração incluem:
\n\nO gateway será responsável por validar os tokens, aplicar as políticas de segurança e rotear as requisições MCP para os backends apropriados. É importante garantir que o gateway esteja devidamente configurado para lidar com o formato JSON-RPC do MCP e extrair as informações necessárias para decisões de política.
\n\nUm registro de ferramentas é essencial para gerenciar o ciclo de vida das ferramentas MCP em seu ambiente. Isso envolve:
\n\nO registro de ferramentas será responsável por manter a lista de ferramentas disponíveis, seus endpoints e seus requisitos de acesso. Ele também fornecerá as informações necessárias ao gateway de API para roteamento e aplicação de políticas.
\n\ngraph TB\n subgraph \"Registro de Ferramentas\"\n DB[(Banco de Dados de Ferramentas)]\n API[API do Registro]\n UI[Interface de Administração]\n \n UI -->|Gerenciar Ferramentas| API\n API -->|Operações CRUD| DB\n end\n \n subgraph \"Pontos de Integração\"\n Gateway[Gateway de API]\n Agents[Agentes de IA]\n \n API -->|Configurações de Ferramentas| Gateway\n API -->|Ferramentas Disponíveis| Agents\n end\n \n subgraph \"Ciclo de Vida da Ferramenta\"\n Register[Registrar]\n Approve[Aprovar]\n Deploy[Implantar]\n Monitor[Monitorar]\n Retire[Retirar]\n \n Register --> Approve\n Approve --> Deploy\n Deploy --> Monitor\n Monitor --> Retire\n end\n \n classDef registry fill:#bbf,stroke:#333,stroke-width:1px;\n classDef integration fill:#fbf,stroke:#333,stroke-width:1px;\n classDef lifecycle fill:#bfb,stroke:#333,stroke-width:1px;\n \n class DB,API,UI registry;\n class Gateway,Agents integration;\n class Register,Approve,Deploy,Monitor,Retire lifecycle;\nEste diagrama ilustra os componentes e ciclo de vida de um Registro de Ferramentas em um ambiente MCP. O Registro de Ferramentas consiste em três componentes principais:
\n\nO Registro de Ferramentas se integra com dois sistemas-chave:
\n\nO diagrama também mostra o ciclo de vida de uma ferramenta MCP:
\n\nEsta abordagem abrangente para gerenciamento de ferramentas garante que todas as ferramentas MCP sejam devidamente verificadas, implantadas e monitoradas ao longo de seu ciclo de vida, reduzindo riscos de segurança e problemas operacionais.
\n\nPolíticas de segurança são as regras que governam o acesso a ferramentas MCP. Isso envolve:
\n\nAs políticas de segurança serão aplicadas pelo gateway de API com base na identidade do usuário e na ferramenta sendo acessada. É importante garantir que as políticas sejam abrangentes e alinhadas com os requisitos de segurança de sua organização.
\n\nFinalmente, você precisará integrar seus agentes de IA com o ambiente MCP seguro. Isso envolve:
\n\nOs agentes de IA serão responsáveis por obter os tokens necessários e incluí-los em requisições MCP. Eles também precisarão lidar com erros de autenticação e autorização graciosamente, fornecendo feedback apropriado aos usuários.
\n\nsequenceDiagram\n participant User as Usuário\n participant Agent as Agente de IA\n participant App as Aplicação\n participant IdP as Provedor de Identidade\n participant Gateway as Gateway de API\n participant Tool as Ferramenta MCP\n \n User->>App: Acessar aplicação de IA\n App->>IdP: Autenticar usuário\n IdP->>App: Emitir tokens\n \n User->>Agent: Requisitar usando capacidades de IA\n Agent->>App: Requisitar token para MCP\n App->>Agent: Fornecer token\n \n Agent->>Gateway: Requisição MCP com token\n Gateway->>Gateway: Validar token & aplicar políticas\n Gateway->>Tool: Encaminhar requisição autorizada\n Tool->>Gateway: Resposta\n Gateway->>Agent: Retornar resposta\n Agent->>User: Apresentar resultado\n \n Note over App,Gateway: Ciclo de atualização de token\n App->>IdP: Atualizar token quando necessário\n IdP->>App: Novo token de acesso\nEste diagrama de sequência ilustra a integração de agentes de IA com um ambiente MCP seguro. O processo começa quando um usuário acessa a aplicação de IA, que autentica o usuário com o Provedor de Identidade e recebe tokens.
\n\nQuando o usuário faz uma requisição que requer capacidades de IA, o agente de IA solicita um token da aplicação, que o fornece. O agente então inclui este token em sua requisição MCP para o Gateway de API.
\n\nO gateway valida o token e aplica políticas de segurança para determinar se a requisição deve ser permitida. Se autorizada, a requisição é encaminhada para a ferramenta MCP apropriada, que a processa e retorna uma resposta. Esta resposta flui de volta através do gateway para o agente e, finalmente, para o usuário.
\n\nEm segundo plano, a aplicação lida com ciclos de atualização de token, solicitando novos tokens de acesso do Provedor de Identidade quando necessário. Isso garante operação contínua sem exigir que o usuário se autentique novamente com frequência.
\n\nEsta abordagem de integração garante que os agentes de IA operem dentro do framework de segurança estabelecido pela arquitetura de proxy, com todas as requisições devidamente autenticadas e autorizadas.
\n\nAo implementar uma arquitetura MCP segura com um proxy com reconhecimento de identidade, você vai muito além de \"chamadas de API glorificadas\" para uma integração robusta de nível empresarial entre agentes de IA e seus sistemas de negócios. Esta abordagem aborda os principais desafios de segurança de implantações MCP, incluindo:
\n\nA arquitetura baseada em proxy fornece um ponto de controle centralizado para aplicar políticas de segurança, gerenciar acesso a ferramentas e monitorar atividade de agentes de IA. Também simplifica operações ao abstrair a complexidade de serviços backend e fornecer uma interface consistente para agentes de IA.
\n\nÀ medida que o MCP continua a evoluir e ganhar adoção, os padrões de segurança descritos neste artigo se tornarão cada vez mais importantes para implantações empresariais. Ao implementar esses padrões agora, você pode garantir que sua infraestrutura de agentes de IA seja segura, escalável e pronta para o futuro.
\n\ngraph LR\n A[Chamadas de API Glorificadas] -->|Evolução| B[Arquitetura MCP Segura]\n \n subgraph \"Principais Benefícios\"\n C[Segurança Centralizada]\n D[Propagação de Identidade]\n E[Aplicação de Políticas]\n F[Auditoria & Conformidade]\n G[Simplicidade Operacional]\n end\n \n B --> C\n B --> D\n B --> E\n B --> F\n B --> G\n \n classDef benefit fill:#bfb,stroke:#333,stroke-width:1px;\n class C,D,E,F,G benefit;\nEste diagrama final resume a evolução de \"chamadas de API glorificadas\" para uma arquitetura MCP segura, destacando os principais benefícios desta abordagem:
\n\nAo adotar esta arquitetura, as organizações podem implantar com confiança agentes de IA em ambientes empresariais, sabendo que suas interações MCP são seguras, auditáveis e gerenciáveis em escala. Isso representa um avanço significativo além da visão simplista de ferramentas de IA como meras chamadas de API, reconhecendo os requisitos de segurança complexos de sistemas de IA de produção.
", "source_hash": "sha256:2e298f37ca328b0eb320a81887dd3640aeb212ad3bf1d820c547bb98ab9e3b19", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-02T03:19:16.703095+00:00" }