Este Resumen de Seguridad describe las medidas técnicas y organizativas que Melaya Labs LLC ("Melaya") aplica actualmente para proteger la confidencialidad, integridad y disponibilidad de la plataforma Melaya. Está pensado para dar a los usuarios potenciales y existentes, a los compradores empresariales y a los auditores una imagen honesta de lo que está hoy en producción, lo que está en curso y lo que aún no está implementado. Cuando una capacidad es aspiracional o está en curso, se marca explícitamente como tal en lugar de ocultarse tras un lenguaje vago. La seguridad es una responsabilidad compartida: Melaya es responsable de la seguridad de la plataforma, y los clientes son responsables de la seguridad de lo que construyen, cargan y ejecutan sobre ella.
1. Cifrado en Tránsito y en Reposo
Todos los datos en tránsito entre los clientes de usuarios y los Servicios están protegidos mediante Transport Layer Security (TLS) versión 1.2 o superior, con terminación en Cloudflare en el perímetro del despliegue. El perfil de TLS en producción sigue la guía de compatibilidad intermedia de Mozilla: únicamente TLS 1.2 y 1.3, únicamente suites de cifrado ECDHE, únicamente cifrados AEAD con secreto hacia adelante, HSTS con un max-age de dos años y la directiva preload, y una Content Security Policy estricta con una lista de permitidos explícita para connect-src. La Content Security Policy se aplica en ambas superficies: el servidor de la API establece default-src 'none' a través de su middleware de encabezados de seguridad, y la aplicación web pública incluye una política que permite los dominios propios, los proveedores de pago e inicio de sesión, bloquea el contenido de complementos y el secuestro mediante base-tag o form-action, y restringe la ejecución de scripts, de modo que un script inyectado no pueda exfiltrar datos hacia un origen atacante. El perfil completo de TLS, la lista de cifrados confirmados y la cadencia de revisión trimestral están documentados en el runbook TLS Baseline en el vault de seguridad interno. Las llamadas internas entre servicios dentro de nuestra infraestructura se realizan a través de loopback o enlaces de red privada.
El cifrado en reposo está implementado actualmente en la capa de aplicación mediante cifrado de sobre a nivel de campo. El cifrado de disco completo en la capa de almacenamiento aún no está habilitado: los dispositivos de bloque en producción no están cifrados a nivel de disco en este momento. El cifrado a nivel de volumen mediante LUKS ha sido seleccionado como la vía de remediación y es un elemento comprometido en el roadmap de seguridad. Hasta que se ejecute, Melaya NO representa el cifrado a nivel de disco ni el cifrado de volumen administrado por el proveedor como un control activo.
Los valores sensibles están protegidos por una capa de cifrado de sobre a nivel de aplicación implementada en nuestro servicio de cifrado de sobre. Las credenciales de API de exchange (clave, secreto, frase de contraseña), las credenciales de conector por usuario y los tokens OAuth, y los secretos MFA y los códigos de recuperación se envuelven con AES-256-GCM utilizando una clave maestra de 256 bits que se mantiene únicamente en el proceso del servidor antes de ser enviados al proveedor del vault Infisical o escritos en la tabla de respaldo agents.credentials. El formato de wire lleva un identificador de clave explícito (v1:<kid>:<base64(iv|ciphertext|tag)>) para que el servidor pueda aceptar múltiples claves válidas durante una ventana de rotación y enrutar las lecturas a la clave exacta que envolvió cada valor. Las nuevas escrituras siempre utilizan la clave activa, que es la primera entrada en la lista de claves configuradas. La rotación es un procedimiento de tres versiones que nunca detiene la plataforma: agregar la nueva clave como segunda entrada (las escrituras siguen yendo a la clave antigua, la nueva clave es de solo lectura), promoverla al primer lugar (las escrituras pasan a la nueva clave, la clave antigua permanece legible), re-envolver las filas históricas vinculadas al identificador de clave retirado y luego eliminar la entrada anterior. Ni Infisical ni el host de Postgres ven credenciales en texto plano en ningún momento: un compromiso de cualquiera de los dos subprocesadores de forma aislada produce únicamente texto cifrado, y el atacante además necesita una clave de sobre configurada para recuperar cualquier clave de exchange. Un script de migración puntual gestionó las filas en texto plano heredadas anteriores a la existencia de la capa de sobre. El barrido se completó contra la base de datos de producción y su verificador de ida y vuelta (envelope-verify.ts, 7/7 escenarios) finaliza con cero en cada ejecución de CI y contra producción en vivo.
2. Aislamiento de entorno de cliente y Pipeline
La plataforma aplica aislamiento lógico entre inquilinos en la capa de aplicación. Cada solicitud autenticada lleva un identificador de usuario derivado de un JSON Web Token validado, y cada consulta a la base de datos, acceso al almacén de objetos y búsqueda en el índice de recuperación tiene como alcance dicho identificador mediante SQL parametrizado y la canalización del contexto tRPC. Los índices de recuperación creados para el Marco Agéntico se almacenan por pipeline y solo se devuelven a consultas originadas desde el pipeline propietario. El estado del motor, las configuraciones de estrategia y los historiales de órdenes están igualmente particionados por usuario. La seguridad a nivel de fila de Postgres se aplica como capa de defensa en profundidad tras el alcance de la capa de aplicación: FORCE ROW LEVEL SECURITY está activo en producción en 44 tablas de los esquemas agents.* y cex.* bajo 117 políticas de seguridad a nivel de fila, y la aplicación se conecta bajo un rol de bajo privilegio dedicado que ejecuta NOBYPASSRLS y por tanto no puede ver datos de otros inquilinos aunque una consulta olvide accidentalmente su cláusula WHERE user_id. El contexto de seguridad a nivel de fila por solicitud establece el identificador del inquilino y el rol como parámetros de sesión antes de que se ejecute cualquier consulta, y el grupo de conexiones emite DISCARD ALL al liberarse para que el contexto no pueda trasladarse entre inquilinos. Diecisiete escenarios entre inquilinos en nuestro verificador rls-verify.ts salen con cero errores frente a la base de datos en producción en cada ejecución de CI, incluyendo casos de SELECT, INSERT, UPDATE, DELETE, reasignación de propiedad, omisión de administrador, fila cero sin contexto y regresión de filtración de contexto.
3. Gestión de claves y secretos
Los secretos de la aplicación, las claves de firma, las credenciales de base de datos y las claves de API de terceros utilizadas por Melaya se almacenan en un archivo de secretos controlado por el operador que se carga al inicio del proceso y en nuestro proveedor de vault. Nunca se confirman en el control de código fuente y los valores de producción no se comparten entre desarrolladores. La clave de cifrado de sobre es una clave de cifrado dedicada que se mantiene únicamente en el almacén de secretos del operador, separada de las credenciales de la base de datos Postgres y separada del token del vault de Infisical, de modo que el compromiso de cualquiera de los tres por separado no revela las credenciales de exchange en texto plano. Se recomienda encarecidamente a los clientes que limiten cada clave de API de exchange únicamente a permisos de trading, que deshabiliten los retiros en el venue emisor y que apliquen listas de permitidos de IP donde el venue lo permita.
Los tokens de sesión están firmados bajo una ventana de rotación de múltiples claves. El servidor acepta un conjunto ordenado de claves de firma, cada una etiquetada con un identificador de clave corto. Los nuevos tokens se firman bajo la primera clave (activa) y llevan ese identificador en el encabezado del JWT para verificación en O(1). Los tokens emitidos bajo cualquier clave retirada en la ventana continúan verificándose hasta que transcurra su TTL de siete días, momento en el que la clave retirada puede eliminarse. Los tokens vencidos se rechazan de inmediato aunque una clave no activa de otro modo los aceptaría. Los viajes de ida y vuelta de verificación están comprobados en nuestro verificador jwt-keys-verify.ts.
4. Autenticación y Control de Acceso
La autenticación de usuarios se basa en email y contraseña con hashing bcrypt en factor de trabajo 12, combinado con limitación de tasa en los endpoints de inicio de sesión, registro y recuperación de contraseña (20 intentos por IP por cada 15 minutos, aplicado por un limitador distribuido respaldado por Redis). Los tokens de sesión se emiten como JSON Web Tokens con un vencimiento de siete días y están vinculados a las reclamaciones de usuario, rol y tier. El control de acceso basado en roles distingue user de admin, y el control de acceso basado en tier limita las funciones según el catálogo de cuatro tiers. Cada acción de consecuencia se verifica en el lado del servidor; los controles del lado del cliente son únicamente una indicación de UX y nunca se utilizan como base para la seguridad.
La autenticación de dos factores está disponible para todos los usuarios mediante el perfil estándar TOTP (RFC 6238, SHA-1, 6 dígitos, período de 30 segundos, desviación de ±1 ventana) y es compatible con todas las aplicaciones de autenticación principales. Los secretos compartidos TOTP se generan en el lado del servidor con 160 bits de entropía, se envuelven a través de la capa de cifrado de sobre descrita en la sección 1, y se almacenan en una columna envuelta en la fila del usuario. Los códigos de recuperación se generan una vez al momento de la inscripción, se procesan con bcrypt en factor de trabajo 12, y luego se envuelven una segunda vez por la capa de sobre, de modo que un compromiso de la base de datos por sí solo no puede recuperarlos. La inscripción es un proceso de dos pasos que requiere que el usuario demuestre que ha configurado su autenticador ingresando un código en vivo antes de que el segundo factor se marque como activo. El flujo de inicio de sesión se convierte en una verificación de contraseña, luego un token de desafío de corta duración (cinco minutos), luego una verificación de código que consume de forma atómica la fila del desafío; un token de desafío capturado no puede reproducirse después de un consumo exitoso. MFA es obligatorio para agregar credenciales de API CEX y para generar claves de API de la plataforma, las dos acciones de mayor impacto en la interacción con fondos del producto. Cada resultado de desafío MFA (mfa.challenge_issued, mfa.challenge_ok, mfa.challenge_fail) se escribe en el registro de auditoría de solo adición descrito en la sección 6 para que los patrones de desafíos sean auditables y resistentes a alteraciones.
El acceso de los empleados de Melaya a los sistemas de producción se concede por ingeniero bajo un flujo de trabajo documentado de aprobación por dos personas y se revoca cuando ya no es necesario. El aprovisionamiento de acceso requiere aprobación de alguien distinto al solicitante, y la baja desactiva la cuenta, rota las claves de firma JWT para invalidar las sesiones activas, revoca las claves de API y elimina las claves SSH. Las entradas de sudoers con privilegios obsoletos y las claves autorizadas SSH se eliminan de forma sesión por sesión, y una cadencia de revisión de acceso trimestral está documentada. Una separación completa entre el usuario de despliegue y el usuario del runtime del servicio (para que un proceso de servicio comprometido no pueda pivotar hacia la ruta de despliegue) está registrada como un control planificado en el roadmap de seguridad.
5. Rate Limiting de Red e Infraestructura
La limitación de tasa se aplica en la capa de aplicación mediante un almacén compartido respaldado por Redis para que los límites sean globales en todas las instancias del servidor en lugar de por proceso. Se aplican dos cubos configurados de forma independiente: un cubo estricto en los endpoints de autenticación (20 intentos por IP por ventana de 15 minutos) y un cubo general de API (200 solicitudes por IP por minuto). El limitador es fail-closed: si el almacén Redis no está disponible, los endpoints de autenticación deniegan en lugar de dejar pasar. El wrapper del limitador con reconocimiento de lotes de tRPC está verificado por nuestro verificador rate-limit-verify.ts (7/7 escenarios, incluido el ataque de lavado por lotes).
El tráfico de borde está gestionado por Cloudflare con WAF, detección de bots y bloqueo geográfico en rutas de alto riesgo. Un scaffold de Terraform para la zona de Cloudflare está confirmado junto con un runbook operativo que cubre la detección de desviaciones, la anulación de emergencia y la regla de reconciliación de 24 horas. La importación y reconciliación de la zona actualmente manual con ese scaffold está en curso y es la tarea de bloqueo antes de que se programe la primera prueba de penetración externa.
6. Monitoreo, Logging y Auditoría
La plataforma emite registros estructurados desde el servidor tRPC de Node.js, el Motor Rust, el worker de Python y el borde. Todos los registros a nivel de servidor y de contenedor (el diario de systemd, los registros del sistema del servidor, los registros de acceso y error de nginx, la salida estándar de los contenedores de CI y del repositorio de fuentes, y todos los registros de aplicaciones de Melaya) se envían fuera del servidor en tiempo real a un inquilino de Grafana Cloud Loki en la misma región que el servidor de producción mediante un recopilador Grafana Alloy, de modo que la pista de auditoría sobrevive al compromiso del servidor o a la pérdida del disco. Las conexiones de red salientes son registradas por una regla de registro de tráfico de salida a nivel de red y se reenvían al mismo sumidero externo; este tráfico de salida se registra y observa en la actualidad, mientras que la lista de permisos de salida aplicada basada en denegación permanece como elemento pendiente en la hoja de ruta.
Los eventos relevantes para la seguridad (resultados de autenticación, resultados de desafíos MFA, adiciones y eliminaciones de credenciales CEX, emisión y revocación de claves de API de la plataforma, cambios y reversiones de tier) se escriben adicionalmente en una tabla agents.audit_log de solo adición. El esquema revoca UPDATE y DELETE del rol de la aplicación, mantiene una cadena de hash criptográfico sobre las filas (prev_hash / row_hash), almacena la IP del actor únicamente como un digest HMAC-SHA256 bajo un secreto con clave (no SHA-256 simple, que es vulnerable a ataques de diccionario), y proporciona una tabla auxiliar agents.audit_log_tombstone para el borrado según el Artículo 17 del GDPR que nunca muta la cadena. Un verificador diario (verify-audit-chain.ts) recorre la cadena de extremo a extremo, comprueba la monotonía de los timestamps con una tolerancia NTP de ±2 segundos, y emite un digest de anclaje adecuado para almacenamiento externo de una sola escritura. Seis escenarios de alteración en audit-log-verify.ts finalizan con cero contra producción en vivo.
7. Gestión de Vulnerabilidades
Cada confirmación ejecuta npm audit --production y un análisis de sistema de archivos con Trivy como parte de CI. Trivy se invoca dos veces en cada compilación: una vez en modo de bloqueo con ignore-unfixed: true para que los hallazgos accionables fallen la verificación, y una vez con ignore-unfixed: false sin bloqueo para que la superficie de vulnerabilidad completa se cargue en la pestaña de Seguridad del repositorio como evidencia de cumplimiento. El host de producción ejecuta unattended-upgrades con el canal de seguridad habilitado y una ventana de reinicio automático. Las imágenes de contenedor de terceros para los servicios de CI, source-forge, secrets-vault, Postgres y Redis están sujetas a revisión antes de actualizaciones de versión, se rastrean en el runbook de Cadencia de Parches del vault de seguridad interno, y son monitoreadas por un detector diario de desviación de digest de imagen que alerta dentro de las 24 horas posteriores a cualquier rotación silenciosa de imagen.
Melaya aún no ha sido sometida a una prueba de penetración externa de terceros. El alcance del compromiso (incluyendo los activos dentro y fuera del alcance, las reglas de participación, la lista corta de proveedores que requieren acreditación CREST y la cadencia de remediación post-compromiso) está confirmado en el runbook interno Pentest Scope para que la selección del proveedor pueda avanzar tan pronto como la reconciliación de IaC de Cloudflare de la sección 5 se complete. No se realiza ninguna afirmación de "pentest anual" en ningún lugar de la documentación de Melaya.
8. Desarrollo de Software Seguro
Los cambios en la plataforma fluyen a través del control de código fuente con revisión de pares antes de la fusión. El modo estricto de TypeScript y el análisis estático se ejecutan en cada compilación del cliente y del servidor. gitleaks se ejecuta como un hook de pre-commit y en CI, con una lista de permitidos de alcance de ruta en lugar de una global, de modo que la divulgación accidental de credenciales falla la compilación antes de la fusión. Todas las acciones de CI están fijadas por SHA de commit para prevenir ataques de reescritura de etiquetas en la cadena de suministro. Los despliegues de producción pasan por un wrapper SSH restringido de Jenkins con una restricción command= en authorized_keys para que incluso un runner de CI comprometido solo pueda invocar las operaciones explícitas resync <service> y log <service> para los servicios de Melaya en la lista de permitidos: sin shell arbitraria, sin recorrido del sistema de archivos, sin escalada de privilegios más allá del reinicio del servicio en sí. Cada invocación del pipeline de despliegue se registra fuera de la caja en el tenant de Grafana Cloud Loki para auditoría, junto con un registro de procedencia confirmado que vincula el binario en ejecución con su commit fuente.
9. Respuesta a Incidentes
Melaya mantiene un runbook escrito de Respuesta a Incidentes que cubre la declaración de severidad (cuatro niveles de severidad), la asignación de roles (Comandante de Incidentes, líder técnico, comunicaciones, escriba), una lista de verificación de contención que incluye pasos explícitos de rotación de clave de sobre, clave JWT y clave HMAC de IP de registro de auditoría, la matriz de notificación de 72 horas del Artículo 33 del GDPR, y una plantilla de post-mortem. El runbook está confirmado en el vault de seguridad interno y se trata como un documento vivo: el primer ejercicio de mesa está programado para el 2026-07-15, y el runbook está explícitamente marcado como "no activo" en sus propios procedimientos hasta que se ejecute ese ejercicio. Los ingenieros de guardia responden a incidentes reales hoy; el control del ejercicio se refiere al ejercicio formal de mesa, no a la existencia de la ruta de respuesta.
10. copia de seguridad y Recuperación ante Desastres
Los objetivos de Tiempo de Recuperación (RTO) y Punto de Recuperación (RPO) por subsistema están publicados en el runbook interno RTO RPO: el tier agents.* tiene como objetivo un RTO de 15 minutos y un RPO de 2 horas, el almacenamiento de credenciales CEX tiene como objetivo un RTO de 5 minutos y un RPO de 1 hora, Infisical y el almacenamiento de objetos tienen como objetivo un RTO de 4 horas y un RPO de 1 hora, y Redis no tiene respaldo y se reconstruye al reconectarse. Los mecanismos de respaldo combinan el archivado continuo de WAL con una ventana de recuperación a un punto en el tiempo de 14 días, un volcado lógico nocturno retenido en otra región, un respaldo base mensual y una exportación diaria de anclaje del registro de auditoría de solo escritura a una ubicación externa. Todos los artefactos de respaldo están comprimidos, con suma de verificación y cifrados con restic. La verificación de restauración se ejecuta en dos cadencias: un trabajo semanal automatizado realiza una verificación de integridad de restic y una restauración puntual en un directorio de prueba, y el primer ejercicio de restauración completo en un entorno desechable está programado para el 2026-07-15, tras el cual su atestación escrita del tiempo de reloj de pared de restauración y la verificación de integridad se confirmará en el mismo runbook. Melaya opera desde una única región de hosting principal hoy. Esto se divulga claramente, y los controles compensatorios (volcados nocturnos en otra región, archivado continuo de WAL, una sonda de salud en otra región y failover DNS de Cloudflare) limitan el RTO de peor caso de pérdida total de región a aproximadamente 24 horas como un riesgo documentado y aceptado.
11. Continuidad de Negocio
Un Plan de Continuidad del Negocio escrito está confirmado en el vault de seguridad interno, cubriendo la respuesta a interrupciones de la región primaria, falla del proveedor de Postgres, interrupción del vault de Infisical (el servidor continúa sirviendo las sesiones existentes mediante credenciales en caché, las nuevas escrituras CEX se rechazan con un error visible para el usuario), interrupción de Stripe (las suscripciones existentes no se ven afectadas), la matriz de disponibilidad de personal y una tabla de contingencia por proveedor. El plan se revisa en la misma cadencia trimestral que la línea base de TLS, con un recorrido anual completo como parte del ejercicio de mesa.
12. Seguridad de Vendors y Subencargados
Melaya utiliza subencargados y proveedores de infraestructura para las funciones descritas en la lista pública de Subencargados. La función contractual, ubicación y garantía de transferencia de cada proveedor deben evaluarse según el despliegue y acuerdo reales; los proveedores de modelos, conectores, comerciantes o herramientas seleccionados por el cliente pueden actuar conforme a sus instrucciones y propias condiciones, en lugar de contratos de proveedor de Melaya. Los clientes empresariales reciben los derechos aplicables de notificación y oposición conforme a su acuerdo o anexo de tratamiento de datos. El entorno alojado principal de Melaya funciona actualmente en Singapur, que no está cubierto por una decisión de adecuación de la UE, por lo que las transferencias aplicables exigen un mecanismo lícito y garantías complementarias cuando proceda. Un entorno local ejecuta Python, archivos locales, operaciones de recuperación y credenciales seleccionadas en hardware controlado por el cliente, pero la configuración, contenido firmado del envío, entrega de credenciales seleccionadas, eventos de colaboración, telemetría, solicitudes a modelos en la nube o llamadas a conectores aún pueden pasar por Melaya o alcanzar a Melaya y terceros según el modo elegido. La página pública de Subencargados, el acuerdo del cliente y el flujo real - no solo la palabra «local» - determinan la información sobre destinatarios y residencia.
13. Postura de Cumplimiento
Melaya está desarrollando sus controles teniendo en cuenta los Criterios de Servicios de Confianza de SOC 2 e ISO/IEC 27001. A la fecha de este documento, Melaya NO posee SOC 2 Tipo I, SOC 2 Tipo II, ISO/IEC 27001 ni ninguna atestación de seguridad de terceros equivalente, y no se ha realizado ninguna evaluación por parte de un organismo de examen o certificación. Estos son hitos aspiracionales en nuestro roadmap. Cualquier cliente potencial que requiera una atestación hoy debe esperar un entregable de análisis de brechas en lugar de un informe completado. Los clientes enterprise pueden solicitar nuestra matriz de controles actual y la lista de remediaciones en curso contactando a [email protected].
Se ha redactado y comprometido en el bóveda interno de seguridad una plantilla de Addendum de Tratamiento de Datos de quince secciones. Incorpora las Cláusulas Contractuales Tipo de la Comisión Europea (Módulo 2 para responsable a encargado y Módulo 3 para encargado a encargado), el UK International Data Transfer Addendum y el equivalente del FADP suizo. El compromiso de notificación de brechas en 72 horas del Artículo 33 GDPR, el procedimiento de devolución o eliminación y los derechos de auditoría (limitados a SOC 2 Type II anual y bajo NDA cuando aterrice) están todos vinculados en la plantilla. La revisión por asesoría externa está pendiente antes de que el DPA se ofrezca como clickwrap en los planes de pago y como versión firmable bilateralmente en el plan citadel.
14. Responsabilidades del Cliente
La seguridad en Melaya es compartida. Los clientes son responsables de elegir contraseñas fuertes y únicas, proteger sus credenciales de cuenta, limitar el alcance de las claves API de exchange a los permisos mínimos requeridos, revisar y validar el comportamiento de los pipelines que construyen, controlar qué contenido cargan a los índices de recuperación, revisar los términos y las prácticas de tratamiento de datos de los proveedores de modelos de lenguaje de terceros que opten por enrutar, y reportar puntualmente cualquier sospecha de compromiso. Recomendamos encarecidamente habilitar la autenticación de dos factores en la configuración de la cuenta la primera vez que inicie sesión; es obligatoria antes de que pueda añadirse cualquier credencial CEX o generarse cualquier clave API de plataforma, y es el control de seguridad de mayor impacto que un cliente puede aplicar a su propia cuenta.
15. Responsible Disclosure y Safe-Harbor
Safe-harbor. Melaya Labs LLC no emprenderá acciones legales contra, ni apoyará ninguna acción legal de un tercero contra, los investigadores de seguridad que actúen de buena fe y cumplan con esta política. Este compromiso se aplica a las reclamaciones que Melaya podría plantear en otro caso conforme a la U.S. Computer Fraud and Abuse Act (CFAA), la U.K. Computer Misuse Act, las disposiciones equivalentes de los estatutos de uso indebido informático de los Estados Miembros de la UE y cualquier reclamación de derecho civil por incumplimiento de contrato, interferencia ilícita o trespass to chattels. "Buena fe" significa que el investigador hizo un esfuerzo genuino por cumplir con el alcance y las reglas de compromiso siguientes, no accedió, modificó, destruyó ni exfiltró datos pertenecientes a otros usuarios, no degradó intencionadamente los Servicios para otros usuarios y divulgó el hallazgo de forma privada a [email protected] antes de cualquier divulgación pública. Esta cláusula es vinculante para Melaya y no requiere aprobación por reporte. No cubre conducta que sea independientemente ilegal en la jurisdicción del investigador, como fraude financiero real contra otros usuarios, o extorsión.
Scope. El testing está autorizado contra melaya.org y todos los subdominios en la zona *.melaya.org, la superficie de aplicación en app.melaya.org, los endpoints de la API del Builder y las páginas legales publicadas por Melaya. El testing NO está autorizado contra: (i) la colocación, cancelación o modificación de órdenes en vivo en ninguna exchange de terceros accesible a través de Melaya; (ii) los proveedores de modelos de lenguaje de terceros (OpenAI, Anthropic, Google, Cohere, runtimes locales) accesibles a través de un pipeline configurado por el usuario; (iii) la propia infraestructura de Cloudflare, del proveedor de alojamiento o del proveedor de bóveda; (iv) cualquier forma de ataque de denial-of-service (L3/L4 flood, L7 flood, credential stuffing a volumen); (v) ingeniería social a empleados, contratistas o clientes de Melaya; (vi) intrusión física.
Reglas de compromiso. Los investigadores deben detener el testing en el momento en que un hallazgo haya sido probado (una sola lectura no destructiva es prueba suficiente de acceso cross-entorno de cliente), nunca deben modificar ni exfiltrar datos de otros usuarios, no deben instalar persistencia y deben mantener el testing automatizado por debajo de 1 solicitud por segundo sostenida. El tráfico de testing debe llevar una cabecera distintiva User-Agent: Melaya-research/<handle> para que Melaya pueda distinguirlo del tráfico real y no se pagine al on-call por ello.
SLA de Triaje. Melaya se compromete a acusar recibo de los informes válidos dentro de cinco (5) días hábiles de su recepción, a proporcionar una evaluación inicial de severidad dentro de diez (10) días hábiles del acuse de recibo, y a remediar los hallazgos según la escala de severidad: Crítico dentro de 48 horas, Alto dentro de 7 días calendario, Medio dentro de 30 días calendario, Bajo dentro de 90 días calendario. Si Melaya incumple un compromiso de SLA, el investigador puede proporcionar siete (7) días de aviso escrito de intención de publicación y la protección de puerto seguro permanece en vigor durante la publicación, siempre que el investigador haya cumplido con las reglas de participación en todo momento.
Contacto. Los reportes deben enviarse a [email protected]. Una clave PGP para reportes cifrados se publicará en /.well-known/security.txt. Los reportes no deben enviarse a través de redes sociales, GitHub issues en repositorios públicos de Melaya o cualquier superficie de chat de soporte: esos canales no se monitorizan para contenido sensible de seguridad y crean riesgo de divulgación pública accidental antes de la remediación.
Esta Sección 15 es autocontenida y sus compromisos son vinculantes. El safe-harbor del primer párrafo, el alcance y las reglas de compromiso del segundo y tercer párrafos, el SLA de triage del cuarto párrafo, Y las reglas de interacción con los Términos del Servicio y de enmienda solo prospectiva del párrafo inmediatamente siguiente constituyen conjuntamente el conjunto completo de compromisos vinculantes para Melaya respecto a los investigadores de seguridad. Cada párrafo de esta Sección 15, no solo los cuatro primeros, forma parte del conjunto de compromisos vinculantes. Melaya mantiene un runbook operativo interno para el enrutamiento de triage y la escalada, pero ese runbook no añade, sustrae ni modifica ninguno de los compromisos de esta Sección 15, y un investigador no necesita leer ningún otro documento para basarse en el safe-harbor anterior. Cualquier cambio a esta Sección 15 se aplica únicamente de forma prospectiva: un hallazgo reportado de buena fe bajo la versión de esta Sección 15 vigente en el momento del reporte permanece protegido por el safe-harbor de esa versión con independencia de cualquier enmienda posterior.
Interacción con los Términos del Servicio (vinculante). Esta Sección 15 constituye la autorización expresa de Melaya para la actividad de investigación de seguridad que, de otro modo, estaría restringida por las prohibiciones de los Términos del Servicio contra eludir, deshabilitar o interferir con las funciones de seguridad, rate-limiting o control de acceso de Melaya. Un investigador que actúe dentro del alcance y de las reglas de compromiso anteriores no está, por tanto, en incumplimiento de los Términos por esa conducta, y Melaya renuncia a cualquier reclamación que de otro modo podría plantear bajo los Términos respecto a esa conducta específica. Este párrafo forma parte por sí mismo del conjunto de compromisos vinculantes anterior y no es meramente texto interpretativo.
Modelo de seguridad de Device Control
Device Control está diseñado como un canal autorizado por el usuario y denegado por defecto. La aplicación Android no puede habilitar por sí sola la Accesibilidad ni la captura de pantalla; el usuario debe conceder dichos permisos en el sistema operativo. Android puede exigir la aprobación de ajustes restringidos para versiones instaladas fuera de la tienda.
Los teléfonos emparejados se autentican mediante un token de dispositivo revocable almacenado como resumen criptográfico (hash) en el servidor. Los tokens telefónicos se limitan a los puntos de conexión telefónicos, son distintos de las sesiones del navegador y tokens de entornos de ejecución y pueden revocarse desde la cuenta del usuario.
El acceso a aplicaciones se aplica mediante una lista de aplicaciones permitidas. El servidor conserva los paquetes aprobados por el usuario; el teléfono sincroniza esa política y comprueba la aplicación en primer plano antes de leer el árbol de pantalla, determinar la admisibilidad de capturas, pulsar, escribir, deslizar o realizar otras acciones restringidas.
Los fotogramas en directo usan un relé de último fotograma para visualización en tiempo real. No se utilizan como credenciales generales de la cuenta y solo se asocian al canal del usuario titular. Los agentes solo deben solicitar capturas cuando los datos estructurados de accesibilidad sean insuficientes.
Las ejecuciones móviles nativas registran una ejecución activa para el teléfono del usuario. El control de parada de la superposición solo puede finalizar esa ejecución registrada para el mismo usuario; no puede finalizar pipelines arbitrarios. Los estados terminales y de intervención humana devuelven al usuario a Melaya para que el control siga visible.
Controles de los Agentes móviles y de la ejecución en dispositivos
La seguridad de los Agentes móviles separa la decisión, autorización, encaminamiento y ejecución física. Un modelo o agente puede proponer una orden; los servicios de Melaya validan al usuario autenticado, el estado del teléfono emparejado, la política de acciones y la envolvente de la orden; el primer teléfono apto que consulte la cola puede reclamar un trabajo encolado para el usuario; y el dispositivo registrado y controlado por este ejecuta entonces la orden conforme a los permisos del sistema operativo.
Las credenciales del dispositivo son distintas de las sesiones del navegador, identidades de servicios en la nube, credenciales de proveedores y tokens de entornos locales. El servidor almacena un resumen criptográfico (hash) SHA-256 del token revocable del teléfono. Android almacena actualmente el token sin transformar en SharedPreferences privadas, mientras que iOS lo almacena en el Llavero. Un token telefónico no autoriza la administración general de la cuenta, los puntos de conexión telefónicos de otro usuario ni un entorno de ejecución ajeno.
Las órdenes se deniegan por defecto y se limitan al usuario autenticado, trabajo reclamado, política de aplicaciones, tipo de acción, parámetros y vigencia en la cola. La cola y la lista de permitidos están actualmente asociadas al usuario, y no dirigidas de forma determinista a un dispositivo seleccionado cuando hay varios teléfonos emparejados; una vez reclamado el trabajo, los controles de titularidad vinculan su resultado. Los puntos de conexión sensibles autentican al solicitante, validan tamaños y titularidad y rechazan trabajos caducados, pero los clientes solo deben emparejar dispositivos de confianza.
Las acciones ambiguas o de gran impacto deben exigir una nueva confirmación humana, información clara sobre el objetivo y las consecuencias y una vía disponible de pausa o parada. Los indicadores persistentes, superposiciones, notificaciones de servicios en primer plano, vistas previas, tiempos de espera, límites de frecuencia, registros de auditoría y limpieza de estados terminales ofrecen defensa en profundidad, pero no garantizan que una acción sea correcta o reversible.
Los canales de órdenes y telemetría utilizan transporte cifrado e identidades autenticadas. Cuando están implantados, los envíos firmados o protegidos en su integridad, nonces, identificadores de orden, caducidad, vinculación al dispositivo y detección de repetición reducen la alteración y ejecución entre usuarios. El cifrado del transporte no impide que un endpoint autorizado vea el texto claro necesario para ejecutar la solicitud.
Los entornos locales mantienen la ejecución de Python, archivos locales e inferencia del modelo local dentro del entorno del usuario, sujetos a los controles de su sistema operativo. Las ejecuciones híbridas exponen además cargas de inferencia o herramientas a los proveedores en la nube seleccionados. Las ejecuciones en la nube se realizan en infraestructura gestionada por Melaya y pueden tratar datos de ejecución y secretos seleccionados. El aislamiento reduce, pero no elimina, los riesgos de aplicaciones, dependencias, modelos, inyección de prompts o infraestructura.
Las credenciales almacenadas usan cifrado o controles de gestión de secretos y solo se entregan cuando se seleccionan para una ejecución. El proceso de ejecución y el proveedor externo reciben necesariamente material de autenticación utilizable. Los usuarios deben aplicar el mínimo privilegio, separar credenciales de producción y pruebas, rotarlas y revocarlas con prontitud, restringir ámbitos del proveedor y nunca introducir secretos en prompts, capturas, registros o resultados de herramientas no fiables.
Los servicios de telemetría y colaboración pueden recibir cualquier mensaje, traza, evento de herramienta, resultado, coste, estado, solicitud de aprobación, captura o carga de diagnóstico que emita un entorno. Los clientes deben configurar adecuadamente el detalle y conservación de eventos, evitar datos sensibles innecesarios y aplicar controles de acceso al espacio de trabajo y proyecto. «Local» describe el lugar de ejecución, no garantiza que no se transmita telemetría.
La Accesibilidad de Android y MediaProjection son capacidades sensibles otorgadas por el usuario. La aplicación móvil debe ofrecer la información destacada y obtener el consentimiento afirmativo exigidos antes del acceso, usar la API menos amplia disponible, permanecer visible cuando proceda, funcionar de forma limitada si se deniega el permiso y nunca usar permisos para eludir la seguridad de la plataforma u ocultar actividad. Una versión distribuida en Google Play no debe permitir que la Accesibilidad inicie, planifique y ejecute acciones autónomamente contra sus normas.
La aplicación iOS de App Store está limitada por el entorno aislado, derechos y API públicas de Apple y no ofrece control irrestricto de aplicaciones de terceros. Las vías mediante entorno Mac, Modo de desarrollo, XCTest, WebDriverAgent, dispositivo emparejado o pruebas firmadas para desarrollo presentan otro modelo de amenazas y confianza y exigen control del Mac, identidad de firma, emparejamiento, objetivo de prueba y canal de red.
Ningún control elimina todos los riesgos. Los modelos pueden ser manipulados por prompts o contenido de pantalla; las aplicaciones pueden cambiar su diseño; los permisos pueden ser excesivos; las dependencias pueden verse comprometidas; los dispositivos pueden perderse; y los usuarios autorizados pueden hacer un uso indebido. Investigamos comunicaciones creíbles, podemos revocar o aislar credenciales o dispositivos afectados y recomendamos usar de inmediato los procedimientos de parada, revocación, rotación y notificación de incidentes.
16. Cambios a este Resumen
Melaya puede actualizar esta Descripción General de Seguridad periódicamente para reflejar cambios en la plataforma, nuestros controles o nuestros subprocesadores. La fecha de "Última actualización" en la parte superior de este documento refleja la revisión más reciente. Cuando los elementos operativamente pendientes (como el primer ejercicio de restauración, el primer ejercicio de mesa de IR, la primera prueba de penetración externa, el cifrado de disco a nivel de volumen o la revisión por asesoría externa de la plantilla de DPA) se completen, la sección correspondiente se reescribe para reflejar el nuevo estado y el cambio se anuncia en el registro de cambios del producto.
17. Contacto
Para preguntas de seguridad, reportes de vulnerabilidades o para solicitar documentación de cumplimiento, contacte con: