Mnemom AEGIS

Red defensiva multi-tenant para agentes de IA.

Mnemom AEGIS — Adaptive Enforcement, Governance & Intelligence Substrate — es la red de seguridad en runtime detrás de la Safe House. Examina cada transacción del agente en cuatro checkpoints — front door, back door, inside.autonomy, inside.integrity — cada uno configurable de forma independiente en cuatro modos de enforcement. Las Managed Rules firmadas portan un objetivo SLO de propagación multi-tenant P95 por debajo de 30 segundos (primeras mediciones publicadas 30 días tras el GA).

AAP declara. AIP verifica en vuelo. CLPI gobierna y ancla. Safe House filtra. AEGIS firma las defensas cross-tenant.

El modelo de amenazas.

Siete patrones de ataque definen hoy la superficie de amenaza agéntica. Cada uno se mapea a uno de los cuatro checkpoints — de modo que los clientes regulan el enforcement por superficie, no como una postura global única.

AmenazaCheckpointCómo se ve
Prompt injectionfront doorIntentos directos de sobrescribir las instrucciones del agente, invertir su rol o esquivar el scope declarado en la superficie entrante.
Inyección indirectafront doorInstrucciones ocultas escondidas dentro de documentos recuperados, salidas de tool y payloads de vector store — el prompt que el agente nunca supo que había recibido.
Uso indebido de toolinside.autonomyLlamadas a tool coaccionadas o encadenadas que exceden los límites de autonomía declarados por el agente o violan la superficie protegida de la Protection Card de la organización (operaciones prohibidas, activos protegidos). Ataques sobre la forma de los argumentos contra esquemas insuficientemente validados (OWASP ASI02).
Exfiltración de datosback doorPII, PHI, secretos, credenciales o datos cross-tenant devueltos en respuestas del agente, trazas de error o patrones de split-token.
Fraude BEC / suplantaciónfront doorSolicitudes al estilo fraude del CEO, presión de urgencia y autoridad, ingeniería social que apunta al contrato de escalado del agente.
Suplantación de agenteinside.integrityIntentos de abuso de identidad que reclaman una autoridad no declarada por la Alignment Card. OWASP ASI03 — Identity & Privilege Abuse.
Compromiso de la supply chaininside.integrityFirmas de comportamiento consistentes con un SDK comprometido, un fine-tune de modelo o una plantilla de prompt vendored — detectadas cross-tenant vía substrate fingerprinting (OWASP ASI04).

Cuatro checkpoints × cuatro modos de enforcement.

Cada checkpoint es configurable de forma independiente. La composición sigue el principio strictest-wins a través de Platform → Org → Team → Agent, de modo que el ajuste más estricto de cualquier capa siempre prevalece. Funciona de forma análoga a cómo Cloudflare WAF Managed Rules le permiten definir severity × action por regla.

Modo
off
observe
nudge
enforce
front door
Screening de mensajes entrantes — cada prompt, payload de retrieval y respuesta de tool antes de que el agente los procese.
back door
Screening de respuestas salientes — PII, secretos, violaciones de Alignment Card, consejo regulado antes de que la respuesta abandone el perímetro.
inside.autonomy
Screening de llamadas a tool — cada acción que el agente ejecuta contra los límites de autonomía declarados por la Alignment Card y la superficie protegida de la Protection Card de la organización (operaciones prohibidas, activos protegidos).
inside.integrity
Screening de la integridad del razonamiento — veredictos AIP sobre payloads thinking-block; firmas de desviación del substrate; patrones de abuso de identidad.
off

Checkpoint deshabilitado. Usado en tenants canary y antes del onboarding.

observe

Evalúa cada transacción; emite veredictos firmados; nunca bloquea. El valor por defecto para nuevas Managed Rules durante el soak observe de 24 horas.

nudge

Anota o advierte en línea sin bloquear. El término medio para reglas tier-3 durante la fase de ramp-up.

enforce

