# AEGIS — Cross-tenant defensive network for AI agents

```json
{"@context":"https://schema.org","@type":"WebPage","name":"AEGIS \u2014 Red defensiva multi-tenant para agentes de IA","description":"Mnemom AEGIS es la red defensiva multi-tenant detr\u00e1s de la Safe House. Cuatro checkpoints, cuatro modos de enforcement, Managed Rules firmadas, un objetivo de propagaci\u00f3n P95 por debajo de 30 segundos y un IoC feed STIX 2.1 p\u00fablico.","url":"https://www.mnemom.ai/es/security","inLanguage":"es-ES","dateModified":"2026-06-08","publisher":{"@type":"Organization","@id":"https://www.mnemom.ai#organization","name":"Mnemom","url":"https://www.mnemom.ai"}}
```

```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://www.mnemom.ai/es"},{"@type":"ListItem","position":2,"name":"Red defensiva multi-tenant para agentes de IA.","item":"https://www.mnemom.ai/es/security"}]}
```

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.

[Panel del cliente](/es/dashboard)[curl /v1/trust/iocs](https://api.mnemom.ai/v1/trust/iocs)[Contactar ventas](/es/contact)

## 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.

Amenaza

Checkpoint

Cómo se ve

Prompt injection

`front door`

Intentos directos de sobrescribir las instrucciones del agente, invertir su rol o esquivar el scope declarado en la superficie entrante.

Inyección indirecta

`front door`

Instrucciones 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 tool

`inside.autonomy`

Llamadas a tool coaccionadas o encadenadas que exceden el scope permitido por la Alignment Card. Ataques sobre la forma de los argumentos contra esquemas insuficientemente validados (OWASP ASI02).

Exfiltración de datos

`back door`

PII, PHI, secretos, credenciales o datos cross-tenant devueltos en respuestas del agente, trazas de error o patrones de split-token.

Fraude BEC / suplantación

`front door`

Solicitudes 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 agente

`inside.integrity`

Intentos de abuso de identidad que reclaman una autoridad no declarada por la Alignment Card. OWASP ASI03 — Privilege Compromise via Identity Abuse.

Compromiso de la supply chain

`inside.integrity`

Firmas 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 ASI06).

## 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.

`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 hace emerger un veredicto firmado en el panel. Solo se alcanza tras el soak observe y la disciplina de auto-rollback sobre la tasa de FP (CLPI Phase 2).

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 promotion firmada aterriza en modo observe durante 24 horas. El auto-rollback por tasa de FP según CLPI Phase 2 retira la recipe antes de que se bloquee tráfico de producción.
    
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.

[Modelo de amenazas completo en /supply-chain](/es/supply-chain)

## OWASP Top 10 for Agentic Applications.

Mapeo honesto. Donde la cobertura es parcial, lo decimos. La taxonomía OWASP ASI completa (dic. 2025) está en owasp.org.

Categoría OWASP

Cobertura

Cómo la aborda AEGIS

ASI02 — Tool Misuse

Completa

Policy engine (CLPI Phase 1) + Managed Rules en el checkpoint inside.autonomy. Screening de llamadas a tool contra los límites de autonomía declarados por la Alignment Card.

ASI03 — Privilege Compromise via Identity Abuse

Completa

Límites de autonomía declarados por AAP (Alignment Card) + veredictos de integridad en vuelo AIP + screening en el checkpoint inside.integrity para patrones de abuso de identidad.

ASI06 — Agentic Supply Chain Compromise

Completa (runtime)

Substrate fingerprinting en cada evaluación. El agregador cross-tenant detecta desviaciones de comportamiento que ningún cliente por sí solo puede ver. Complementa — no sustituye — la procedencia a nivel de paquete (SLSA, Sigstore).

ASI07 — System Prompt Leakage

Parcial

Screening en el checkpoint back-door de patrones conocidos de system prompt + secretos y violaciones de Alignment Card. La detección es basada en contenido; los agentes que citan legítimamente su system prompt a petición del usuario no se suprimen.

ASI01 (Prompt Injection), ASI04 (Resource Exhaustion), ASI05 (Cascading Hallucination), ASI08 (Repudiation & Untraceability), ASI09 (Identity Spoofing), ASI10 (Overreliance) se mapean a otras partes del stack Mnemom (AAP cards, veredictos AIP, anclaje on-chain CLPI, Trust Ratings) — cubiertas en /protection-network y /trust.

## 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.

Capacidad

Mnemom AEGIS

Cloudflare WAF

Lakera Guard

Cisco AI Defense

AWS Bedrock Guardrails

Google 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 clientes

SDK embed en build-time; ninguna red cross-tenant en runtime

Solo AWS; sin aprendizaje cross-cliente

Filtro 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 agente

Detector único en runtime

Integración NeMo Guardrails; política en build-time

Bedrock 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

No

No

No

No

No

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 cliente

Sin feed público

Talos para amenazas tradicionales; sin IoC feed agéntico público

No

No

Invariante de dual-control en tier-1/-2 (impuesta en el modelo de datos)

Sí — impuesto por el esquema, no procedimental

Change-management procedimental

Controlado por el vendor

Controlado por el vendor

IAM de política del cliente

Controlado 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](/es/trust/slos)

## 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 .
```

[Panel del cliente](/es/dashboard)[curl /v1/trust/iocs](https://api.mnemom.ai/v1/trust/iocs)[Contactar ventas](/es/contact)

---
_Source: /es/security/index.html · Generated by build-markdown-mirrors.mjs · For agent-readability commitment #4 see https://www.mnemom.ai/for-agents_
