CentrodeConfianza

Cloudflare Workers es el origen canónico de producción usado por redirecciones de autenticación y metadatos SEO. La evidencia de candidatos registra identidad exacta de fuente/versión y comprobaciones públicas.

La base Agency SaaS define organizaciones, membresías, roles por tenant, escrituras de suscripción protegidas y límites respaldados por RLS.

MIRMC publica un canal privado de reporte, límites para pruebas responsables y un registro estándar security.txt sin afirmar falsamente un bug bounty ni un SLA garantizado de remediación.

MIRMC contiene enrolamiento TOTP y un challenge compartido AAL1-a-AAL2 después del login para cuentas con factor verificado. El billing privilegiado de Agency y las mutaciones protegidas del Centro de Mando también tienen gates de assurance en servidor.

Los redireccionamientos de Stripe no otorgan un plan. Se requieren webhooks firmados, mapeos de precios controlados por servidor y transiciones aprobadas antes de converger la suscripción.

Las mutaciones del tenant y transiciones comerciales anexan evidencia estructurada al audit trail de la organización. Las mutaciones protegidas del Centro de Mando conservan denegaciones de autorización y evidencia del ciclo de ejecución, y un límite staged de exportación AAL2 para owner/admin añade flujos JSON/NDJSON acotados, controles explícitos de origen del navegador y recibos SHA-256 por página.

La malla cognitiva de 30 agentes usa evidencia compartida, memoria versionada, canales de desafío, consenso ponderado y roles con veto, manteniendo límites de autoridad autónoma.

Una superficie pública localizada de estado realiza una sonda fresca de salud productiva y muestra evidencia exacta del candidato, separando explícitamente salud en vivo, uptime histórico y SLA contractual.

MIRMC ya define severidades de incidentes legibles por máquina, roles de respuesta, objetivos RPO/RTO solo de ingeniería y un protocolo aislado de evidencia para pruebas de restauración. Los objetivos numéricos siguen sin verificar y no son contractuales hasta que existan recibos reales de pruebas.

MIRMC publica un registro de proveedores/integraciones respaldado por código que distingue dependencias core de servicios condicionales y opcionales. Deliberadamente no se presenta como lista legal firmada de subprocesadores ni garantía de residencia de datos.

MIRMC ya contiene una autoridad staged de publicación por tenant con AAL2 de sesión actual, separación maker/checker, dos aprobaciones independientes para producción, caducidad, binding al commit exacto y un límite service-only ligado al release receipt de Cloudflare. Todavía no se afirma activación productiva.

Agency Overview ya contiene una superficie staged multi-sitio de métricas agregadas para cobertura de repositorios, autonomía, aprobaciones preview, dominios y gobierno de publicación. El snapshot exige autoridad del tenant y no expone filas crudas de clientes/proyectos.

MIRMC ya contiene un plano staged de retención por tenant con políticas acotadas por categoría, administración AAL2, legal holds con separación creador/liberador y un gate service-only de elegibilidad para borrado. La eliminación automática está apagada por defecto y no se afirma purge productivo.

MIRMC ahora mapea ocho actividades de tratamiento respaldadas por código a límites canónicos de proveedores, clases de datos, sujetos, categorías de retención y estados de evidencia de residencia, y puede construir un paquete JSON de procurement desde registros canónicos. El mapa es solo evidencia de ingeniería: no se infiere del código un DPA, rol legal, mecanismo de transferencia, garantía de residencia ni certificación de cumplimiento.

MIRMC ya contiene una base SAML SSO staged para inicio/callback, binding explícito del UUID del proveedor con la organización y guardas negativas cross-tenant. Producción continúa en planned porque todavía no existe un IdP real registrado y verificado, y no se afirma OIDC como implementado.

Está staged una base SCIM 2.0 Users por tenant, credenciales de organización hash-only, enlace de primer login ligado a SAML, plano de control AAL2 y precondiciones ETag atómicas opcionales. Producción continúa en planned hasta completar con éxito un canary con IdP y cliente SCIM reales.

El billing de Agency y las mutaciones protegidas del Centro de Mando validan ahora el assurance de la sesión en servidor y rechazan usuarios enrolados cuya sesión puede llegar a AAL2 pero sigue en AAL1. Las denegaciones MFA del Centro de Mando quedan registradas sin persistir tokens de acceso ni valores TOTP. El enrolamiento obligatorio por rol sensible y el enforcement universal en RPC/RLS continúan pendientes.

La identidad del candidato Cloudflare y las sondas frescas del runtime son el límite de evidencia productiva. Un check alojado ausente o fallido nunca se convierte silenciosamente en éxito.

MIRMC tiene controles Network Gateway v18 cerrados en source con las nueve superficies privilegiadas registradas evaluadas por red y sin bypass RPC directo conocido en source. ENFORCE productivo continúa planned porque secretos coordinados, conformance de staging, canary medido, evidencia runtime y activación explícita todavía no han sido verificados.

La auditoría del 25 de agosto de 2026 encontró main sin protección ni status checks obligatorios. CODEOWNERS y una política escalonada de ruleset ya están preparados, pero GitHub debe aplicarlos antes de considerar este control implementado.

Ya existe transparencia operativa en vivo y está definido un modelo de operación de incidentes, pero todavía no se afirman como completos el uptime histórico, la evidencia histórica de incidentes ni compromisos contractuales de uptime/remedios.

MIRMC no afirma certificación SOC 2 en este registro de confianza.

MIRMC no afirma certificación ISO 27001 en este registro de confianza.

MIRMC ya tiene objetivos RPO/RTO explícitos de ingeniería y un protocolo aislado de pruebas de restauración, pero esta auditoría todavía no afirma evidencia DR periódica completada ni el cumplimiento verificado de esos objetivos.