Bloquea la transacción y presenta un veredicto firmado en el panel. Se alcanza únicamente tras el período de reposo en observe y la disciplina de reversión por tasa de FP — confirmado por el operador hoy, automático en la Fase 2 de CLPI.

Cascada de composición: Platform → Org → Team → Agent, strictest-wins. Los admins de cliente pueden ajustar más estricto en cualquier capa.

El pipeline Managed Rules.

Las recipes son contenido de detección. Las Managed Rules son el estado firmado del control-plane que las envuelve. El pipeline está restringido estructuralmente — no procedimentalmente — de modo que las reglas tier-1 y tier-2 no pueden auto-promocionarse, sin importar el modo fijado por el operador.

  1. 1. Arena

    Quince personas adversarias canónicas sondean Safe House 24/7. La mutation-phase gating se activa por bucket solo cuando la tasa de detección cruza el 95 % sobre una ventana móvil de 48 horas con histéresis de 24 horas.

  2. 2. Candidate

    Los candidatos que superan la arena entran en una cola de revisión aislada con una ruta de escritura estrictamente separada, de modo que el sistema que propone el contenido de detección nunca puede ser el mismo que lo aprueba. Los informes de falsos negativos y falsos positivos de los clientes y las señales de red cross-tenant confluyen todos en la misma cola.

  3. 3. Review

    Tres modos de reviewer — manual (por defecto), auto-approve-trusted-sources, auto-approve-high-confidence. Tier-1 / tier-2 requieren siempre review en dual-control bajo una cadena de auditoría append-only.

  4. 4. Soak observe 24h

    Cada promoción firmada aterriza en modo observe durante 24 horas. La monitorización de la tasa de FP retira la recipe antes de que se bloquee cualquier tráfico de producción — confirmado por el operador hoy, automático en la Fase 2 de CLPI.

  5. 5. Enforce

    El failover tiered KV+R2+isolate-cache con cadenas de firma independientes empuja la regla a cada gateway. P95 ≤ 30 s entre promotion firmada y carga en gateway.

El invariante protector

Una Managed Rule de tier-1 o tier-2 — una que realmente bloquearía tráfico de producción real — nunca puede promocionarse sin una revisión humana de dos personas, por muy agresivo que esté configurado el modo de auto-promoción. La garantía se impone de forma estructural, en el propio modelo de datos: una regla activa no puede existir mientras no se haya alcanzado su quórum de revisión. Es una propiedad del sistema, no un procedimiento que alguien deba recordar seguir.

Garantizado por el modelo de datos, no por la disciplina del operador.

Substrate fingerprinting + detección de supply chain.

Cada evaluación se sella con un substrate fingerprint — el proveedor, el modelo y la versión del SDK detrás de la solicitud, más un lockfile hash opcional aportado por el cliente y enviado mediante la cabecera `X-Mnemom-Lockfile-Hash`. AEGIS observa la desviación de comportamiento en todos los clientes que se ejecutan sobre el mismo substrate, de forma simultánea.

El 11 de mayo de 2026 — el gusano Mini Shai-Hulud comprometió más de 170 paquetes npm y 2 paquetes PyPI, incluyendo la suite SDK de Mistral AI y el paquete PyPI de Guardrails AI. Las versiones comprometidas de `@tanstack/*` se distribuyeron con atestaciones SLSA Build Level 3 válidas — el primer caso documentado de un gusano produciendo provenance firmada legítima para paquetes maliciosos. La detección por tenant y la verificación Sigstore a nivel de paquete no pueden estructuralmente capturar esta clase de ataque.

OWASP Top 10 for Agentic Applications.

Mapeo honesto frente a la autoridad OWASP Top 10 para Aplicaciones Agénticas (OWASP Gen AI Security Project, publicado el 09-12-2025). Donde la cobertura es parcial o ausente, lo decimos — consulta la taxonomía ASI completa en genai.owasp.org.

OWASP Top 10 para Aplicaciones Agénticas (genai.owasp.org)

