Seguridad

El sistema se diseñó con tres reglas: el navegador nunca habla con las plataformas de IA, cada dato pertenece a una organización y solo esa organización puede leerlo, y nada relacionado con una medición se sobrescribe. Lo que sigue describe cómo se aplican esas reglas en la implementación actual.

No contamos con certificaciones externas (por ejemplo SOC 2 o ISO 27001) y no afirmamos tenerlas. Si tu organización necesita una evaluación de seguridad, escríbenos y compartiremos la documentación técnica disponible.

La autenticación es de primera parte y vive en la API, que es la única autoridad sobre quién eres y a qué organización perteneces.

Cada recurso de cliente lleva el identificador de su organización y, cuando aplica, de su proyecto. Las rutas de la API están ancladas a la organización o al proyecto, y la pertenencia se carga desde el usuario autenticado, nunca desde una cabecera o parámetro controlado por el cliente. Los sub-recursos se consultan siempre mediante una unión con el proyecto filtrada por organización, en la capa de consultas. Las pruebas automatizadas verifican que un acceso cruzado entre organizaciones responde 404, para no revelar siquiera la existencia del recurso.

Las funciones de administración interna usan rutas separadas, reservadas a superadministradores, y no comparten controladores con las rutas de clientes.

Las claves de OpenAI, Anthropic, Google y Meta existen únicamente en el entorno de la API y de los trabajadores en segundo plano. El navegador nunca las recibe ni llama directamente a esos proveedores: las solicitudes salen desde nuestros servidores, con tiempos de espera acotados y reintentos limitados. Las cabeceras de autorización se eliminan de cualquier registro.

Los endpoints de autenticación y los endpoints públicos (análisis gratuito, contacto, eventos de analítica) están protegidos con limitación de frecuencia respaldada en Redis. El análisis gratuito además guarda un hash de la dirección IP para limitar repeticiones sin conservar la IP en claro. Cada ejecución contra una plataforma de IA registra tokens y costo, y los límites del plan se aplican antes de ejecutar.

Toda entrada a la API se valida con esquemas tipados antes de llegar a la lógica de negocio. La base de datos es PostgreSQL con identificadores UUID; las mediciones (ejecuciones, respuestas, evaluaciones, citas) son de solo anexado y no se modifican de forma destructiva, lo que permite auditar cualquier cifra histórica. La eliminación de proyectos es un archivado lógico; la eliminación definitiva es una operación administrativa explícita.

Las acciones relevantes (creación y cambios de proyectos, marcas, preguntas, oportunidades y acciones, cambios de miembros) se guardan en un registro de actividad con actor, entidad, fecha e IP. Los registros de aplicación son estructurados (JSON) e incluyen identificadores de solicitud, organización y proyecto para poder seguir una operación de extremo a extremo. Los secretos, tokens y cabeceras de autorización se redactan antes de escribirse. Los fallos de ejecución y evaluación se persisten con su código de error y se muestran en el panel interno para su revisión.

La plataforma es un monolito modular: una API, un trabajador de tareas en segundo plano, PostgreSQL y Redis. Menos componentes significa menos superficie de exposición. Cada variable de entorno está documentada y los secretos no se incluyen en el repositorio. Antes del lanzamiento comercial completaremos la lista de verificación de seguridad previa al lanzamiento documentada en nuestro roadmap interno.

Si encuentras una vulnerabilidad, escríbenos a hola@asoma.app con una descripción del problema y los pasos para reproducirlo. Confirmaremos la recepción, te mantendremos informado del avance y no emprenderemos acciones legales contra investigaciones realizadas de buena fe que no accedan a datos de terceros ni degraden el servicio. Te pedimos no divulgar el hallazgo públicamente hasta que esté corregido.