Antes de autorizar um conector remoto no Claude, confirme quem controla o endereço do servidor, compare a URL com a documentação do fornecedor e confira o domínio de cada tela de autenticação. Depois, revise as permissões solicitadas e faça o primeiro teste com dados fictícios. Um nome conhecido ou um logotipo familiar não substitui essa conferência.
O objetivo é decidir se aquele destino específico pode receber dados e executar ações em nome da empresa. Este é um roteiro de revisão operacional, não um anúncio de recurso nem uma garantia de segurança. A autorização só deve avançar quando houver uma explicação verificável para o endereço, o responsável e o acesso solicitado.
Resumo rápido
- Obtenha a URL na documentação oficial ou com um administrador identificado.
- Leia o hostname inteiro, inclusive o final do domínio.
- Diferencie servidor MCP, serviço de login e endereço de retorno.
- Conceda apenas o acesso necessário à tarefa inicial.
- Teste com uma conta restrita e registre como revogar a conexão.
O que você está autorizando ao conectar um servidor remoto
Um conector é uma ponte entre o Claude e outro sistema. MCP, sigla de Model Context Protocol, organiza essa comunicação entre aplicações de IA, ferramentas e fontes de dados. O servidor remoto é o componente que atende pela internet. Para entender os elementos dessa ponte, consulte nosso guia de MCP.
A documentação da Anthropic esclarece que conectores personalizados podem acessar serviços que não foram verificados pela empresa. Também informa que a conexão com o servidor remoto parte da infraestrutura de nuvem da Anthropic. Portanto, o servidor não recebe apenas uma visita do navegador da pessoa que fez a configuração. Veja a documentação de conectores personalizados.
Há pelo menos três responsabilidades a identificar: quem fornece o Claude, quem opera o servidor MCP e quem guarda os dados consultados. Às vezes o operador do conector e o fornecedor do sistema de origem são empresas diferentes. Registre essa diferença antes de permitir que contratos, mensagens ou informações comerciais atravessem a integração.
Escreva uma frase objetiva para a tarefa: consultar o status de pedidos, localizar documentos de uma pasta ou preparar um rascunho. Essa frase será o critério para avaliar a necessidade de cada permissão. Se o propósito ainda é amplo demais para caber em uma frase, o pedido de autorização provavelmente precisa ser detalhado.
Como conferir a URL e identificar o domínio correto
Comece fora da mensagem que trouxe o convite. Abra o site do fornecedor por um favorito já conhecido ou pelo endereço registrado no contrato. Procure a documentação da integração a partir dali. Compare o endereço completo com aquele recebido. Quando o conector é interno, peça ao responsável técnico a configuração aprovada por um canal corporativo conhecido.
Em https://mcp.exemplo.com.br/servidor, o hostname é mcp.exemplo.com.br, e /servidor é o caminho. O nome da empresa dentro do caminho não prova quem controla o destino. Em https://exemplo.com.br.outro.example/mcp, o endereço termina em outro.example. Os endereços deste parágrafo são apenas exemplos de leitura, não recomendações de conexão.
Expanda a barra de endereço e procure trocas discretas de letras, hífens extras, finais diferentes e caracteres que se parecem com os do domínio esperado. Não tente deduzir a legitimidade por semelhança visual. Se o nome está estranho ou abreviado, compare com a documentação e peça confirmação ao fornecedor por um contato que você já possuía.
HTTPS protege o transporte quando a conexão e o certificado são válidos. Isso não demonstra que o operador tem relação com a empresa que aparece no logotipo. Um domínio indevido também pode usar HTTPS. Na prática, avalie duas perguntas separadas: a conexão está protegida e o destinatário é realmente o operador aprovado?
Não cole endereços com parâmetros de autenticação em verificadores públicos, chamados abertos ou conversas de grupo. Uma URL pode carregar informações de sessão. Para pedir ajuda, compartilhe inicialmente o hostname e a descrição do problema; envie detalhes adicionais por um canal restrito e após remover segredos.
Como revisar login, redirecionamentos e permissões
Um fluxo legítimo pode passar por mais de um domínio. OAuth é um mecanismo de autorização que permite conceder acesso sem entregar a senha do serviço a cada aplicativo. O servidor MCP pode usar um provedor de identidade separado. Essa diferença exige uma explicação documentada, não uma reprovação automática nem uma aprovação por costume.
A especificação de autorização do MCP distingue o servidor que fornece o recurso e o servidor de autorização. Para quem administra a integração, isso ajuda a verificar se o destino de login faz parte da arquitetura esperada. Para quem só utiliza a ferramenta, a regra prática é confirmar o provedor de login com o responsável antes de informar credenciais.
| Elemento | O que verificar | Quando interromper |
|---|---|---|
| URL do conector | Correspondência com a configuração aprovada | Endereço recebido sem origem verificável |
| Tela de login | Domínio do provedor de identidade documentado | Pedido de senha em um domínio desconhecido |
| Aplicativo solicitante | Nome, operador e finalidade compatíveis | Outro produto aparece sem explicação |
| Permissões | Recursos e ações necessários à tarefa | Acesso amplo sem justificativa |
| Conta conectada | Ambiente e usuário corretos | Conta pessoal ou cliente errado |
Leia os verbos da autorização: consultar, criar, editar, excluir e administrar têm consequências distintas. Uma tarefa de pesquisa não justifica automaticamente modificar cadastros. Quando a interface permitir escolher pastas, espaços ou recursos, selecione o conjunto mínimo. Quando não permitir, avalie uma conta com acesso reduzido no sistema de origem.
Registre o que a tela realmente mostrou, sem copiar tokens ou senhas. Se houver discrepância entre a documentação e a autorização, não resolva com uma suposição. Peça a explicação e volte à configuração depois. Nosso conteúdo sobre permissões para agentes de IA ajuda a transformar essa revisão em uma política da equipe.
O que pedir ao administrador antes do primeiro teste
Solicite uma ficha curta: URL aprovada, operador, serviço de autenticação, finalidade, tipos de dados envolvidos, recursos permitidos e contato para incidentes. Acrescente como desconectar a integração e onde revisar o acesso no serviço de origem. Uma resposta que apenas repete o nome comercial não resolve a identificação do destino.
Para a equipe técnica, a revisão deve incluir a validação dos destinatários de tokens e dos endereços usados no fluxo de autorização. As boas práticas de segurança do MCP tratam de ameaças que ultrapassam a aparência da tela. A leitura técnica complementa a conferência humana; não transforma qualquer servidor compatível em um servidor confiável.
Combine previamente os critérios de aprovação. Um teste útil tem uma tarefa delimitada, um resultado esperado e uma forma de verificar que nada além dela ocorreu. Por exemplo, localizar um documento fictício em uma pasta de treinamento. Um teste vago, como pedir ao agente para organizar toda a operação, não ajuda a distinguir o comportamento esperado do acesso excessivo.
Também pergunte onde ficam os registros operacionais e quem consegue consultá-los. Nem todo produto oferece o mesmo detalhe de auditoria. Se não houver registro suficiente, use um ambiente de teste ainda mais restrito e reduza o escopo da experiência. Não prometa rastreabilidade que o fornecedor não demonstrou.
Exemplo: uma agência de Curitiba revisa um conector de CRM
Imagine uma agência de marketing de Curitiba que quer consultar oportunidades do CRM pelo Claude. O caso é ilustrativo. Um integrante recebe uma URL por mensagem e propõe conectar sua conta administrativa. A gestora decide separar a análise do endereço da discussão sobre produtividade.
Primeiro, a agência abre a documentação do fornecedor a partir do site já usado pela equipe. O responsável técnico confirma o hostname do servidor e explica que a autenticação acontece no provedor de identidade contratado. A equipe registra os dois domínios e a origem da confirmação, sem guardar os parâmetros temporários do login.
Depois, define que o teste poderá consultar apenas oportunidades fictícias em um espaço de treinamento. O usuário de teste não administra o CRM e não acessa carteiras reais. Na tela de consentimento, a pessoa compara as permissões com essa finalidade. Se aparecer uma exigência de administração sem justificativa, o teste para até a revisão do fornecedor.
Durante o teste, a equipe pede a localização de um cadastro fictício e confere o resultado diretamente no CRM. Depois desconecta a integração e revisa o acesso no serviço de origem. Só com esses passos registrados considera levar o uso para dados reais. O exemplo não presume economia de tempo, ganho comercial ou ausência de risco.
A documentação da Anthropic diferencia conectores remotos de extensões locais. Esse ponto evita que a agência procure uma configuração de rede no lugar errado. Consulte quando usar conectores web e de desktop e acompanhe a página de integrações do Anthropic Claude para contexto sobre os tipos de conexão.
Erros comuns
Aprovar porque o logotipo é conhecido. Nome e imagem são sinais visuais, não uma comprovação do endereço configurado. Compare a URL com a origem aprovada e verifique quem opera o servidor. Uma aparência familiar não resolve uma divergência no domínio.
Usar a conta mais poderosa para evitar dificuldades. Esse atalho torna o teste menos informativo e amplia as consequências de uma ação inesperada. Comece com acesso restrito e aumente apenas o que for necessário para uma tarefa já definida.
Conferir só a primeira página. O endereço inicial pode estar correto e o login seguir para outro provedor. Revise a sequência e peça documentação para os destinos inesperados. Não informe credenciais durante uma investigação ainda inconclusiva.
Tratar compatibilidade como aprovação de segurança. MCP descreve uma forma de comunicação. O protocolo não substitui a avaliação do operador, da política de dados e das ferramentas expostas. O servidor pode funcionar corretamente e ainda oferecer acesso inadequado para sua necessidade.
Guardar segredos no relatório de revisão. A ficha deve documentar decisões e responsáveis. Não precisa conter senhas, chaves ou capturas com informações de sessão. Restrinja também as evidências que revelem nomes de clientes e detalhes internos.
Perguntas frequentes
Todo conector remoto precisa estar em um domínio da Anthropic?
Não. O servidor pode ser operado por outra organização. O ponto é confirmar que o domínio pertence ao operador aprovado e corresponde à documentação daquela integração. Um endereço fora da Anthropic precisa de identificação, assim como qualquer outro destinatário de dados.
Se o endereço usa HTTPS, posso autorizar?
HTTPS é uma condição de proteção do transporte, não uma avaliação completa de confiança. Verifique também o operador, a finalidade, a conta conectada e as permissões. Se um desses pontos estiver indefinido, interrompa a autorização até esclarecer.
Um domínio de login diferente significa fraude?
Não necessariamente. Pode ser um provedor de identidade legítimo. A diferença deve estar prevista na documentação ou ser confirmada pelo administrador por um canal conhecido. Não aceite uma explicação fornecida apenas pela própria página suspeita.
Posso pedir ao Claude que aprove o conector por mim?
Você pode usar IA para organizar a lista de verificação e explicar termos. A decisão precisa de evidências externas, identificação do responsável e revisão humana do acesso. A resposta do modelo não comprova quem controla um domínio.
O que fazer depois de autorizar um endereço errado?
Interrompa o uso, desconecte o conector e revise autorizações no serviço de origem. Acione o responsável por segurança com as evidências disponíveis, sem expor segredos em canais abertos. A necessidade de trocar credenciais ou tomar outras medidas depende do que foi concedido e compartilhado.