Categoría OWASPCoberturaCómo la aborda AEGIS
ASI02 — Tool Misuse
Partial
Motor de políticas (CLPI Fase 1) con aplicación de acciones acotadas + Managed Rules con reglas de prohibición en el checkpoint inside.autonomy, más el cribado de back-door para exfiltración de datos vía herramientas. La aplicación del alcance declarado es el control principal; Mnemom no intercepta cada invocación insegura de herramienta en el gateway.
ASI03 — Identity & Privilege Abuse
Full
Límites de autonomía declarados por AAP (Alignment Card) aplicados por el motor de políticas CLPI + veredictos de integridad AIP en vuelo + cribado en el checkpoint inside.integrity de reclamaciones de privilegio/abuso de identidad en tiempo de ejecución.
ASI04 — Agentic Supply Chain Vulnerabilities
Full (runtime)
El fingerprinting de sustrato en cada evaluación + el agregador entre inquilinos detectan desviaciones de comportamiento en tiempo de ejecución consistentes con una dependencia/sustrato comprometido que ningún cliente individual puede ver. Complementa — no reemplaza — la procedencia de paquetes en tiempo de compilación (SLSA, Sigstore).
ASI07 — Insecure Inter-Agent Communication
Partial
El checkpoint de back-door trata como sospechosas por diseño las reclamaciones de autoridad/identidad no autenticadas que llegan como mensajes entrantes en tiempo de ejecución. Esto criba el contenido de los mensajes entre agentes; la autoridad legítima de agente a agente debe codificarse en las Alignment Cards. No es un esquema de autenticación de transporte.

Las categorías restantes se cubren en otras partes del stack de Mnemom, expuestas con honestidad: ASI01 (Agent Goal Hijack) — cribado front-door de Safe House, entregado para inyección directa y cubriendo sustancialmente el secuestro de objetivos multironda (residual en secuencias multironda/multivector novedosas); ASI09 (Human-Agent Trust Exploitation) — detección front-door entregada de manipulación de autoridad/urgencia/secreto; ASI10 (Rogue Agents) — cubierto en la capa de gobernanza (Alignment Cards de AAP + ciclo de vida CLPI + Trust Ratings), no un único patrón front-door. Brechas honestas: ASI05 (Unexpected Code Execution) y ASI06 (Memory & Context Poisoning) hoy no se interceptan en el front-door (el motor de políticas reduce la superficie de acción; AIP da observabilidad parcial aguas abajo — combínalo con un sandbox de capa de aplicación / trata la memoria como entrada no confiable), y ASI08 (Cascading Failures) es una cuestión de arquitectura de aplicación (timeouts, bulkheads, circuit breakers). Ver /protection-network y /trust.

Marco de Gestión de Riesgos de IA del NIST.

Cómo los controles de runtime ya entregados de Mnemom respaldan las cuatro funciones del NIST AI RMF. Mapeo honesto — Mnemom es un sustrato de confianza en runtime, no un programa de gestión de riesgos de IA; donde una función es responsabilidad organizativa del cliente, lo decimos.

NIST AI Risk Management Framework (AI RMF 1.0)

Función del AI RMFCoberturaCómo lo respalda Mnemom
GOVERN
Partial
Alignment Card como artefacto de política legible por máquina por agente (principal, supervisión, límites de autonomía) + gobernanza de ciclo de vida CLPI + promoción de Managed Rules con doble control. Tu programa de gobernanza organizativa (roles, autoridad de aprobación, incorporación de modelos de terceros) sigue siendo tuyo.
MAP
Partial
La Alignment Card enmarca el propósito + los límites declarados de autonomía/integridad de cada agente; la clasificación de riesgo del EU AI Act + el mapeo OWASP Agentic Top 10 enmarcan el contexto de riesgo. Enmarcado por agente entregado; el enmarcado de toda la cartera es del cliente.
MEASURE
Partial
Checkpoints + veredictos de integridad de AIP (por decisión), el Trust Rating (0–1000), los SLIs publicados en trust.mnemom.ai/slos, la telemetría de falsos positivos de Safe House y el substrate fingerprinting de AEGIS. Medición de runtime en vivo; la evaluación de modelos previa al despliegue es complementaria + la ejecuta el cliente.
MANAGE
Partial
La aplicación de acciones acotadas del Policy Engine + Safe House observe/nudge/enforce tratan el riesgo detectado; el CMS de avisos + el transparency log comunican incidentes; el failover de AEGIS + el respondedor siempre activo gestionan respuesta/recuperación. La asignación de recursos de riesgo + el proceso de IR de tu organización siguen siendo tuyos.

