Gateways MCP não são suficientes: os agentes de IA precisam de identidade, autorização e comprovação

Os gateways MCP estão em toda parte (e isso é bom)

O Model Context Protocol (MCP) tornou-se rapidamente a forma padrão pela qual os agentes acessam o mundo externo: o protocolo comum para conectar um agente a bancos de dados, plataformas SaaS, executores de código, sistemas de pagamento e serviços internos. Se seus agentes fazem algo útil, é quase certo que o fazem por meio do MCP.

Naturalmente, os gateways MCP estão se proliferando. Todos os fornecedores de infraestrutura, todas as empresas de service mesh e um número crescente de projetos de código aberto e startups estão lançando soluções de gateway MCP. E elas oferecem valor real: roteamento centralizado, descoberta de serviços, gerenciamento de credenciais e controle básico de acesso para conexões de servidor MCP.

Esses são os requisitos mínimos. Eles não são a linha de chegada para a segurança.

Se sua empresa está levando agentes de IA de protótipos para a produção, onde eles chamam APIs, executam código, consultam dados confidenciais e interagem com outros agentes em nome da sua empresa, o roteamento e o controle de acesso são necessários, mas estão longe de ser suficientes. Os problemas difíceis de segurança são identidade, autorização e comprovação. E os gateways MCP não resolvem nenhum deles.

As três lacunas que os gateways MCP deixam em aberto

As implantações de agentes de IA corporativos devem responder a três perguntas antes de poderem entrar em produção. Os gateways MCP deixam todas as três sem resposta.

Lacuna 1: Identidade. “Quem é esse agente?”

Os gateways MCP fazem a autenticação no nível da conexão. Uma solicitação chega com uma chave de API válida ou um token OAuth, o gateway verifica se ela está na lista e a solicitação é aprovada. Isso indica que a credencial é válida. Mas não diz quem está fazendo a chamada.

Na prática, a maioria dos agentes de IA opera com chaves de API codificadas ou tokens de conta de serviço compartilhados. Quando o Agente A e o Agente B usam a mesma credencial de serviço para acessar um servidor MCP, o gateway vê dois chamadores idênticos. Não há mecanismo para o agente provar criptograficamente sua identidade, nem uma afirmação respaldada por certificado que um serviço downstream possa verificar de forma independente.

Esse é um problema que o mundo dos microsserviços resolveu há anos com SPIFFE e mTLS. Cada serviço recebe uma identidade criptográfica verificável. Quando o Serviço A chama o Serviço B, o serviço receptor sabe exatamente quem está ligando e pode provar isso. Os agentes de IA escritos com frameworks hoje não têm nada disso. Eles operam em um vácuo de identidade, e os gateways MCP não fazem nada para mudar isso.

A diferença na prática é gritante. Hoje, a maioria das chamadas de agentes chega a um servidor de ferramentas com a seguinte aparência:

Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...

Um token. Possivelmente compartilhado entre vários agentes. Possivelmente de longa duração. Sem nenhuma informação sobre qual carga de trabalho o produziu, em que contexto estava operando ou se foi renovado desde a última emissão. O servidor de ferramentas o aceita ou rejeita. Essa é toda a história da identidade.

Com a identidade de carga de trabalho baseada em SPIFFE, a mesma chamada chega com um SVID respaldado por certificado, uma asserção assinada criptograficamente que se parece com isto:

spiffe://diagrid.io/ns/payments/fraud-detection-agent

Esse URI não é um segredo. Não precisa ser. É uma afirmação verificável emitida pela plataforma, vinculada à carga de trabalho específica em execução em um namespace específico em um domínio de confiança específico, rotacionada automaticamente e comprovável por qualquer serviço que confie no mesmo domínio de confiança. O servidor da ferramenta receptora não verifica apenas “esta credencial está na minha lista de permissões?”. Ele verifica: qual é essa carga de trabalho, onde ela está sendo executada e se é a carga de trabalho que deveria estar fazendo essa chamada.

O primeiro modelo protege a credencial. O segundo modelo protege a identidade. Para agentes de IA que operam de forma autônoma entre serviços, bancos de dados e sistemas de pagamento, essa distinção é a diferença entre controle de acesso e confiança zero.

Do ponto de vista das normas, o uso do SPIFFE para identidade de carga de trabalho está sendo discutido ativamente no grupo de trabalho WIMSE da IETF e no grupo de trabalho AAIF Identity & Trust.

Para um aprofundamento sobre identidade, leia Identidade do Agente: A Camada Fundamental que Ainda Falta à IA

