Governança do conector MCP por meio de um gateway de API de IA: tokens OAuth, escopos de ferramentas e atribuição por usuário

Quando um agente chama o Gmail, o Drive, o Stripe, um sistema interno ou um servidor MCP remoto, a solicitação do modelo é apenas parte do evento de segurança. A verdadeira questão operacional é: quem autorizou o conector, quais OAuth escopos foram concedidos, qual ferramenta foi invocada, quais dados saíram do limite do provedor de modelo e como o acesso pode ser revogado durante um incidente?

Um gateway de IA API que apenas chama modelos de proxies não pode responder a essas perguntas. Pode saber o inquilino, modelo, chave API, tamanho do prompt e custo. Ele pode não saber que o modelo delegou trabalho a um conector operando sob o token OAuth de um usuário humano. Essa lacuna enfraquece a atribuição, a política de aprovação, a revogação e a resposta de auditoria.

O padrão prático é tratar MCP a autorização do conector como um objeto de plano de controle de gateway de primeira classe. Não reduza a governança do conector a uma lista de permissões de nomes de ferramentas. Gerencie registro de conector, OAuth proveniência de token, classificação de escopo de ferramenta, política de aprovação, estado de revogação e registro de auditoria como parte da mesma camada de governança que já lida com API gerenciamento de chaves, acesso de modelo, política de locatário e análise de uso.

Fatos, recomendações e previsões

Fatos: OpenAI documenta MCP remoto como uma categoria de ferramenta de Respostas API e permite que aplicativos forneçam um token de acesso OAuth para um servidor MCP remoto. OpenAI também identifica conectores de serviços hospedados, como Gmail, Google Drive, Google Calendar, Dropbox e Microsoft Teams. A documentação de controle de dados de OpenAI diz que MCP servidores usados ​​com a ferramenta de servidor remoto MCP são serviços de terceiros e os dados enviados a eles estão sujeitos às políticas de retenção desses serviços. A documentação do conector Anthropic descreve conectores personalizados usando servidores MCP remotos e observa que os usuários geralmente autorizam conectores por meio de OAuth, com permissões que podem ser revogadas posteriormente. A especificação de autorização MCP usa autorização no estilo OAuth para transportes MCP baseados em HTTP. OAuth a orientação de segurança na RFC 9700 é relevante para manipulação de tokens, fluxos de código de autorização e segurança do cliente.

Recomendações: Um gateway deve registrar conectores antes do uso em produção, vincular cada chamada de conector ao locatário, chave, usuário, assunto do token e identidade do servidor, classificar ferramentas por risco de leitura/gravação, aplicar a política de aprovação antes do envio e manter o estado de revogação centralmente.

Previsões: A adoção remota MCP levará os gateways de IA além do roteamento de modelos e da medição de tokens. Gateways que não conseguem ver a identidade do conector, OAuth escopo, decisões de aprovação e limites de retenção downstream serão mais difíceis de usar em ambientes regulamentados, corporativos e operados por parceiros.

O problema da governança é a divisão de identidade

As chamadas do conector envolvem pelo menos três identidades e não devem ser mescladas em registros ou verificações de políticas.

• Chamador do gateway: a API chave, conta de serviço, carga de trabalho ou aplicativo de parceiro que enviou a solicitação de modelo.
• Usuário delegado: o usuário humano ou final que autorizou acesso ao Gmail, Drive, CRM, agenda, pagamentos, dados internos ou outro recurso protegido.
• Destino do conector: o servidor MCP remoto ou conector de serviço hospedado que recebe a chamada da ferramenta e pode encaminhá-la para outro sistema.

Se essas identidades forem recolhidas em um campo chamado user, a trilha de auditoria se tornará ambígua. Uma conta de serviço de produção pode enviar uma solicitação em nome de 20 mil usuários finais. Um único ser humano pode autorizar vários conectores com escopos diferentes. Um servidor remoto MCP pode expor ferramentas suportadas por vários serviços downstream. O gateway precisa de campos separados para todos os três.