"Parcial" es honesto: el AI RMF es un marco voluntario y no certificable que opera tu organización. Mnemom aporta los controles de runtime + la evidencia verificable de la que puede valerse cada función; no exime de tus responsabilidades GOVERN ni certifica conformidad. Mapeo completo en /guides/eu-compliance.

Cómo se compara AEGIS.

Resumen de la investigación del panorama competitivo del 23 de mayo de 2026. AEGIS es la capa de red; los vendors abajo son complementarios, no reemplazos — vea /governance para la historia de integración completa.

CapacidadMnemom AEGISCloudflare WAFLakera GuardCisco AI DefenseAWS Bedrock GuardrailsGoogle Model Armor
Managed Rules cross-tenant con promotion firmada
Sí — firmadas con Ed25519, propagación P95 ≤ 30 s, cadena de auditoría pública
Managed Rules WAF (capa web, no capa de agente)Threat-intel curada por el vendor; ninguna señal derivada de la red de clientesSDK embed en build-time; ninguna red cross-tenant en runtimeSolo AWS; sin aprendizaje cross-clienteFiltro in-process; sin red
Modelo cuatro-checkpoints × cuatro-modos por agente
Sí — front door / back door / inside.autonomy / inside.integrity, cada uno configurable de forma independiente
Reglas WAF por ruta; no moldeadas para transacción de agenteDetector único en runtimeIntegración NeMo Guardrails; política en build-timeBedrock Guardrails por política (denylist, PII, contextual grounding)Filtros prompt-injection + URL + contenido dañino
Substrate fingerprinting (provider + model + versión del SDK) en cada evaluación
Sí — detección cross-tenant de supply chain
NoNoNoNoNo
IoC feed público STIX 2.1 + advisories firmados
Sí — /v1/trust/iocs (vacío al GA por diseño)
Solo feeds Radar internos al clienteSin feed públicoTalos para amenazas tradicionales; sin IoC feed agéntico públicoNoNo
Invariante de dual-control en tier-1/-2 (impuesta en el modelo de datos)
Sí — impuesto por el esquema, no procedimental
Change-management procedimentalControlado por el vendorControlado por el vendorIAM de política del clienteControlado por el vendor

Fuentes: documentación pública de los vendors, 23 de mayo de 2026. AEGIS es una capa que los clientes ejecutan junto a estos productos, no un reemplazo.

SLO publicados. Medidos en continuo.

Cifras principales abajo. La tabla completa — consultas de medición, datos históricos una vez se cierre la primera ventana de 30 días, y los cuatro SLO de apoyo — vive en /trust/slos.

Propagación de Managed Rule
P95 ≤ 30 s

Promoción firmada → cargada en el gateway. Objetivo publicado; primeras mediciones 30 días después del GA.

Disponibilidad del failover
99,99 %

El gateway carga un conjunto de reglas verificado a través de múltiples niveles de lectura independientes.

Frescura del rule-set
P99 ≤ 5 min

En operación normal. Page P0 a 24h de staleness.

La primera ventana de medición de 30 días se publica 30 días después del GA. No preanunciamos cifras que no podemos defender.

Ver los SLO publicados

Traiga sus herramientas.

El IoC feed es STIX 2.1 legible por máquina. La cadena de auditoría es verificable. El panel está abierto a cada cliente.

curl -s https://api.mnemom.ai/v1/trust/iocs | jq .
Featured on There's An AI For That