Cada cliente se beneficia de cada detección. Mnemom AEGIS — el Adaptive Enforcement, Governance & Intelligence Substrate — alimenta tres loops de señal independientes en una única candidate review queue, luego firma las recipes promovidas y las propaga a cada gateway de la red. Mismo vocabulario que las cards: cuatro checkpoints × cuatro modes de enforcement, Platform → Org → Team → Agent, strictest-wins.
Tres loops de señal independientes. Una cola de revisión. El contenido de detección y los controles de enforcement circulan por la misma maquinaria firmada, de modo que una lección aprendida en cualquier punto llega a todas partes.
Señal 1 — Arena adversarial
15 personas canónicas. Mutation-phase gated. En producción.
Quince personas adversariales cubren todos los tipos de amenaza canónicos en los cuatro checkpoints de Safe House, incluido un topo de cadena de suministro en inside.integrity.
El mutation-phase gating deja evolucionar los ataques solo mientras la detección por bucket se mantiene sobre el umbral, con histéresis sostenida para evitar oscilaciones, evaluado de forma independiente por substrate fingerprint.
El tráfico del arena corre por su propia ruta de escritura aislada, separada de la señal de producción, de modo que los ataques sintéticos nunca puedan contaminar los datos de los clientes. El aislamiento se aplica del lado del servidor, no por convención.
Señal 2 — Informes de clientes
Falsos positivos y falsos negativos, reportados por los clientes que ejecutan los agentes.
Los clientes reportan fallos (falsos negativos) y bloqueos excesivos (falsos positivos) directamente desde el dashboard o a través de la API de report.
Cada informe llega a la misma cola de revisión que alimenta el arena: una única cola compartida, una pipeline firmada, sin importar de dónde proceda la señal.
Calm-at-GA: esta señal existe porque los falsos positivos son inevitables. El mutation-phase gating y el auto-rollback ante falsos positivos se construyen sobre el supuesto de que nos equivocaremos, y de que usted nos lo dirá cuando ocurra.
Señal 3 — Agregador multi-tenant
El worker L1. La visión de la red. El trabajo genuinamente nuevo.
La red mantiene estadísticas móviles para cada substrate fingerprint: la combinación de proveedor, modelo y SDK sobre la que corre un agente. Cada evaluación de la red se estampa con esa fingerprint.
Cuando eventos de seguridad aparentemente no relacionados en distintos clientes comparten una substrate fingerprint, el agregador los enlaza en una única firma de campaña: la vista multi-tenant que ningún cliente individual puede ver por sí solo. En producción.
Esto es lo que nadie más en el mercado tiene. Los guardrails de los hyperscalers, los detectores in-process y los proxies por tenant ven un cliente a la vez. El agregador ve a través de todos ellos.
Tres loops. Un sustrato. Firmado de extremo a extremo.
Tres loops, un substrato: la pipeline de AEGIS de principio a fin.
Arena
15 personas + mutation-phase gate
Señal de cliente
Informes de clientes + telemetría
Agregador multi-tenant
Estadísticas móviles por substrate fingerprint
Tabla de candidates + cola de review
Cada fuente de señal escribe por su propia ruta aislada. Revisión manual por defecto; los modos automáticos son opt-in.
Promoción firmada
Firmado con Ed25519 en la promoción. Las reglas tier-1 y tier-2 exigen revisión por dos personas, aplicada de forma estructural, no por proceso.
Recipes promovidas
Compuestas como las cards. Platform → Org → Team → Agent, strictest-wins.
Gateway — 4 checkpoints × 4 modes
Sobres KV-signed + R2-signed. Objetivo de propagación P95 ≤ 30 segundos en /trust/slos.
La detección de cadena de suministro es una sub-dimensión, no un sistema paralelo. Cada evaluación lleva una substrate fingerprint: proveedor, modelo, SDK version y un lockfile hash opcional. El mismo modelo de cuatro checkpoints lleva cada recipe.
Pipeline de promoción
Cada recipe promovida está firmada. Tier-1 y tier-2 nunca se auto-promueven.
Las tres señales alimentan la misma cola de revisión, y cada recipe promovida viaja por la misma pipeline firmada. El invariante protector está integrado en el sistema de forma estructural: no es un procedimiento ni una política que pueda saltarse.
01
Candidate
Cada señal escribe por su propia ruta aislada. El contenido de la recipe se normaliza a una sola forma, mientras que la fuente de origen permanece adjunta para el rastro de auditoría.
02
Review
Tres modes de reviewer según el patrón Cloudflare-peer: manual (por defecto), auto-approve-trusted-sources, auto-approve-high-confidence. Los candidates tier-3 son elegibles para los auto-modes; tier-1/-2 no — independientemente de la configuración del mode.
03
Promoción firmada
Firmado con Ed25519 en el momento de la promoción. El historial de revisión es append-only. Una regla no puede activarse hasta que se cumpla el quorum de revisión por dos personas.
04
Soak en observe 24h
Cada recipe promovida se entrega en mode observe durante 24 horas, independientemente del tier. La tasa de falsos positivos se muestrea en una ventana móvil de 7 días. Auto-rollback dispara al superar el umbral según CLPI Phase 2.
05
Enforce + propagación
La regla se escribe en dos niveles de almacenamiento, cada uno firmado con una clave independiente, y luego la carga cada gateway, donde las Managed Rules bloquean hoy en producción. El objetivo es una propagación de P95 ≤ 30s, medida de forma continua en /trust/slos.
El invariante protector
Una recipe tier-1 o tier-2 — la que realmente bloquearía tráfico de producción — nunca puede promoverse sin revisión humana por dos personas, por agresiva que sea la configuración del reviewer mode. El sistema lo impone de forma estructural. Los modos automáticos solo aceleran el despliegue de tier-3 (observe / nudge / log), donde el blast radius de una mala decisión está acotado.
Efecto de red vendor-neutral
Substrate-aware en OpenAI, Anthropic, Gemini y cualquier modelo en el gateway de Mnemom.
La substrate fingerprint estampada en cada evaluación incluye el proveedor, el modelo y la SDK version, además de un lockfile hash opcional que los clientes pueden enviar. La señal multi-tenant fluye a través de proveedores, no solo dentro de uno.
Sin lock-in de proveedor.
AEGIS ve desviación de comportamiento atribuida al sustrato a través de cada cliente que corre sobre la misma combinación provider/model/SDK. El flujo de evaluación de un cliente que hace emerger anomalías eleva la protección para cualquier otro cliente sobre ese sustrato — en OpenAI, Anthropic, Gemini o cualquier modelo local situado tras el gateway.
Complementa; no reemplaza.
AEGIS es la capa de red. Los clientes que usan Lakera Guard, NeMo Guardrails, Cloudflare WAF, AWS Bedrock Guardrails o Robust Intelligence pueden ejecutar AEGIS en paralelo — complementa; no reemplaza. Capa distinta, señal distinta.
AAP declara. AIP verifica. AEGIS firma.
AAP hace pública la intención del agente — transparencia, no confianza. AIP entrega los verdicts de integridad en vuelo. CLPI gobierna el ciclo de vida de la card. AEGIS firma las defensas multi-tenant que actúan sobre la imagen integrada. Ninguna capa pretende ser la anterior.
Contrato calm-at-GA
Si la red está en calma, la página dice calma.
En GA el feed IoC está vacío por diseño. La lista de advisories muestra un único post-mortem sintético claramente etiquetado como synthetic. La threat thermometer está en calma. No fingimos actividad. El mutation-phase gating está en producción; la primera activación en producción se informará en /trust/advisories cuando ocurra. El doble control tier-3 está en producción; el doble control tier-1/-2 comienza cuando se incorpore nuestro segundo platform-admin.
Inspeccionar la red.
Tres fuentes de señal. Una pipeline firmada. Cada promoción, cada advisory, cada IoC verificable públicamente.