Um modelo de evento útil começa com campos como:

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_acme",
  "gateway_key_id": "key_support_bot_prod",
  "workload_id": "support_agent",
  "end_user_id": "user_7421",
  "connector_id": "conn_google_drive_support",
  "mcp_server_url_hash": "sha256:...",
  "oauth_subject": "google-oauth-sub:...",
  "tool_name": "drive.files.search",
  "tool_action_class": "read",
  "approval_decision": "auto_allowed",
  "retention_class": "third_party_standard",
  "downstream_request_id": "optional_provider_or_connector_id"
}

Essa estrutura permite que as equipes de segurança, finanças e plataforma respondam a perguntas diferentes no mesmo registro. Qual inquilino invocou a ferramenta? Qual chave de aplicativo fez isso? Qual acesso delegado pelo usuário final? Qual conector recebeu dados? A ação foi somente leitura ou destrutiva? A aprovação foi necessária?

Modelar conectores como recursos de gateway

Um conector deve ser registrado antes de ser usado na produção. A inscrição não precisa ser lenta, mas deve produzir um objeto durável que a política possa referenciar.

Um recurso mínimo de conector pode incluir:

• tenant_id: o locatário ou organização com permissão para usar o conector.
• connector_id: um identificador interno estável, independente dos nomes de exibição do servidor.
• server_url: o URL do servidor MCP remoto ou o identificador do conector hospedado.
• owner_user_id: o administrador ou usuário que o inscreveu.
• authorization_server: metadados do emissor ou do servidor de autorização, quando disponíveis.
• allowed_tools: nomes e versões ou impressões digitais de ferramentas revisadas.
• tool_classes: leitura, gravação, exportação, administração, pagamento, mensagem ou desconhecido.
• approved_scopes: OAuth escopos aprovados para o conector.
• retention_class: interno, provedor de modelo, padrão de terceiros ou proibido para cargas de trabalho confidenciais.
• revocation_status: ativo, user_revoked, tenant_disabled, expirado, em quarentena ou negado.

Isso é semelhante em espírito a um perfil de modelo ou registro de credencial de provedor, mas a autorização do conector não é o mesmo objeto que uma chave de modelo upstream. As credenciais de tempo de execução do provedor permitem que o gateway chame APIs de modelo. Os tokens de conector representam autoridade delegada em sistemas internos ou de terceiros. Eles merecem proveniência, controles de armazenamento e políticas de auditoria separados.

Intermediar ou validar OAuth tokens deliberadamente

Existem dois padrões de implementação comuns.

Intermediado por gateway OAuth

Neste modelo, o gateway inicia ou coordena o fluxo OAuth, armazena tokens de atualização ou material de token de acesso em um cofre, cria sessões de conector de curta duração e anexa tokens de acesso ao despachar chamadas remotas MCP. Isso dá ao gateway um forte controle sobre consentimento, vida útil do token, revogação e junções de auditoria.

A compensação é a complexidade. O gateway deve lidar com telas de consentimento, segurança de fluxo de código de autorização, atualização de token, rotação de token, armazenamento criptografado, gerenciamento de URI de redirecionamento, validação de emissor e configuração de aplicativo OAuth específica do locatário. O RFC 9700 é importante aqui porque esse padrão coloca o gateway próximo de OAuth responsabilidades do cliente.

Gerenciado pelo aplicativo OAuth

Neste modelo, o aplicativo obtém o token OAuth e o transmite pelo modelo ou caminho do gateway ao invocar um conector MCP remoto. O envio pode ser mais rápido porque os produtos existentes já podem ter fluxos de autorização do conector.

A compensação é a governança fragmentada. Se o gateway vir apenas um token opaco, ele poderá não conhecer o assunto, os escopos, o emissor, a atualização, o status de revogação ou a proveniência do consentimento do token. Uma versão mais segura desse padrão exige que o aplicativo forneça metadados do conector assinado com cada chamada, e o gateway deve validar o emissor, o público, a expiração, o registro do conector, a vinculação do usuário e o escopo aprovado antes do envio.

Para conectores de dados do usuário, como e-mail, calendário, armazenamento, CRM e pagamentos, prefira OAuth tokens por usuário. Os tokens ao portador de longa duração compartilhados devem ser limitados a fluxos de trabalho explícitos de contas de serviço com escopo definido para um locatário e revisados como recursos de maior risco.

Normalizar escopos de ferramentas antes do envio

