Seguridad de clave API

Esta página documenta prácticas recomendadas para almacenar, rotar y revocar claves API de MCP de Cryptohopper. Los consejos se aplican a cualquier entorno donde se use el MCP — estaciones de trabajo locales, sistemas CI, despliegues de agentes y clientes MCP de terceros.

Qué otorga una clave MCP

Una clave API de MCP de Cryptohopper es un token portador que autentica solicitudes contra una única cuenta de Cryptohopper.

Qué puede hacer la clave	Qué no puede hacer la clave
Leer datos de mercado (tickers, libros de órdenes, velas) al nivel permitido del nivel	Acceder a bots de Cryptohopper
Consultar uso y cuota para la cuenta	Colocar trades o modificar posiciones
Listar exchanges y pares compatibles	Acceder a la interfaz de cuenta
—	Autorizar llamadas de la API de Trading de Cryptohopper

Las claves son de solo lectura. Una clave MCP comprometida no permite a un atacante hacer trading. Sin embargo, sí permite consumo de cuota, lo cual puede interrumpir flujos de trabajo legítimos.

Consulta la descripción general de la cuenta para conocer la relación entre claves, cuenta y suscripción.

Almacenamiento

Las claves deben tratarse como secretos. Se aplican prácticas estándar de manejo de secretos.

Recomendado

• Almacena las claves en un administrador de secretos dedicado (1Password, Bitwarden, AWS Secrets Manager, HashiCorp Vault o equivalente).
• Lee las claves desde variables de entorno en tiempo de ejecución. Prefiere variables de entorno sobre archivos de configuración confirmados en control de código fuente.
• Delimita permisos de archivo: los archivos de configuración del cliente que contengan claves deben ser legibles solo por el usuario propietario.
• Usa archivos de configuración por cliente (~/.config/...) en lugar de ubicaciones de todo el sistema.

No recomendado

• Confirmar claves en repositorios git, incluso en repositorios privados.
• Pegar claves en mensajes de chat, rastreadores de problemas o conversaciones de soporte.
• Compartir claves entre desarrolladores o máquinas. Crea una clave por consumidor en su lugar.
• Almacenar claves en archivos de texto plano en carpetas sincronizadas en la nube (ej. Dropbox, iCloud Drive) sin cifrado adicional.

Si una clave se confirma accidentalmente en git, revócala inmediatamente y genera una nueva. El historial de git es duradero y se asume comprometido.

Rotación

Rotar claves — revocar una clave antigua y emitir una nueva — es el mecanismo defensivo que limita el radio de explosión de un compromiso.

Cadencia sugerida

Contexto	Cadencia de rotación
Estación de trabajo personal, cliente MCP local	Cada 90 días
Flujo de trabajo programado en CI / nube	Cada 60 días
Compartida entre múltiples entornos	Cada 30 días
Clave con cualquier historial de exposición (confirmada en repo, pegada en chat, etc.)	Inmediatamente, luego cada 30 días

La asignación de claves del nivel determina cuántas claves pueden existir simultáneamente. Consulta niveles de suscripción.

Procedimiento de rotación

1. Genera una nueva clave api en la interfaz de cuenta de Cryptohopper.
2. Despliega la nueva clave a todos los consumidores (clientes MCP, secretos CI, configuraciones de agentes).
3. Verifica que cada consumidor esté usando la nueva clave emitiendo una consulta de prueba.
4. Revoca la clave antigua desde la interfaz de cuenta de Cryptohopper.

Las claves son independientes. Revocar una no afecta a las demás.

Segmentación de claves

Donde el nivel permite más de una clave (Adventurer: 3 claves; Hero: 10 claves), úsalas para segmentar el uso.

Patrones de segmentación sugeridos

• Una clave por agente. Cada agente de IA distinto obtiene su propia clave. Si un agente se comporta mal y consume cuota excesiva, puede ser identificado y limitado sin afectar a los demás.
• Una clave por entorno. Claves separadas para producción, staging y desarrollo. Revocar o rotar la clave de desarrollo deja la producción intacta.
• Una clave por usuario. En un equipo pequeño, una clave por miembro del equipo proporciona atribución para uso de cuota y permite revocación individual cuando un miembro del equipo se va.

Recuerda que todas las claves comparten la cuota semanal única de la cuenta. La segmentación es para atribución, revocación y limitación — no para expansión de cuota.

Revocación

Revoca una clave cuando:

• La clave ha sido expuesta (confirmada en un repositorio, enviada por un canal no cifrado, presente en un dispositivo perdido o robado).
• Un consumidor ya no necesita acceso (flujo de trabajo desmantelado, miembro del equipo que se fue).
• Como parte de rotación programada.

La revocación a través de la interfaz de cuenta de Cryptohopper surte efecto inmediatamente. Las solicitudes posteriores usando la clave revocada devuelven UNAUTHORIZED. Consulta la referencia de errores.

Defensa en profundidad

Más allá de la higiene básica:

• Restricciones de red. Si tu cliente MCP se ejecuta en un entorno fijo (ejecutor CI, servidor de producción), considera restringir el tráfico saliente específicamente a mcp-data.cryptohopper.com.
• Registros de auditoría. Mantén registros locales de qué clave realizó qué acción. Comparar patrones de uso de MCP contra la telemetría de uso por cuenta de Cryptohopper ayuda a detectar anomalías.
• Monitorear uso. Un pico repentino en el volumen de llamadas a menudo es la primera señal de una clave comprometida. Consulta uso y límites.
• Separar de credenciales de la API de Trading. La API REST de Trading de Cryptohopper usa credenciales separadas. No co-localices claves MCP y credenciales de la API de Trading en un solo archivo sin cifrar — un compromiso de una no debe implicar a la otra.

Respuesta a incidentes

Si se sospecha que una clave está comprometida:

1. Revoca inmediatamente. No esperes a confirmar. El costo de una revocación innecesaria es menor; el costo de una revocación retrasada es consumo de cuota, y — si la clave está emparejada con credenciales de la API de Trading en el mismo compromiso — potencialmente más.
2. Verifica el uso. Consulta el endpoint de uso para buscar patrones anómalos en el ciclo actual. Documenta cualquier cosa sospechosa.
3. Revisa la fuente de exposición. Comprende cómo se expuso la clave. Una clave filtrada a menudo es un síntoma de una brecha de control más amplia.
4. Rota credenciales adyacentes. Si el mismo entorno contenía credenciales de la API de Trading, rota esas también.
5. Genera una nueva clave y redespliega a los consumidores.