Seguridad

Ocho compromisos de confianza

Ocho compromisos que Mycelium entrega en cada tier, en código y en los Términos de Servicio. Aparecen en línea en el wizard de onboarding en el paso de OAuth, no enterrados en letra chica. Algunos compromisos dependen del tier (Team y Enterprise suman registro de auditoría y una capa personal privada); marcamos el tier explícitamente por compromiso.

Estos ocho son la lista canónica. Agregamos compromisos nuevos solo después de revisión de panel (para evitar inflación de promesas de confianza). Si una superficie futura agrega uno, aterriza aquí primero, antes de que cualquier copy de marketing se refiera a él.

1. Credenciales cifradas en reposo

Qué significa. Tokens OAuth, refresh tokens y API keys se cifran en reposo en la capa de almacenamiento. El contenido del cliente en reposo también se cifra. Nunca leemos tokens ni contenido en texto plano desde disco.

Cómo lo aplicamos. Cifrado en reposo gestionado por Postgres con AES-256 en cada superficie persistente. TLS 1.3 en la frontera pública; mTLS en la frontera entre servicios dentro del motor de ejecución. Las llaves de cifrado por tenant (BYOK) están disponibles en el tier Mycelium Enterprise; rotación de llave vía la API de admin. La superficie completa de cifrado está documentada en el Data Processing Addendum.

2. Desconectar es igual a eliminar en 24 horas

Qué significa. Cuando el admin del workspace desconecta un conector, los datos ingeridos de esa fuente se eliminan en 24 horas. Eso cubre eventos crudos, embeddings derivados y nodos del grafo de conocimiento que se rastrearon hasta la fuente.

Cómo lo aplicamos. La desconexión corre en dos fases, ambas ahora aplicadas por la arquitectura de extremo a extremo.

Fase 1 (sincrónica): cuando se llama al endpoint admin de desconexión, el motor de ejecución agrega la fuente al set disconnected_sources del tenant. Cada receptor de webhook (Slack, GitHub, Notion, Linear, Gmail, Salesforce, Microsoft 365, Confluence, Google Workspace, ServiceNow, Workday y doce más) revisa este set antes de verificar la firma y devuelve HTTP 410 Gone si la fuente coincide. No se ingiere contenido nuevo después de que la llamada retorna. El registro de auditoría lleva connector.disconnect.requested + connector.disconnect.scheduled en el mismo tick.

Fase 2 (asincrónica, programada): la misma llamada agenda un trabajo de purga en vault_path/.runtime/disconnect_jobs/{source}.json con scheduled_at = ahora + grace_period_seconds (por defecto 24 horas, configurable de 0 a 720 horas). El tick del trabajador procesa trabajos vencidos en cadencia de 15 minutos: recorre vault_path/External Inputs/{source}/, elimina los archivos y luego descarta las filas de embeddings correspondientes. El registro de auditoría lleva connector.disconnect.purge_started y connector.disconnect.purge_complete (o purge_failed en error, con alerta al operador y reintento dentro de la ventana de gracia). La latencia máxima de purga es grace_period + 15 minutos, lo que mantiene el SLA de 24 horas de extremo a extremo apretado a nivel de arquitectura cuando se usa el período de gracia por defecto.

Los clientes pueden cancelar una desconexión programada antes de que el trabajador tome el trabajo (la aceptación a nivel de token se restablece); cancel devuelve 409 una vez que la purga ha comenzado. Los clientes que necesiten una ventana de gracia personalizada o eliminación pre-programada escriben a privacy@mycelium-ai.co y un operador coordina el cambio.

La desconexión a nivel de conector no toca otros conectores. Eliminar la cuenta revoca el acceso en todos los conectores de inmediato. La eliminación completa del contenido corre luego por conector mediante la purga de Fase 2 descrita arriba; una sola llamada de hard-delete a nivel de cuenta es trabajo en progreso, aún no lanzada.

Los endpoints implementadores son POST /admin/connectors/{tenant_id}/{source}/disconnect (agendar), GET /admin/connectors/{tenant_id}/{source}/disconnect (estado), y DELETE /admin/connectors/{tenant_id}/{source}/disconnect (cancelar-mientras-programado). El código fuente vive en el motor de ejecución en src/connectors/disconnect.py + src/connectors/worker.py; la especificación completa está en docs/api/admin-connectors.md. Oficiales de Compras de Fortune 100 que pregunten cómo Mycelium prueba que una eliminación se honró pueden solicitar una exportación de muestra del registro de auditoría con la secuencia canónica de eventos en un tenant no productivo.

