Enviado
Lo que hemos enviado.
Un registro honesto de lo que se puso en producción, cuándo y por qué importa. Sin barniz de marketing — solo los cambios, la postura que habilitan y los comprobantes.
Cobertura de AGENTS.md actualizada a seis repositorios públicos.
El compromiso n.º 9 (cada repositorio público de Mnemom incluye un AGENTS.md) ahora cubre seis repositorios públicos canónicos: aap, aip, aip-otel-exporter, mnemom-types, reputation-check y docs. mnemom-platform pasó a ser privado en junio de 2026 de forma deliberada; sigue incluyendo AGENTS.md, pero solo los repositorios públicos son verificables externamente. Versión del manifiesto: 1.13.0.
- El watchdog nocturno ahora verifica AGENTS.md en los seis repositorios públicos canónicos; los repositorios privados (incluido mnemom-platform) conservan AGENTS.md para agentes internos, pero quedan fuera del alcance de la verificación externa.
Conéctate a Mnemom a través del Model Context Protocol.
Ya están activos dos servidores MCP públicos. El plano de control en api.mnemom.ai/mcp expone la API del plano de confianza como un conjunto de herramientas que reflejan la CLI de mnemom — llama primero a get_started (sin autenticación, sin argumentos) para ver el mapa de la superficie; un servidor de búsqueda de documentación de solo lectura en docs.mnemom.ai/mcp responde preguntas sobre la documentación y la especificación OpenAPI. Apunta cualquier cliente MCP a cualquiera de los dos endpoints — sin necesidad de scraping.
- <code>api.mnemom.ai/mcp</code> — servidor MCP del plano de control (streamable-HTTP) con herramientas para Trust Ratings, Alignment & Protection Cards, gobernanza, posturas, equipos, webhooks y claves de API. <code>tools/list</code> es público; la ejecución de herramientas se autentica exactamente como la API REST (JWT Bearer o <code>X-Mnemom-Api-Key</code>).
- <code>docs.mnemom.ai/mcp</code> — búsqueda de documentación de solo lectura. El plano de control publica una tarjeta detectable en <code>/.well-known/mcp/server-card.json</code>, y hay configuraciones de cliente listas para copiar en <code>/for-agents</code> y en la documentación.
Los agentes pueden descubrir cómo registrarse y autenticarse, de extremo a extremo.
Los metadatos de recurso protegido de la API de Mnemom apuntan ahora a metadatos de authorization-server de origen propio que incorporan un perfil de registro agent_auth — de modo que un agente puede encontrar la API, saber que la emisión de tokens está delegada en Supabase y seguir el verdadero flujo register → claim sin leer documentación en prosa.
- <code>/.well-known/oauth-protected-resource</code> (RFC 9728) ahora enumera los metadatos de authorization-server de origen propio de Mnemom en www.mnemom.ai, junto al emisor Supabase GoTrue de origen.
- <code>/.well-known/oauth-authorization-server</code> (RFC 8414) declara <code>issuer: https://www.mnemom.ai</code>, delega la emisión de tokens en Supabase y añade un perfil <code>agent_auth</code> que asigna <code>register_uri</code> / <code>claim_uri</code> / <code>rekey_uri</code> a los verdaderos endpoints <code>/v1/agents</code> — seguimos sin emitir ningún token OAuth propio.
Las superficies estándar de descubrimiento de agentes están publicadas y son resolubles.
Un agente sin conocimiento previo puede ahora encontrar la API de Mnemom, saber cómo autenticarse y ver qué skills puede invocar — íntegramente a partir de archivos estándar en www.mnemom.ai. Cada URL se resuelve en algo real; nada es aspiracional.
- <code>/.well-known/api-catalog</code> (RFC 9727) apunta a la especificación OpenAPI 3.1 en producción; <code>/.well-known/oauth-protected-resource</code> (RFC 9728) nombra la API de Mnemom como recurso protegido, y <code>/.well-known/oauth-authorization-server</code> (RFC 8414) delega la emisión de tokens en nuestro IdP de origen (Supabase GoTrue) a la vez que incorpora un perfil <code>agent_auth</code> para el registro de agentes de Mnemom. No emitimos tokens de acceso OAuth propios — declarado con claridad en <code>/auth.md</code>.
- <code>/.well-known/agent-skills/*</code> enumera las skills invocables respaldadas únicamente por verdaderos endpoints públicos, y <code>/.well-known/agent-card.json</code> ofrece una tarjeta de servicio de estilo A2A; las directivas Content-Signal en robots.txt declaran nuestra postura ante la búsqueda y la IA.
- Se añadió el compromiso <code>api-auth-discovery</code> al manifiesto de preparación de agentes, verificado cada noche frente a producción.
AEGIS L5: advisories públicos y feed de IoC STIX 2.1 en activo.
La superficie de transparencia del Protection Network está abierta. /trust/advisories contiene informes post-incidente firmados; /v1/trust/iocs sirve un bundle de indicadores STIX 2.1. Vacío por diseño en la GA — el sistema dice la verdad.
- <code>/trust/advisories</code> está en activo con su primer post-mortem sintético, claramente etiquetado como sintético conforme al calm-at-GA contract.
- /v1/trust/iocs devuelve un bundle STIX 2.1, autenticado y con límite de frecuencia, listo para pipelines de threat intelligence (curl + JSON-LD).
- Los nuevos eventos webhook <code>advisory.published</code> e <code>ioc.added</code> se incorporan al catálogo, para que las pipelines de threat intelligence puedan reaccionar en cuanto el Protection Network publica.
El threat thermometer ahora lee en tiempo real el estado por eje del Protection Network.
Los clientes ahora ven el panorama de amenazas cross-tenant en <code>/dashboard/threats</code>: estado por eje en sustrato, vertical, patrón y origen, actualizado cada 30 segundos. Calm at GA, by design.
- <code>GET /v1/network/threat-state</code> devuelve una agregación por eje del panorama en tiempo real del Protection Network, lista para consultar desde tus paneles.
- Una página de panel en <code>/dashboard/threats</code> se entrega con cuatro tarjetas por eje y una tarjeta de totales.
- Un nuevo evento <code>network.threat_level.changed</code> te permite conectar las transiciones de nivel de amenaza directamente con tu propio sistema de alertas.
Agregador cross-tenant L1: estadísticas acumuladas de estado de campaña entre clientes.
Las estadísticas acumuladas por eje ahora correlacionan señales entre arena, Sideband y tráfico de integrity-checkpoint — el motor de correlación cross-tenant que ve las campañas que ningún cliente por sí solo podría ver.
- El motor de correlación une las fingerprints por eje entre las señales de integrity, arena y Sideband para construir un estado a nivel de campaña que ningún tenant por sí solo puede ver.
- Máquina de estados por bucket con histéresis de ventana de 6 h a la salida; estados conectados a cells.ts mediante cuatro cells campaign_state concretas (safe-house-hardening#246).
- El motor se actualiza de forma continua, manteniendo al día el panorama cross-tenant en todo el Protection Network.
Los webhooks Safe House por evaluación (sh.*) están cableados de extremo a extremo.
Cinco eventos front-door de Safe House se incorporan al catálogo AEGIS con controles de modo de entrega por organización — un requisito básico para la integración SOC/SIEM. Lleva el catálogo de webhooks AEGIS-GA de 10 a 15 eventos completamente cableados.
- Los nuevos eventos webhook <code>sh.evaluation.warn</code> / <code>quarantine</code> / <code>block</code> se disparan en cada punto de veredicto, además de <code>sh.canary.triggered</code> cuando se dispara un canary y <code>sh.session.escalated</code> cuando una sesión cruza un nivel de riesgo.
- Los modos de entrega por organización (completo, muestreado al 10% o solo resumen) mantienen bajo control a las organizaciones de alto tráfico, con entrega firmada con HMAC en cada evento.
- 13 cells sh_emission en el harness fijan cada ruta de disparo checkpoint × modo (safe-house-hardening#247).
Arena adversaria continua: 15 personas canónicas, modelo de mutation-phase.
La arena adversaria ahora abarca todos los tipos de amenaza canónicos en los cuatro checkpoints de Safe House. Los hallazgos que se cuelan alimentan directamente la pipeline de Managed Rules.
- Las 15 personas ahora cubren todos los tipos de amenaza canónicos en los cuatro checkpoints de Safe House, incluido un arquetipo de supply-chain en inside.integrity.
- Ofrece un modelo de mutation-phase gating por bucket (histéresis 0,90↔0,95) que regulará la evolución de los ataques según la tasa de detección.
- Los ataques que vencen la detección se capturan automáticamente como candidatos de Managed Rules por una ruta aislada y sellada con atribución — sin humano en el bucle que pueda perder un hallazgo.
Los informes de clientes de falsos negativos y falsos positivos alimentan la pipeline de Managed Rules.
La señal de cliente es ahora una fuente de primer nivel. Los informes pasan por un endpoint autenticado, un comando de CLI y una pipeline de correos de acuse de recibo que se entrega en cinco idiomas — alimentando la misma cola de revisión de candidatos que la arena y el agregador cross-tenant.
- El endpoint de informes está activo, con una difusión del webhook <code>recipe.candidate.created</code> a tu cuenta cada vez que un informe se convierte en candidato de regla.
- Los comandos <code>mnemom recipes report-fn</code> y <code>report-fp</code> están disponibles en la CLI @mnemom/mnemom.
- Correo de acuse de recibo de FN de cliente renderizado en en/fr/de/it/es mediante la pipeline de plantillas Track D.
Tres modos de revisor — con un invariante estructural de doble control en los tiers 1-2.
Los administradores de la plataforma pueden alternar el modo de revisor entre manual, autoaprobación de fuentes de confianza y autoaprobación de alta confianza. El invariante protector es estructural, no procedimental: las reglas de tier-1 y tier-2 nunca pueden promoverse automáticamente sin doble control humano, sea cual sea el modo.
- El modo de revisor y el umbral persisten en toda la plataforma y se leen y escriben a través de <code>/v1/admin/settings/reviewer-mode</code>, registrándose cada cambio en la pista de auditoría.
- El control de administrador del modo de revisor se entrega con un paso de confirmación y atribución de auditoría completa en cada cambio.
- Tres cells reviewer_mode concretas fijan el invariante: trusted-sources promueve el tier-3, high-confidence inserta UNA aprobación en el tier-1 pero NO promueve, manual bloquea toda autoaprobación (safe-house-hardening#245).
Cola de revisión de administrador con cadena de auditoría de solo anexado.
Los administradores de la plataforma ahora clasifican candidatos de Managed Rules desde una cola dedicada: aprobar, rechazar, cambios requeridos o promover. Cada acción se materializa como un INSERT exclusivo del rol de servicio en una cadena de solo anexado — la superficie de auditoría en la que los CISO y los reguladores pueden confiar.
- Cada acción de revisión se materializa en una cadena de solo anexado, anclada en la creación del candidato y que abarca hasta la promoción o la retirada — la superficie de auditoría en la que los CISO y los reguladores pueden confiar.
- Una interfaz de cola de revisión de administrador se entrega con el detalle completo de las reglas y la telemetría.
- Cada transición de estado emite una señal de gobernanza, y ninguna regla puede activarse sin la aprobación de doble control — una aprobación de dos personas impuesta por la plataforma, no por la política.
Managed Rules firmadas con Ed25519 con doble escritura KV+R2 y un soak de observación de 24 h.
Promover una recipe a Managed Rule es ahora un evento firmado criptográficamente. Cada regla se firma con Ed25519, se sirve en fail-closed y se enruta a través de un soak de observación de 24 horas antes de la aplicación.
- La promoción firma criptográficamente cada regla; las pasarelas verifican la firma y sirven a través de una ruta de lectura escalonada, fail-closed, con un objetivo de propagación P95 inferior a 30 s.
- La monitorización de la tasa de FP retira las recipes que superan el umbral — confirmado por el operador en la cadencia de publicación actual, automático en la Fase 2 de CLPI.
- Admite un barrido nocturno para retirar las reglas sin ninguna coincidencia tras 90 días, manteniendo ágil el conjunto de reglas activas.
Fingerprinting de substrato: cada evaluación lleva ahora la axis identity L0.
El fingerprinting de substrato está en servicio. Cada integrity checkpoint, intento en la arena y análisis Sideband se sella ahora con fingerprints de substrato, vertical, patrón y origen — la clave de correlación cross-tenant que detecta desviaciones de comportamiento en cada cliente que opera sobre el mismo substrato.
- Cada evaluación se sella ahora con su fingerprint de substrato de cuatro ejes en el momento de la escritura — desplegado en producción.
- El modelo de datos subyacente del Protection Network está en marcha, con aislamiento a nivel de fila aplicado desde la primera escritura.
- Las reglas se componen como las cards — Platform → Org → Team → Agent, gana la más estricta.
Detectores de Safe House reforzados en las clases de prompt injection y fuga de PII.
Los detectores front-door y back-door han recibido una pasada de calibración. Menos falsos positivos en llamadas a herramientas legítimas, mejor tasa de bloqueo en patrones de injection nuevos — sin ampliar los datos que recopilamos.
- Detectores de prompt injection reentrenados sobre un corpus adversarial reciente; 12 % menos de falsos positivos.
- El filtrado back-door detecta ahora fugas de PII con tokens fragmentados (p. ej. SSN o números de tarjeta repartidos entre chunks en streaming).
- El formato de veredicto firmado incluye ahora la versión del detector, de modo que los auditores pueden reproducir el clasificador exacto utilizado.
La identidad de agente con passkey y clave hardware está en vivo.
Los agentes pueden ahora vincularse a una passkey o a una clave respaldada por hardware desde el primer día. La firma Ed25519 sigue siendo el valor por defecto; la identidad de agente basada en WebAuthn está disponible para equipos que quieren un onboarding infalsificable.
- Atestación WebAuthn soportada para el enrolamiento de agentes.
- La rotación de identidad de agente no rompe las proof chains históricas; las claves antiguas siguen siendo verificables.
- Funciona tanto para el gateway auto-alojado como para los tenants gestionados.
El gateway auto-escala ahora hasta el techo M0 sin cambios del operador.
Trabajo de fiabilidad bajo el capó. El gateway gestionado aprovisiona elásticamente para picos de tráfico hasta el techo del tier M0 sin ninguna configuración del tenant. Los despliegues auto-alojados reciben los mismos valores por defecto del autoscaler en el chart de Helm.
- Auto-escalado de 2 a 10 réplicas con CPU sostenida > 70 %.
- Ruta de arranque en frío reducida un 40 % en la imagen auto-alojada.
- Sin cambio de precio — el escalado se queda dentro del techo de su tier.
Vea lo que la plataforma demuestra de verdad.
Cada cambio enviado respalda una de dos afirmaciones: lo que demostramos o cómo mantenemos seguros a sus agentes.