Lacuna 2: Autorização além do roteamento. “O que este agente tem permissão para fazer?”

Considere um agente com acesso a um servidor MCP de banco de dados de clientes. O gateway permite a conexão, o agente possui uma credencial válida e a regra de roteamento permite isso. O agente está no meio do fluxo de trabalho quando o LLM, interpretando uma instrução ambígua, constrói uma chamada que exclui registros que correspondem a um filtro amplo. Nada no gateway o impede. A regra de roteamento dizia que o agente poderia acessar o servidor. Ela não dizia nada sobre o que o agente poderia fazer uma vez lá.

Essa é a lacuna de autorização que os gateways MCP deixam em aberto. Eles controlam o acesso; quais chamadores podem acessar quais servidores. Eles não controlam o comportamento; quais ações uma identidade de agente específica tem permissão para realizar, em quais contextos de fluxo de trabalho, sob quais condições. Para software determinístico, essa distinção quase não importa; é possível raciocinar sobre o gráfico de chamadas com antecedência. Para agentes de IA, cujo comportamento é emergente e não determinístico por natureza, é a diferença entre um modelo de segurança e a ilusão de um.

O que a produção exige é uma autorização de negação por padrão no nível do fluxo de trabalho: políticas declarativas que especifiquem exatamente quais identidades de agente podem invocar quais fluxos de trabalho e ferramentas, aplicadas na camada da plataforma independentemente do que o LLM decida fazer. Essas políticas precisam estar na configuração da infraestrutura, sob a responsabilidade das equipes de plataforma e segurança, com controle de versão e auditáveis. Não no código do aplicativo, onde podem ser ignoradas, substituídas ou simplesmente esquecidas.

Lacuna 3: Prova. “O que esse agente fez? Podemos provar isso?”

Os gateways MCP geram logs. Os logs são úteis. Os logs não são prova.

A infraestrutura de logs corporativos melhorou significativamente. As plataformas SIEM modernas podem tornar os pipelines de logs resistentes à adulteração, e trilhas de auditoria imutáveis são possíveis com as ferramentas certas. Mas mesmo um log perfeitamente preservado responde à pergunta errada. Quando uma equipe de conformidade pergunta “você pode demonstrar que um humano aprovou essa chamada de ferramenta antes que o agente a executasse?”, uma entrada de log que diz ferramenta: transfer_funds, status: aprovado, usuário: alice não é uma resposta. Elas não fornecem nenhuma garantia criptográfica de que os eventos registrados realmente ocorreram na sequência registrada.

Em sistemas com múltiplos agentes, esse problema se agrava. Quando o Agente C invoca uma chamada de ferramenta destrutiva, ela foi autorizada pelo Agente B, que foi autorizado pelo Agente A, que foi acionado por um ser humano? Sem uma cadeia de custódia assinada que se propague por todos os limites dos agentes, não há como reconstruir ou verificar a cadeia de decisões.

Uma entrada na cadeia assinada não é um registro de log. É um objeto estruturado e criptograficamente verificável que acompanha o fluxo de trabalho. Uma entrada simplificada se parece com isto:

{
  "step": "fraud_check_passed",
  "agent": "spiffe://diagrid.io/ns/payments/sa/fraud-detection-agent",
  "timestamp": "2025-04-18T14:23:11Z",
  "result": "approved",
  "signature": "eyJhbGciOiJFUzI1NiJ9..."
}

Cada entrada é assinada pela identidade que a produziu. Quando a cadeia chega a um servidor de ferramentas downstream, ela carrega o histórico completo: quem iniciou o fluxo de trabalho, quais etapas de validação foram executadas, se houve aprovação humana e qual agente produziu cada entrada. O servidor de ferramentas verifica todas as assinaturas antes de agir. Uma entrada que não possa ser verificada porque a identidade do signatário é desconhecida, a assinatura não corresponde ou a etapa esperada está ausente faz com que a chamada seja recusada antes da execução.

A Lei de IA da UE, as orientações emergentes da SEC e os requisitos SOC2 em evolução convergem para uma expectativa clara: as empresas devem demonstrar controle verificável e responsabilidade sobre seus sistemas de IA.

O que as empresas precisam é de um registro inviolável e assinado criptograficamente de cada etapa em cada fluxo de trabalho do agente, não um log que alguém analisa após o fato, mas uma prova que os serviços a jusante verificam em tempo real antes de agir. Um servidor de ferramentas deve ser capaz de recusar uma chamada de ferramenta destrutiva, a menos que o histórico assinado comprove que um ser humano a aprovou, que uma etapa de validação foi aprovada e que o agente que fez a chamada está autorizado. Os gateways MCP não têm esse conceito.

