Cómo cuidamos tus claves y tu código
StrategyCheck todavía no tiene usuarios con cuenta: la beta privada abre el 28 de febrero de 2027. Por eso esta página separa tres cosas: lo que ya existe y se verificó, lo que está escrito pero se activa con las cuentas, y lo que no tenemos. Nunca guardamos la contraseña de tu broker, nunca podemos retirar tu dinero y tu código corre aislado y sin red. Cada afirmación lleva su etiqueta.
Hoy existe y se verificó. En construcción está escrito o diseñado, pero todavía no se usó con una cuenta de usuario. No tenemos no existe y no lo prometemos para una fecha, salvo que se diga.
Contenido
- Qué datos guardamos
- Tus claves de broker
- Tu código Python
- Sin custodia
- Un cliente no lee a otro
- Registro de decisiones que no se edita
- Dónde corre todo
- Qué no tenemos todavía
- Cómo reportar una vulnerabilidad
1. Qué datos guardamos
| Qué | Cuándo | Detalle |
|---|---|---|
| Lista de espera | Hoy | Tu email, el caso que elegiste (opcional), el idioma, desde qué sección del sitio te anotaste, la fecha y un ip_hash: un resumen irreversible de tu dirección IP (SHA-256 de la IP, el día y una sal, truncado). Cambia cada día y no permite recuperar la IP. La tabla acepta altas desde el sitio, pero el navegador no puede leerla. Detalle en Privacidad. |
| Estado público del motor | Hoy | La página Estado muestra solo hechos agregados de la cuenta de prueba del propio producto: cantidades, fechas y veredicto. No muestra dinero, posiciones ni precios. |
| Tu cuenta | En construcción (beta) | Email de la cuenta, tus estrategias (la regla o el código) y sus versiones, y las operaciones y órdenes en paper con el registro de cada decisión. |
| Lo que no guardamos | Hoy | La contraseña de tu broker, en ningún caso. Datos de tarjeta: hoy no se cobra nada; cuando exista el cobro lo procesará un tercero (Paddle) y los datos de tarjeta no pasarán por nuestros servidores. |
2. Tus claves de broker En construcción
Con Alpaca la conexión es por OAuth: autorizás desde el sitio de Alpaca y StrategyCheck recibe un token con permiso de trading y datos. Nunca recibe ni pide tu contraseña. Con Interactive Brokers, a través del puente de código abierto, las credenciales quedan en tu máquina y no guardamos nada del broker.
- Cifrado en reposo. El token se guarda en Supabase Vault, cifrado. La tabla de conexiones guarda solo el identificador del secreto, no el secreto.
- Quién lo lee. Solo el gateway de ejecución, con funciones de servidor que únicamente puede ejecutar el rol de servicio. El panel (usuarios autenticados) y el público no pueden ejecutarlas: algunas de las 58 pruebas automáticas de la sección 5 lo verifican. El runtime de tu estrategia nunca ve el token.
- Revocable. Podés revocar el permiso cuando quieras desde tu cuenta de Alpaca; el token deja de servir.
Qué falta: la bóveda y las funciones de lectura están aplicadas en la base desde el 29 de octubre de 2026, pero el flujo OAuth con Alpaca todavía no está conectado. Hoy no guardamos ninguna clave de ningún usuario, porque todavía no hay cuentas.
3. Tu código Python En construcción
- Aislado y sin red. Tu script corre en un proceso aparte, dentro de un contenedor sin red, con el sistema de archivos de solo lectura. Su único canal es un socket local hacia el gateway: entran barras de precios, salen intenciones (no órdenes). No puede abrir conexiones, ni leer la base de datos, ni ver ninguna clave.
- Con límites. CPU, memoria y tiempo por ciclo acotados. Si un ciclo pasa el tiempo, el gateway mata el proceso, el ciclo falla y se registra.
- Revisado antes. Un validador comprueba sintaxis, dependencias permitidas, mirada al futuro y tiempo por ciclo antes de aceptar una versión. El validador no es la barrera de seguridad: la barrera es el contenedor.
- No se comparte ni se usa para entrenar. No entrenamos ningún modelo con tu código y no lo compartimos con otros usuarios. Tampoco hay un modelo de lenguaje en el lazo de ejecución: ninguno decide una orden.
Qué está hecho y qué no: el protocolo entre el gateway y el sandbox, el corte por tiempo y el validador están escritos y tienen pruebas automáticas, pero esas pruebas corren el sandbox como un proceso común. El contenedor con gVisor y sin red todavía no se probó en un servidor real; se mide antes de la beta. Hasta entonces no corre código de ningún usuario.
4. Sin custodia Hoy
No tenemos cuentas de broker ni bancarias a tu nombre ni permiso para retirar o transferir tu dinero. Tu dinero está siempre en tu broker. Con el permiso de trading, el sistema puede enviar órdenes a tu cuenta (es lo que le pedís que haga), y siempre pasan por límites de riesgo que ningún texto puede pisar. En la beta ni siquiera existe operar en real: solo paper. Operar en real, cuando exista, es una decisión tuya y depende de una aprobación de Alpaca que todavía no tenemos.
5. Un cliente no lee a otro Hoy
Cada fila de datos de cliente lleva su identificador de cliente (tenant_id) y la base aplica seguridad por fila (RLS, row level security): la política toma el cliente de un dato del usuario que él no puede editar, no de uno que sí. Hay 58 pruebas automáticas que lo comprueban; la última corrida fue el en el proyecto de Supabase del producto y pasaron 58 de 58. Verifican, entre otras cosas, que:
- un usuario no lee filas de otro cliente;
- un dato editable por el propio usuario no da acceso a nada;
- el público sin sesión no lee nada;
- un usuario autenticado no puede escribir directamente;
- el panel y el público no ejecutan las funciones que leen secretos.
Límite: las pruebas cubren las tablas principales (operaciones, eventos, estrategias, resúmenes diarios, cuentas y algunas más). El resto de las tablas con identificador de cliente usa la misma plantilla de políticas, pero todavía sin prueba propia. Y hoy hay un solo cliente real: el tenant de prueba del propio producto.
6. Registro de decisiones que no se edita Hoy
Los eventos, las intenciones, las verificaciones de riesgo, los fills y las operaciones cerradas se guardan en tablas de solo agregar: la base rechaza UPDATE y DELETE, incluso para el rol de servicio. Las versiones de estrategia y los límites de riesgo también son inmutables: cambiarlos crea una versión nueva. Cada decisión guarda el hash de los datos que la produjeron (barras, posiciones, parámetros, versión), y se puede reproducir con los mismos datos para comprobar que da lo mismo.
Límite: es una protección de la base, no una auditoría de terceros. No sellamos el registro con un servicio externo ni lo firmamos: quien administre la base podría, en teoría, desactivar la protección. Por eso el hash y la reproducción: si algo cambiara, no coincidiría.
7. Dónde corre todo
- Supabase (base de datos Postgres, autenticación, bóveda de secretos): región de Frankfurt, Alemania (el pooler del proyecto es aws-1-eu-central-1). Plan Free: Supabase conserva copias diarias de la base.
- Hetzner (servidor donde corre el gateway de ejecución y el motor): centro de datos en la Unión Europea.
- Cloudflare (sitio, DNS y las funciones del formulario): entrega el sitio solo por HTTPS, con HSTS y cabeceras de seguridad (CSP, X-Frame-Options, nosniff).
- Alpaca: datos de mercado y, cuando conectes tu cuenta, el broker.
Los subprocesadores y sus funciones están en Privacidad. Todavía no probamos una restauración completa desde copia de seguridad.
8. Qué no tenemos todavía
| Qué | Estado | Fecha |
|---|---|---|
| Segundo factor (2FA) en el panel | No tenemos | Estimada: antes de la beta (28 de febrero de 2027) |
| SOC 2 (u otra certificación) | No tenemos | Sin fecha |
| Auditoría de seguridad externa / prueba de penetración | No tenemos | Sin fecha |
| Programa de recompensas (bug bounty) | No tenemos | Sin fecha. Sí recibimos reportes (sección 9), sin recompensa |
| Sellado externo del registro de decisiones | No tenemos | Sin fecha |
| Sandbox de código probado en un servidor real | En construcción | Antes de la beta |
Mientras tanto, lo que sí hay son controles técnicos concretos (secciones 2 a 7) y pruebas automáticas. No son lo mismo que una certificación de un tercero, y esta página no lo presenta como tal.
9. Cómo reportar una vulnerabilidad
Escribí a [email protected] con el asunto «Seguridad». Contanos qué encontraste y cómo reproducirlo. Respondemos dentro de las 72 horas. Te pedimos investigar de buena fe: sin acceder a datos de otras personas, sin degradar el servicio y sin publicar el detalle antes de que lo hayamos corregido. No ofrecemos recompensa; si querés, te nombramos como quien lo reportó.
Esta página describe controles técnicos de software. No es una garantía de resultado ni un compromiso contractual: los términos están en Términos. StrategyCheck no es asesor de inversiones.