MCP servidores podem expor nomes de ferramentas e metadados, e alguns ecossistemas fornecem dicas como anotações somente leitura. Use esses sinais, mas não trate os metadados fornecidos pelo servidor como totalmente confiáveis. Os metadados da ferramenta podem estar errados, desatualizados, ambíguos ou adversários. A orientação MCP da OWASP destaca privilégios mínimos, lista de permissões, autenticação, autorização e monitoramento; MCP Os 10 principais trabalhos também chamam a atenção para os riscos de envenenamento de ferramentas.

Um gateway deve manter suas próprias classes de ação normalizadas:

• Ler: pesquisar, listar, obter, buscar, recuperar, resumir o conteúdo existente.
• Escrever: criar, atualizar, editar, rotular, mover, comentar, agendar.
• Enviar: e-mail, mensagem de bate-papo, webhook, resposta de ticket, notificação.
• Excluir: remover, limpar, arquivar, revogar.
• Exportação: download em massa, transferência de arquivos, extração de conjunto de dados.
• Financeiro: cobrança, reembolso, fatura, pagamento, alteração de assinatura.
• Administrador: alteração de permissão, convite de usuário, atualização de função, edição de política.
• Desconhecido: qualquer coisa não revisada ou não classificada com segurança.

Em seguida, aplique a política em classes normalizadas em vez de nomes brutos de ferramentas. Por exemplo:

policy connector_default {
  allow read when tenant.connector_risk in ["low", "medium"]
    and user.authorization_age_days <= 90
    and connector.retention_class != "prohibited";

  require_approval send, write when connector.risk != "low";
  require_approval export, delete, financial, admin;
  deny unknown;
}

Isso mantém a política estável quando um conector renomeia gmail.search para mail.messages.query. A ferramenta bruta ainda precisa de revisão, mas o sistema de aprovação pode raciocinar em categorias operacionais.

Execute uma verificação do conector pré-despacho

Antes que o gateway permita uma chamada de conector iniciada por modelo, ele deverá executar uma decisão compacta de pré-despacho. É aqui que a análise de uso de IA, a política de segurança, o fluxo de trabalho de aprovação e a política de retenção se encontram.

Uma sequência prática é:

1. Resolver inquilino e chave: identifique a chave do gateway, o inquilino, a carga de trabalho, o ambiente e a solicitação do modelo.
2. Resolver usuário final: exige um ID de usuário final estável para conectores delegados. Rejeite chamadas delegadas anônimas, a menos que seja explicitamente permitido.
3. Resolver conector: corresponder o URL do servidor ou ID do conector hospedado a um recurso de conector inscrito.
4. Validar token: verifique o emissor, o público quando aplicável, a expiração, o assunto, a vinculação do locatário, o estado de revogação e os escopos necessários.
5. Classificar ação: mapeie o nome da ferramenta e os metadados para leitura, gravação, envio, exclusão, exportação, financeiro, administrativo ou desconhecido.
6. Verifique o limite de retenção: determine se a carga de trabalho permite processamento e registro de MCP servidores de terceiros.
7. Aplicar política de aprovação: permitir automaticamente, exigir aprovação do usuário, exigir aprovação do administrador, bloquear ou colocar em quarentena.
8. Reservar orçamento se for faturável: se a execução do conector tiver cobranças diretas ou indiretas, reserve o orçamento antes do envio.
9. Escreva a decisão: persista a decisão antes de chamar o conector, não apenas após o sucesso.

Escrever a decisão primeiro é importante. Se o conector atingir o tempo limite, transmitir saída parcial ou disparar um erro downstream, o log de auditoria ainda deverá mostrar que o gateway permitiu ou negou uma tentativa de ação específica.

A aprovação deve levar em conta o fluxo de trabalho

A aprovação por chamada é simples de raciocinar e muitas vezes inutilizável na prática. Um agente de suporte ao cliente que precisa ler um ticket, pesquisar no Drive, redigir um e-mail e atualizar um registro de CRM não deve forçar o usuário a passar por um modal para cada operação de leitura inofensiva. Ao mesmo tempo, enviar um e-mail, excluir um arquivo, reembolsar um pagamento ou exportar uma pasta não deve ser delegado silenciosamente porque um modelo selecionou uma ferramenta.