Como é uma infraestrutura pronta para IA

Preencher as três lacunas requer três recursos que operam na camada da plataforma de IA, abaixo do código do agente ou da aplicação e acima da rede/computação.

Identidade criptográfica do agente

Todo agente precisa de uma identidade criptográfica baseada em SPIFFE, um certificado emitido e renovado automaticamente pela plataforma. Quando um agente chama uma ferramenta ou outro agente, o serviço receptor verifica a identidade por meio do mTLS padrão. Não se trata de um token em um cabeçalho. É uma afirmação respaldada por certificado, enraizada em uma cadeia de confiança que qualquer participante pode verificar de forma independente. A mesma abordagem comprovada em prática que protege a comunicação entre microsserviços, estendida aos desafios únicos de agentes autônomos e não determinísticos.

Autorização de fluxo de trabalho Zero-Trust

Identidade sem autorização não tem sentido. As equipes de plataforma e segurança precisam de políticas declarativas e compatíveis com GitOps que definam quais identidades de agentes podem invocar quais fluxos de trabalho e ferramentas. A postura padrão deve ser “negar tudo”: tudo o que não for explicitamente permitido é bloqueado. Essas políticas devem ser aplicáveis na camada da plataforma.

Essa é a diferença entre “este agente pode acessar este servidor” (o que os gateways fazem) e “esta identidade de agente específica pode invocar este fluxo de trabalho específico neste alvo específico, e nada mais” (o que a produção exige).

Política como Código sobre Histórico Assinado

Regras gerais de identidade para fluxo de trabalho são necessárias, mas não suficientes. As questões de autorização realmente interessantes são contextuais: essa chamada de ferramenta foi precedida por uma etapa de detecção de fraudes? Um ser humano a aprovou nos últimos 30 segundos? O agente que está fazendo esta chamada é o mesmo que recebeu a solicitação original do usuário, ou a cadeia foi sequestrada?

Essas questões não podem ser respondidas apenas a partir da solicitação. Elas exigem um raciocínio sobre o histórico do fluxo de trabalho que levou à chamada. Com um histórico de execução assinado criptograficamente propagado por todas as etapas, um mecanismo de políticas no estilo Open Policy Agent (OPA) que pode avaliar Rego (ou qualquer outra linguagem de política) em relação a toda a cadeia no momento da decisão:

allow_tool_call {
    input.history[_].step == "human_approval"
    input.history[_].step == "fraud_check_passed"
    input.history[_].agent == input.calling_agent
}

A política é executada no receptor, não no chamador. Os agentes não podem falsificar o histórico, pois cada entrada é assinada pela identidade que a produziu. Isso transforma o próprio histórico do fluxo de trabalho em uma entrada verificável para a autorização, da mesma forma que o OPA já avalia as reivindicações JWT e o contexto da solicitação para APIs HTTP, mas agora estendido de ponta a ponta por meio de cadeias de execução com múltiplos agentes e ferramentas.

Cadeia de Custódia Criptográfica

Quando os agentes colaboram além dos limites dos serviços, cada etapa deve ser assinada. Cada serviço assina o histórico de execução acumulado com seu próprio certificado de identidade, criando uma cadeia à prova de adulteração. Uma ferramenta a jusante não verifica apenas “esse chamador tem permissão?”. Ela verifica todo o histórico: quem iniciou o fluxo de trabalho, quais aprovações ocorreram, quais etapas de validação foram aprovadas e se todas as identidades na cadeia estão autorizadas.

Este não é um registro que alguém verifica posteriormente. É uma prova criptográfica verificada antes de cada chamada de ferramenta. Isso permite padrões de aplicação impossíveis apenas com o roteamento: uma ferramenta MCP de pagamento que se recusa a executar, a menos que o histórico assinado comprove que um fluxo de trabalho de detecção de fraudes foi aprovado e que um ser humano aprovou a transação.

Como isso funciona na prática

Esses não são requisitos teóricos. O Diagrid Catalyst, a plataforma gerenciada para executar aplicativos baseados em Dapr e agentes de IA em produção, oferece tudo isso hoje.

MCP como infraestrutura. As conexões do servidor MCP são declaradas como CRDs do Kubernetes com detalhes de conexão, credenciais e escopos de acesso. Não há lógica de conexão codificada no código do aplicativo. As credenciais são resolvidas a partir de armazenamentos secretos em tempo de execução e nunca são expostas ao código do agente.

