Segurança da chave de API

Esta página documenta as práticas recomendadas para armazenar, rotacionar e revogar chaves de API do MCP da Cryptohopper. As orientações se aplicam a qualquer ambiente onde o MCP é usado — estações de trabalho locais, sistemas de CI, implantações de agentes e clientes MCP de terceiros.

O que uma chave MCP concede

Uma chave de API do MCP da Cryptohopper é um token portador que autentica solicitações contra uma única conta da Cryptohopper.

O que a chave pode fazer	O que a chave não pode fazer
Ler dados de mercado (tickers, livros de ofertas, velas) no nível permitido pelo plano	Acessar bots da Cryptohopper
Consultar uso e cota da conta	Realizar operações ou modificar posições
Listar corretoras e pares suportados	Acessar a interface da conta
—	Autorizar chamadas à API de negociação da Cryptohopper

As chaves são somente leitura. Uma chave MCP comprometida não permite que um invasor negocie. No entanto, ela permite o consumo de cota, o que pode interromper fluxos de trabalho legítimos.

Consulte a visão geral da conta para entender a relação entre chaves, conta e assinatura.

Armazenamento

As chaves devem ser tratadas como segredos. Práticas padrão de manipulação de segredos se aplicam.

Recomendado

• Armazene as chaves em um gerenciador de segredos dedicado (1Password, Bitwarden, AWS Secrets Manager, HashiCorp Vault ou equivalente).
• Leia as chaves de variáveis de ambiente em tempo de execução. Prefira variáveis de ambiente em vez de arquivos de configuração enviados ao controle de versão.
• Defina permissões de arquivo: arquivos de configuração de cliente contendo chaves devem ser legíveis apenas pelo usuário proprietário.
• Use arquivos de configuração por cliente (~/.config/...) em vez de localizações em todo o sistema.

Não recomendado

• Enviar chaves para repositórios git, mesmo em repositórios privados.
• Colar chaves em mensagens de chat, rastreadores de problemas ou conversas de suporte.
• Compartilhar chaves entre desenvolvedores ou máquinas. Crie uma chave por consumidor.
• Armazenar chaves em arquivos de texto simples em pastas sincronizadas na nuvem (por exemplo, Dropbox, iCloud Drive) sem criptografia adicional.

Se uma chave for acidentalmente enviada ao git, revogue-a imediatamente e gere uma nova. O histórico do git é durável e considerado comprometido.

Rotação

Rotacionar chaves — revogar uma chave antiga e emitir uma nova — é o mecanismo defensivo que limita o raio de impacto de um comprometimento.

Cadência sugerida

Contexto	Cadência de rotação
Estação de trabalho pessoal, cliente MCP local	A cada 90 dias
Fluxo de trabalho agendado em CI / nuvem	A cada 60 dias
Compartilhado entre vários ambientes	A cada 30 dias
Chave com qualquer histórico de exposição (enviada ao repositório, colada no chat, etc.)	Imediatamente, depois a cada 30 dias

A permissão de chaves do plano determina quantas chaves podem existir simultaneamente. Consulte os planos de assinatura.

Procedimento de rotação

1. Gere uma nova chave de API na interface da conta da Cryptohopper.
2. Implante a nova chave em todos os consumidores (clientes MCP, segredos de CI, configurações de agente).
3. Verifique se cada consumidor está usando a nova chave emitindo uma consulta de teste.
4. Revogue a chave antiga na interface da conta da Cryptohopper.

As chaves são independentes. Revogar uma não afeta as outras.

Segmentação de chaves

Quando o plano permite mais de uma chave (Adventurer: 3 chaves; Hero: 10 chaves), use-as para segmentar o uso.

Padrões de segmentação sugeridos

• Uma chave por agente. Cada agente de IA distinto recebe sua própria chave. Se um agente se comportar mal e consumir cota excessiva, ele pode ser identificado e limitado sem afetar os outros.
• Uma chave por ambiente. Chaves separadas para produção, preparação e desenvolvimento. Revogar ou rotacionar a chave de desenvolvimento deixa a produção intocada.
• Uma chave por usuário. Em uma equipe pequena, uma chave por membro da equipe fornece atribuição para uso de cota e permite revogação individual quando um membro da equipe sai.

Lembre-se de que todas as chaves compartilham a cota semanal única da conta. A segmentação é para atribuição, revogação e limitação — não para expansão de cota.

Revogação

Revogue uma chave quando:

• A chave foi exposta (enviada a um repositório, enviada por um canal não criptografado, presente em um dispositivo perdido ou roubado).
• Um consumidor não precisa mais de acesso (fluxo de trabalho desativado, membro da equipe que saiu).
• Como parte da rotação programada.

A revogação através da interface da conta da Cryptohopper entra em vigor imediatamente. Solicitações subsequentes usando a chave revogada retornam UNAUTHORIZED. Consulte a referência de erros.

Defesa em profundidade

Além da higiene básica:

• Restrições de rede. Se seu cliente MCP é executado em um ambiente fixo (executor de CI, servidor de produção), considere restringir o tráfego de saída especificamente para mcp-data.cryptohopper.com.
• Logs de auditoria. Mantenha logs locais de qual chave executou qual ação. Comparar padrões de uso do MCP com a telemetria de uso por conta da Cryptohopper ajuda a detectar anomalias.
• Monitore o uso. Um pico repentino no volume de chamadas é frequentemente o primeiro sinal de uma chave comprometida. Consulte uso e limites.
• Separe das credenciais da API de negociação. A API REST de negociação da Cryptohopper usa credenciais separadas. Não coloque as chaves MCP e as credenciais da API de negociação em um único arquivo não criptografado — um comprometimento de uma não deve implicar a outra.

Resposta a incidentes

Se houver suspeita de comprometimento de uma chave:

1. Revogue imediatamente. Não espere para confirmar. O custo de uma revogação desnecessária é pequeno; o custo de uma revogação atrasada é consumo de cota e — se a chave estiver pareada com credenciais da API de negociação no mesmo comprometimento — potencialmente mais.
2. Verifique o uso. Consulte o endpoint de uso para procurar padrões anômalos no ciclo atual. Documente qualquer coisa suspeita.
3. Revise a fonte da exposição. Entenda como a chave foi exposta. Uma chave vazada é frequentemente um sintoma de uma lacuna de controle mais ampla.
4. Rotacione credenciais adjacentes. Se o mesmo ambiente continha credenciais da API de negociação, rotacione-as também.
5. Gere uma nova chave e reimplante aos consumidores.