Uma política viável é dividida em camadas:

• Permitir automaticamente ferramentas somente leitura revisadas para locatários de baixo risco e nova autorização de usuário.
• Exigir aprovação para ações de envio, criação, atualização, exclusão, exportação, financeiras e administrativas.
• Permitir aprovações agrupadas para um fluxo de trabalho, escopo e janela de tempo nomeados.
• Exigir reaprovação quando os escopos se expandirem, as definições da ferramenta mudarem materialmente ou o conector passar para uma classe de risco mais alta.
• Bloqueie ferramentas desconhecidas até serem revisadas.

As aprovações agrupadas devem ser explícitas. Um usuário pode aprovar: "Durante os próximos 30 minutos, permita que este fluxo de trabalho de suporte pesquise no Drive e rascunhe respostas, mas exija confirmação antes de enviar." Isso é mais útil do que uma opção de permissão/negação de conector binário.

Os limites de retenção precisam de seu próprio campo

MCP remotas podem mover dados para fora dos limites de retenção e processamento do provedor de modelo. Isso não é automaticamente errado, mas deve ser visível. Uma carga de trabalho que tem permissão para usar um endpoint de modelo sob uma configuração de retenção de dados ainda pode ser proibida de enviar o mesmo conteúdo para um servidor MCP de terceiros com termos de retenção diferentes.

Adicione classificação de retenção a cargas de trabalho e conectores. Classes de exemplo:

• internal_only: nenhuma chamada de conector de terceiros é permitida.
• approved_processors_only: o conector deve estar em uma lista de fornecedores aprovados.
• third_party_standard_allowed: o processamento do conector SaaS padrão é permitido.
• no_argument_logging: chamadas de conector são permitidas, mas os argumentos devem ser editados ou com hash.
• export_blocked: leitura/pesquisa permitida, exportação em massa negada.

É aqui que o gateway protege as equipes contra um erro sutil: assumir que os controles de dados do provedor de modelo se aplicam automaticamente a todas as ferramentas que o agente usa. Eles não se aplicam necessariamente quando os dados são enviados para um servidor MCP remoto ou conector de serviço externo.

Crie um livro-razão de auditoria do conector

Um livro-razão de auditoria de conector deve juntar solicitações de modelo, autorização de gateway, envio de conector e resultados downstream. Não confie apenas nos rastreamentos brutos do provedor, pois cada provedor pode expor eventos de ferramenta de maneira diferente, e os logs do aplicativo podem omitir o token ou o contexto de aprovação.

Os campos contábeis recomendados incluem:

• model_request_id e ID de rastreamento.
• tenant_id, gateway_key_id, carga de trabalho, ambiente e ID do usuário final.
• connector_id, hash de URL do servidor, identificador do conector hospedado e classe de risco.
• tool_name, versão da ferramenta ou impressão digital de metadados e classe de ação normalizada.
• OAuth emissor, assunto do token, hash do conjunto de escopo, intervalo de expiração e proveniência do token.
• Hash de argumentos, argumentos redigidos, classe de confidencialidade e classe de retenção.
• Decisão de aprovação, aprovador, escopo de aprovação e expiração da aprovação.
• Status de envio, status de resposta, classe de erro, latência e IDs de solicitação downstream, quando disponíveis.

O registro completo de argumentos pode ajudar na resposta a incidentes, mas também aumenta o risco de privacidade e retenção. Prefira campos estruturados, hashing, redação seletiva e tags de confidencialidade por padrão. Permitir captura completa somente sob um incidente explícito ou política de depuração com expiração.

Revogação e quarentena são requisitos do produto

A revogação não pode ser uma edição manual do banco de dados. Usuários e administradores precisam de fluxos de trabalho que se transformem em estado de política imediato.

Implemente pelo menos estas ações:

• Desconexão do usuário: revoga ou marca inativo todos os tokens para autorização do conector de um usuário.
• Desativação de locatário: bloqueia um conector para um locatário inteiro sem desativar o tráfego de modelo não relacionado.
• Tratamento de expiração de token: falha no fechamento ou reautorização quando a atualização falha ou a atualização da autorização excede a política.
• Quarentena do conector: bloqueia um conector preservando sua configuração e registros para investigação.
• Lista de bloqueios de emergência: bloqueio por hash de URL do servidor, ID do conector, emissor ou impressão digital da ferramenta.
• Rebaixamento de escopo: reautorize com menos escopos quando um fluxo de trabalho não precisar mais de acesso amplo.

O detalhe importante da implementação é que o status de revogação deve ser verificado no momento do envio. Uma sincronização noturna é útil para reconciliação, mas não é suficiente para resposta a incidentes.

Sondas de conformidade para conectores MCP remotos

Antes que um conector esteja disponível para locatários de produção, teste-o como uma dependência governada. Um pequeno conjunto de sondagens detecta muitas falhas de integração e políticas.

• A descoberta de metadados retorna identidade de servidor estável e definições de ferramentas esperadas.
• Os metadados de recursos protegidos e o comportamento de autorização correspondem às suposições documentadas quando aplicável.
• Os requisitos de registro de cliente dinâmico são compreendidos, suportados ou explicitamente desativados.
• Solicitações sem tokens falham com segurança.
• Os tokens expirados falham de forma previsível e não acionam novas tentativas descontroladas.
• A classificação de leitura/gravação corresponde ao comportamento observado, não apenas às descrições.
• Metadados de ferramenta mal formados são rejeitados ou marcados como desconhecidos.
• Alterações na lista de ferramentas acionam revisão quando nomes, escopos, descrições ou classes de risco mudam.
• Os erros do conector são registrados sem vazar argumentos confidenciais para campos de erro genéricos.

Essas sondagens não substituem a revisão de segurança, mas fornecem ao gateway uma maneira repetível de detectar desvios. MCP servidores remotos podem mudar independentemente do provedor do modelo e do ciclo de lançamento do seu aplicativo.

Lista de verificação de implementação

• Crie um registro de conector com campos de locatário, servidor, autorização, escopo, ferramenta, risco, retenção e revogação.
• Separe a identidade da chave do gateway, a identidade delegada do usuário final e a identidade do conector em todas as decisões políticas.
• Armazene tokens de conector em um cofre de credenciais, mas mantenha-os distintos das credenciais de tempo de execução do provedor de modelo.
• Prefira por usuário OAuth para conectores de dados do usuário; limitar tokens de serviço compartilhados a fluxos de trabalho explícitos de contas de serviço.
• Normalize as ações da ferramenta em leitura, gravação, envio, exclusão, exportação, financeiro, administrativo e desconhecido.
• Execute verificações pré-despacho para inscrição do conector, validade do token, correspondência de escopo, compatibilidade de retenção, estado de aprovação e reserva de orçamento.
• Registre as decisões do conector antes do envio e estabeleça o status final após resposta ou erro.
• Crie fluxos de trabalho de desconexão de usuário, desativação de locatário, quarentena de conector e lista de bloqueio de emergência.
• Teste metadados do conector, comportamento do token, desvio de ferramenta e metadados malformados antes do uso em produção.

Conclusão acionável

MCP e conectores de serviço tornam os agentes úteis porque permitem que os modelos atuem em sistemas reais. Essa mesma utilidade transforma a autorização do conector em uma preocupação do plano de controle, e não em um detalhe de engenharia imediata.

O gateway deve saber mais do que o modelo, a contagem de tokens e a API chave. Deve saber qual conector foi chamado, qual usuário o autorizou, quais escopos foram concedidos, qual classe de ação da ferramenta foi solicitada, se a aprovação foi necessária, se o limite de retenção era compatível e como o acesso pode ser revogado. Comece com um registro de conector, uma verificação de política pré-despacho e um livro-razão de auditoria associado. Em seguida, adicione OAuth corretagem, aprovações agrupadas, investigações de conformidade e quarentena de emergência à medida que o uso do conector aumenta.

O objetivo não é bloquear a adoção MCP remota. O objetivo é tornar o acesso ao conector atribuível, revogável, revisável e compatível com as mesmas expectativas de governança que as equipes já aplicam ao acesso ao modelo e um gateway OpenAIcompatível com API.

Leitura relacionada

• padrões mais amplos de governança da ferramenta de agente