Chamadas de ferramentas MCP duráveis. Cada chamada de ferramenta MCP é executada como um fluxo de trabalho dentro do sidecar do Dapr. Se um processo travar no meio da chamada, a execução é retomada a partir do último ponto de verificação. Chamadas de ferramentas de longa duração (migrações de banco de dados, sequências de API externas, execução de código) sobrevivem automaticamente a falhas de processo e de nó.

Ganchos de middleware. Antes e depois de cada chamada de ferramenta, ganchos de fluxo de trabalho configuráveis permitem autorização por ferramenta, registro de auditoria, limitação de taxa, validação de entrada e controles de custo, sem modificar o código do agente. Esses são fluxos de trabalho em si, composíveis e implantáveis de forma independente, e é neles que você conecta o OPA ou qualquer outro mecanismo de política para avaliar o histórico assinado antes que uma ferramenta seja realmente executada.

Política de acesso a fluxos de trabalho declarativa. Um CRD do Kubernetes que controla quais identidades de aplicativos podem iniciar fluxos de trabalho e atividades específicos em um aplicativo de destino. Utiliza identidade baseada em SPIFFE/mTLS para verificação do chamador. Suporta padrões glob, regras por chamador e políticas de negação total em todo o namespace. Quando uma política existe, tudo o que não for explicitamente permitido é negado.

Propagação do histórico assinado. Os fluxos de trabalho optam por enviar seu histórico completo de execução para fluxos de trabalho e atividades filhos. Cada identidade que interage com um fluxo de trabalho assina o histórico acumulado com seu certificado de identidade. Os serviços a jusante verificam toda a cadeia antes de agir, e os mecanismos de política podem avaliá-la.

Intervenção humana com comprovação. Os agentes podem pausar para aprovação humana por meio de eventos de fluxo de trabalho de longa duração. Quando uma ferramenta a jusante recebe o histórico assinado, ela pode verificar criptograficamente se a aprovação realmente ocorreu, e não apenas se um log indica que sim.

Considere um agente processando uma solicitação de reembolso de cliente acima de um limite definido. Em vez de executar imediatamente ou falhar, o fluxo de trabalho pausa e emite um evento de aprovação:

Agente de reembolso atinge limite de US$ 10.000
        │
        ▼
O fluxo de trabalho é suspenso — emite solicitação de aprovação
  — envia mensagem no Slack para o canal de aprovações de pagamentos
  — registros pendentes de aprovação no histórico de assinaturas
  — define um tempo limite de 30 minutos
        │
   Revisões manuais no Slack
        │
        ├── Aprova → o fluxo de trabalho é retomado
        │             etapa de aprovação assinada e anexada ao histórico
        │
        └── Recusa / tempo limite → fluxo de trabalho é encerrado
                              recusa registrada no histórico assinado
        │
        ▼
A ferramenta de reembolso recebe a chamada
  — verifica se o histórico assinado contém a etapa human_approval
  — confirma que o carimbo de data/hora da aprovação está dentro do intervalo previsto na política
  — confirma se a identidade do aprovador é um aprovador autorizado
  — executa apenas se todas as verificações forem aprovadas

A aprovação não é uma entrada de log adicionada posteriormente. É uma etapa assinada no histórico de execução que o servidor da ferramenta verifica antes de agir. Se a etapa de aprovação estiver ausente, expirada ou assinada por uma identidade não reconhecida, a chamada da ferramenta é recusada, e não é auditada após o dano já ter ocorrido.

A pergunta que as empresas devem fazer

A questão não é “precisamos de um gateway MCP?”. Provavelmente sim, e isso certamente deve fazer parte do gerenciamento de conexões de entrada. MCP é o protocolo, e você precisa de infraestrutura para gerenciar conexões com servidores MCP em escala, fazer roteamento e aplicar alguma limitação de taxa.

A pergunta é: sua infraestrutura MCP fornece identidade, autorização e comprovação?

Sua plataforma de IA pode dizer exatamente qual agente fez uma chamada, não qual credencial foi usada, mas qual identidade verificada criptograficamente? Ela pode aplicar políticas de confiança zero e negação por padrão sobre o que cada agente tem permissão para fazer, gerenciadas pela equipe da sua plataforma e aplicadas independentemente do que o LLM decidir? Ela consegue produzir uma cadeia de custódia assinada e à prova de adulteração que comprove cada etapa em cada fluxo de trabalho do agente, verificável em tempo real por serviços downstream antes que eles ajam?

Se a resposta for não, você não tem uma camada de segurança para agentes de IA. Você tem um roteador.

E roteadores não são suficientes.

Conheça o Catalyst mais a fundo.

Fale com um especialista