3. Nunca se usa para entrenamiento

Qué significa. El contenido del cliente nunca se usa para entrenar ningún modelo de IA, ni nuestro ni de nadie más. Esto es contractual, no aspiracional.

Cómo lo aplicamos. Los Términos de Servicio prohíben entrenar con contenido del cliente. Mycelium no entrena actualmente ningún modelo con datos de clientes. Cuando usas Hosted Pass-Through inferencia (una funcionalidad opt-in en Team y Enterprise), el proveedor de modelo upstream (Anthropic, OpenAI, Google) opera bajo sus contratos enterprise, que prohíben entrenar con prompts de clientes. El camino por defecto es BYO inferencia (compromiso #4 abajo), que mantiene tu contenido fuera de cualquier endpoint de inferencia controlado por Mycelium.

4. BYO inferencia

Qué significa. Mycelium no incluye el costo de inferencia. Traes tu subscripción existente de Claude Pro, ChatGPT Plus, Gemini, o tu API key. Tu contenido nunca llega a un endpoint de inferencia controlado por Mycelium a menos que tu workspace explícitamente opte por Hosted Pass-Through.

Cómo lo aplicamos. El motor de ejecución incluye ruteo de modelo con patrón adapter. El ruteo por defecto envía las llamadas de inferencia a través de la subscripción BYO que configuras al instalar. Hosted Pass-Through es una funcionalidad opt-in a nivel de tier con un toggle explícito en la UI de admin. El adapter no almacena prompts en servidores de Mycelium en el camino BYO. La razón comercial importa: evitar la reventa por token es estructural, no estacional. Mira la sección de Precios para el compromiso BYO en copy plano.

5. Pausar sincronización (un click para períodos sensibles)

Qué significa. Un toggle de un click pausa la ingesta de conectores en todas las fuentes sin desconectarlos. Útil para retenciones legales, ventanas de M y A, investigaciones internas o cualquier período en que quieras cerrar el camino de ingesta temporalmente.

Cómo lo aplicamos. El toggle de pausa vive en la página de Conectores. Mientras está pausado, no se ingieren eventos nuevos, no se computan embeddings, no se disparan actualizaciones del grafo de conocimiento. Los datos existentes siguen consultables. Reanudar vuelve a habilitar la ingesta desde el punto de reanudación hacia adelante. El backfill de la ventana pausada es opt-in por fuente.

6. Registro de auditoría en Team y Enterprise

Qué significa. En los tiers Team y Enterprise, cada consulta de búsqueda y cada invocación de IA se registra con timestamp, identidad del actor, IP de origen y el payload de la consulta. El admin del workspace puede exportar el registro bajo demanda.

Cómo lo aplicamos. El registro de auditoría append-only vive en audit-log.jsonl por tenant. Los admins del workspace exportan el registro vía el endpoint de admin. La retención por defecto es 12 meses en Team, extensible a 7 años en Enterprise para compradores SOX o adyacentes a HIPAA. Las exportaciones de auditoría son JSONL comprimido en gzip firmado con una llave por tenant. Las cuentas de tier Personal no tienen registro de auditoría porque no tienen admins a quienes auditar; el registro es una superficie de Team hacia arriba por diseño.

7. Capa personal privada en Team

Qué significa. En el tier Team y superior, cada miembro del workspace tiene una capa personal conectada a sus fuentes personales (Gmail personal, Notion personal, iMessage, etc.). La capa personal es privada para ese usuario. Los admins del workspace no la pueden buscar. Los otros miembros del equipo no la pueden ver. No alimenta el cerebro de la empresa.

Cómo lo aplicamos. El motor de ejecución aplica una frontera de privacidad por usuario en la capa de almacenamiento y de consulta. La capa personal vive bajo un scope JWT por usuario; el cerebro de la empresa es un scope JWT separado. Las lecturas cruzando scope se deniegan en la capa de autenticación. Una prueba de integración afirma que un token de admin no puede leer los caminos de la capa personal de otro usuario. El flujo de empleado saliente (cubierto en la guía de aprobación de IT abajo) exporta el contenido de la capa personal del usuario en 7 días, después lo elimina. La arquitectura completa de control de acceso vive en /security/rbac.

8. Auditoría de seguridad de tercero y SOC 2 Type II en progreso

Qué significa. Mycelium ha contratado una auditoría de seguridad de tercero y está corriendo un período de observación SOC 2 Type II. Ambos salen antes de que entre el primer cliente pago.

Cómo lo aplicamos. La selección del proveedor y el arranque de auditoría se rastrean en un work item hermano. El nombre de la firma auditora y la ventana de observación aparecen en Estado de auditoríaabajo a medida que aterrizan. No reclamamos “SOC 2 certificado” hasta que el reporte SOC 2 Type II esté en mano. Durante el período de observación, la insignia dice “en progreso.” La auditoría cubre revisión de código del motor de ejecución productizado, el sitio de marketing y la app de Studio, más prueba de penetración de mycelium-ai.co y la app de Studio, más revisión de los flujos OAuth de los conectores, cifrado de datos en reposo, aplicación de desconectar-es-igual-a-eliminar y aplicación de la frontera de tenant.

Estado de auditoría

Estado actual de la auditoría de seguridad de tercero y del período de observación SOC 2 Type II. Actualizado a medida que cada hito aterriza. Compras de Fortune 100 debería leer el nombre del auditor y la ventana de observación directamente de esta fila, no de un deck de ventas.

No reclamamos “SOC 2 certificado” hasta que el reporte SOC 2 Type II esté en mano. Durante el período de observación, la insignia dice “en progreso.” Esa distinción le importa a Compras. Nos sostenemos en ella.

Oficiales de Compras de Fortune 100 que pidan el nombre del auditor antes de la firma: escriban a security@mycelium-ai.co y compartimos la lista corta de tres firmas y el estado actual bajo NDA. Los nombres salen públicamente aquí cuando la carta de compromiso se firma.

Guía de aprobación de IT para admins del workspace

Para admins del workspace planificando una instalación Team o Enterprise. Antes de hacer click en “Conectar” en un flujo OAuth de Google Workspace empresarial, Slack, Notion o similar, obtén aprobación de IT y legal. Esta guía camina la ruta estándar.

La razón por la que esto importa: el OAuth a nivel de admin a un Google Workspace empresarial es scope creep real. Tú como admin puedes hacer click en la pantalla de consentimiento, pero ¿tu equipo de IT y legal tiene efectivamente la autoridad escrita para que Mycelium ingiera todo el correo empresarial y contenido de Drive al que llega el conector? Si el memo sobre-promete y el equipo de IT lo pasa por alto, la aprobación de IT se convierte en la violación de privacidad, no en su habilitador. Esta guía está construida para evitar eso.

Paso 1. Revisa el scope

Lee los ocho compromisos de confianza arriba. Decide qué conectores realmente necesitas al instalar. Sé específico sobre qué canales de Slack, qué carpetas de Drive y qué workspaces de Notion están incluidos. Las anulaciones de admin en cada conector te dejan ajustar el scope por defecto aún más.

Paso 2. Redacta el memo

Usa la plantilla de memo de IT y legal en la Sección 10 abajo. Llena los espacios específicos de tu empresa. Sé honesto sobre el scope que estás solicitando. No sobre-prometas.

Paso 3. Obtén aprobación por escrito

Envía el memo a tus contactos de IT y legal. Pide aprobación por escrito que cubra (a) el scope de los conectores, (b) los compromisos de manejo de datos, (c) cualquier requerimiento de residencia y (d) la ventana de retención del registro de auditoría si necesitas una desviación de los valores predeterminados. No hagas click en “Conectar” en Mycelium hasta que la tengas.

Paso 4. Documenta la aprobación

Guarda el hilo de aprobación o el memo firmado en tu archivo de carta de compromiso con Mycelium. Podemos referenciarlo en el MSA contractual o el DPA como el documento de autorización del scope.

Paso 5. Instala y audita

Completa el flujo OAuth. El registro de auditoría empieza a registrar inmediatamente. Rastrea los tickets de soporte por objeciones de IT o legal que surjan post-instalación. Iteramos la guía de scope basados en objeciones reales, no hipotéticas.

Plantilla de memo de IT y legal

Una plantilla copia-y-pega que puedes entregarle a tus equipos de IT y legal. Llena los [CORCHETES] con los detalles específicos de tu empresa. La plantilla está publicada bajo los mismos términos que el resto de mycelium-ai.co; eres libre de copiarla, modificarla y usarla para tu proceso interno de aprobación.

Descargar plantilla de memo de IT y legal (Markdown)

La plantilla cubre: resumen ejecutivo, conectores propuestos, qué se ingiere por conector, qué se omite por conector, superficie de cifrado, los ocho compromisos de confianza, estado de auditoría, lista de subprocesadores, residencia de datos, referencia al DPA, flujo de empleado saliente, preguntas para hacerle a Mycelium por escrito y próximos pasos recomendados para IT y legal.

Versión en inglés: Download IT and legal memo template (Markdown).

Control de acceso por rol dentro de tu tenant

Mycelium entrega control de acceso por rol con globs de carpeta dentro de cada tenant. Cada JWT lleva un claim roles. Cada ruta que toca el vault resuelve el conjunto de roles contra la ruta objetivo antes de leer o escribir. Las denegaciones producen entradas estructuradas en el registro de auditoría.

Este es el entregable de Fase 4 en el camino de control SOC 2 CC6.1. La documentación completa, incluyendo la librería de 10 roles por defecto, la superficie de la API de admin, el comportamiento de denegación de webhooks, el comportamiento de retrocompatibilidad y las advertencias operativas que la mayoría de las páginas esconde, vive en /security/rbac.

Divulgación de vulnerabilidades

Mycelium corre un programa de divulgación coordinada. Los investigadores que reportan vulnerabilidades de buena fe y siguiendo las reglas abajo son reconocidos en nuestro CHANGELOG público y acreditados en cualquier aviso de seguridad relacionado.

Reporte

Envía reportes de vulnerabilidad a security@mycelium-ai.co. Las envíos cifrados son bienvenidos; huella PGP disponible bajo solicitud.

Por favor incluye:

• Una descripción clara y reproducible del problema
• La URL, endpoint, versión o componente afectado
• Salida de prueba de concepto o pasos que demuestren el impacto
• Tu nombre preferido para el crédito (o solicitud de permanecer anónimo)

Línea de tiempo de respuesta

• Acuse de recibo en un día hábil
• Clasificación inicial y evaluación de severidad en cinco días hábiles
• Plan de remediación y fecha objetivo en quince días hábiles
• Ventana de divulgación pública: noventa días desde el reporte inicial, o antes si un fix ha salido y se ha notificado a la base de clientes, lo que ocurra primero

Alcance

En alcance:

• mycelium-ai.co y todos los subdominios operados por Mycelium
• La capa de memoria de código abierto en github.com/mycelium-hq/ai-brain-starter
• Los endpoints del motor de ejecución productizado expuestos a clientes bajo carta de compromiso (sujeto a la sección de safe-harbor abajo)

Fuera de alcance:

• Servicios de tercero (infraestructura de Vercel, Resend, PostHog, Anthropic, OpenAI, etc.). Por favor reporta directamente al proveedor.
• Ingeniería social a empleados, contratistas o clientes piloto de Mycelium
• Ataques físicos a oficinas o hardware de Mycelium
• Pruebas de denegación de servicio o de límites de tasa sin autorización previa por escrito

Safe harbor

La investigación conducida en línea con esta política se considera autorizada y Mycelium no buscará acción civil ni la reportará a las autoridades. Los investigadores deben evitar acceder o modificar datos de clientes, deben detener las pruebas inmediatamente al ser solicitado, y deben darle a Mycelium tiempo razonable para remediar antes de la divulgación pública.

Reconocimiento

Los investigadores que siguen esta política y envían reportes de vulnerabilidad válidos son reconocidos en el CHANGELOG público y (con el consentimiento del investigador) en cualquier aviso de seguridad publicado. Las bounties en efectivo no se ofrecen actualmente; esperamos lanzar un programa pago después de que la auditoría SOC 2 Type II se complete.

Privacidad y solicitudes de sujetos de datos

Para preguntas de privacidad o solicitudes de sujetos de datos bajo GDPR, UK GDPR, CCPA o LGPD, escribe a privacy@mycelium-ai.co.