Mnemom AEGIS

Réseau défensif multi-tenant pour les agents IA.

Mnemom AEGIS — Adaptive Enforcement, Governance & Intelligence Substrate — est le réseau de sécurité runtime derrière la Safe House. Il filtre chaque transaction d’agent à quatre checkpoints — front door, back door, inside.autonomy, inside.integrity — chacun configurable indépendamment dans quatre modes d’enforcement. Les Managed Rules signées portent un objectif SLO de propagation multi-tenant P95 sous 30 secondes (premières mesures publiées 30 jours après le GA).

AAP déclare. AIP vérifie en vol. CLPI gouverne et ancre. Safe House filtre. AEGIS signe les défenses cross-tenant.

Le modèle de menace.

Sept schémas d'attaque définissent aujourd'hui la surface de menace agentique. Chacun est mappé sur l'un des quatre checkpoints — afin que les clients règlent l'enforcement par surface, et non comme une posture globale unique.

MenaceCheckpointÀ quoi ça ressemble
Prompt injectionfront doorTentatives directes de remplacer les instructions de l'agent, d'inverser son rôle ou de contourner la portée déclarée à la surface entrante.
Injection indirectefront doorInstructions cachées dissimulées dans les documents récupérés, les sorties d'outils et les charges utiles de vector store — le prompt que l'agent ne savait pas avoir reçu.
Mésusage d'outilsinside.autonomyAppels d'outils coercés ou chaînés qui dépassent la portée autorisée de l'Alignment Card. Attaques sur la forme des arguments contre des schémas sous-validés (OWASP ASI02).
Exfiltration de donnéesback doorPII, PHI, secrets, identifiants ou données cross-tenant renvoyés dans les réponses de l'agent, les traces d'erreur ou des schémas de split-token.
Fraude BEC / usurpation d'identitéfront doorRequêtes de type fraude au président, pression d'urgence et d'autorité, ingénierie sociale ciblant le contrat d'escalade de l'agent.
Usurpation d'agentinside.integrityTentatives d'abus d'identité qui revendiquent une autorité que l'Alignment Card ne déclare pas. OWASP ASI03 — Privilege Compromise via Identity Abuse.
Compromission de la supply chaininside.integritySignatures comportementales compatibles avec un SDK compromis, un fine-tune de modèle ou un template de prompt vendoré — détectées cross-tenant via le substrate fingerprinting (OWASP ASI06).

Quatre checkpoints × quatre modes d'enforcement.

Chaque checkpoint est configurable indépendamment. La composition suit le principe strictest-wins de Platform → Org → Team → Agent : le réglage le plus strict de n'importe quelle couche l'emporte toujours. Le fonctionnement est analogue à la façon dont Cloudflare WAF Managed Rules vous laissent définir severity × action par règle.

Mode
off
observe
nudge
enforce
front door
Screening des messages entrants — chaque prompt, charge utile de retrieval et réponse d'outil avant que l'agent ne les traite.
back door
Screening des réponses sortantes — PII, secrets, violations d'Alignment Card, conseils réglementés avant que la réponse ne quitte le périmètre.
inside.autonomy
Screening des appels d'outils — chaque action que l'agent entreprend par rapport aux bornes d'autonomie déclarées par l'Alignment Card.
inside.integrity
Screening de l'intégrité du raisonnement — verdicts AIP sur les charges utiles thinking-block ; signatures de déviation du substrate ; schémas d'abus d'identité.
off

Checkpoint désactivé. Utilisé dans les tenants canary et avant onboarding.

observe

Évalue chaque transaction ; émet des verdicts signés ; ne bloque jamais. Le défaut pour les nouvelles Managed Rules pendant le soak observe de 24 heures.

nudge

Annote ou avertit en ligne sans bloquer. Le terrain intermédiaire pour les règles tier-3 pendant la montée en charge.

enforce

Bloque la transaction et fait remonter un verdict signé au tableau de bord. Atteint uniquement après le soak observe et la discipline d'auto-rollback du taux de FP (CLPI Phase 2).

Cascade de composition : Platform → Org → Team → Agent, strictest-wins. Les admins client peuvent serrer à n'importe quelle couche.

Le pipeline Managed Rules.

Les recipes sont du contenu de détection. Les Managed Rules sont l'état signé du control-plane qui les enveloppe. Le pipeline est contraint structurellement — pas procéduralement — de sorte que les règles tier-1 et tier-2 ne peuvent pas auto-promouvoir, quel que soit le mode défini par l'opérateur.

  1. 1. Arena

    Quinze personas adverses canoniques sondent Safe House 24/7. La mutation-phase gating s'active par bucket uniquement lorsque le taux de détection dépasse 95 % sur une fenêtre glissante de 48 heures avec hystérésis de 24 heures.

  2. 2. Candidate

    Les candidats qui passent l'arène entrent dans une file de revue isolée dotée d'un chemin d'écriture strictement séparé, de sorte que le système qui propose le contenu de détection ne peut jamais être celui qui l'approuve. Les signalements de faux négatifs et de faux positifs des clients ainsi que les signaux réseau cross-tenant convergent tous vers la même file.

  3. 3. Review

    Trois modes de relecture — manual (défaut), auto-approve-trusted-sources, auto-approve-high-confidence. Les tier-1 / tier-2 exigent toujours une relecture en dual-control sous une chaîne d'audit append-only.

  4. 4. Soak observe 24h

    Chaque promotion signée atterrit en mode observe pendant 24 heures. L'auto-rollback sur taux de FP selon CLPI Phase 2 retire la recipe avant que tout trafic de production ne soit bloqué.

  5. 5. Enforce

    Le failover tiered KV+R2+isolate-cache avec chaînes de signature indépendantes pousse la règle vers chaque gateway. P95 ≤ 30 s entre promotion signée et chargement gateway.

L'invariant protecteur

Une Managed Rule de tier-1 ou tier-2 — celle qui bloquerait réellement du trafic de production — ne peut jamais être promue sans une revue humaine à deux personnes, quelle que soit l'agressivité du mode d'auto-promotion. La garantie est appliquée structurellement, dans le modèle de données lui-même : une règle active ne peut exister tant que son quorum de revue n'a pas été atteint. C'est une propriété du système, et non une procédure que quelqu'un doit penser à suivre.

Garanti par le modèle de données, et non par la discipline de l'opérateur.

Substrate fingerprinting + détection de supply chain.

Chaque évaluation est estampillée d'un substrate fingerprint — le fournisseur, le modèle et la version du SDK à l'origine de la requête, plus un lockfile hash facultatif fourni par le client et envoyé via l'en-tête `X-Mnemom-Lockfile-Hash`. AEGIS observe la déviation comportementale sur l'ensemble des clients exécutés sur le même substrate, simultanément.

Le 11 mai 2026 — le ver Mini Shai-Hulud a compromis plus de 170 paquets npm et 2 paquets PyPI, dont la suite SDK de Mistral AI et le paquet PyPI de Guardrails AI. Les versions compromises de `@tanstack/*` étaient livrées avec des attestations SLSA Build Level 3 valides — le premier cas documenté d'un ver produisant une provenance signée légitime pour des paquets malveillants. La détection par tenant et la vérification Sigstore au niveau du paquet ne peuvent structurellement pas attraper cette classe d'attaque.

OWASP Top 10 for Agentic Applications.

Mapping honnête. Là où la couverture est partielle, nous le disons. La taxonomie OWASP ASI complète (déc. 2025) est sur owasp.org.

Catégorie OWASPCouvertureComment AEGIS la traite
ASI02 — Tool Misuse
Complète
Policy engine (CLPI Phase 1) + Managed Rules au checkpoint inside.autonomy. Screening des appels d'outils par rapport aux bornes d'autonomie déclarées par l'Alignment Card.
ASI03 — Privilege Compromise via Identity Abuse
Complète
Bornes d'autonomie déclarées par AAP (Alignment Card) + verdicts d'intégrité en vol AIP + screening au checkpoint inside.integrity pour les schémas d'abus d'identité.
ASI06 — Agentic Supply Chain Compromise
Complète (runtime)
Substrate fingerprinting sur chaque évaluation. L'agrégateur cross-tenant détecte les déviations comportementales qu'aucun client seul ne peut voir. Complète — ne remplace pas — la provenance au niveau des paquets (SLSA, Sigstore).
ASI07 — System Prompt Leakage
Partielle
Screening au checkpoint back-door des schémas de system prompt connus + secrets et violations d'Alignment Card. La détection est basée sur le contenu ; les agents qui citent légitimement leur system prompt à la demande de l'utilisateur ne sont pas supprimés.

ASI01 (Prompt Injection), ASI04 (Resource Exhaustion), ASI05 (Cascading Hallucination), ASI08 (Repudiation & Untraceability), ASI09 (Identity Spoofing), ASI10 (Overreliance) sont mappées sur d'autres parties du stack Mnemom (AAP cards, verdicts AIP, ancrage on-chain CLPI, Trust Ratings) — couvertes sur /protection-network et /trust.

Comment AEGIS se compare.

Abrégé de la recherche sur le paysage concurrentiel du 23 mai 2026. AEGIS est la couche réseau ; les vendors ci-dessous sont complémentaires, pas des remplacements — voir /governance pour l'histoire d'intégration complète.

CapacitéMnemom AEGISCloudflare WAFLakera GuardCisco AI DefenseAWS Bedrock GuardrailsGoogle Model Armor
Managed Rules cross-tenant avec promotion signée
Oui — signées Ed25519, propagation P95 ≤ 30 s, chaîne d'audit publique
Managed Rules WAF (couche web, pas couche agent)Threat-intel curée par le vendor ; aucun signal issu du réseau clientSDK embed au build-time ; pas de réseau cross-tenant runtimeAWS uniquement ; pas d'apprentissage cross-clientFiltre in-process ; pas de réseau
Modèle quatre-checkpoints × quatre-modes par agent
Oui — front door / back door / inside.autonomy / inside.integrity, chacun configurable indépendamment
Règles WAF par route ; pas façonnées pour la transaction agentDétecteur unique au runtimeIntégration NeMo Guardrails ; policy au build-timeBedrock Guardrails par politique (denylist, PII, contextual grounding)Filtres prompt-injection + URL + contenu nuisible
Substrate fingerprinting (provider + model + version du SDK) sur chaque évaluation
Oui — détection cross-tenant de supply chain
NonNonNonNonNon
IoC feed public STIX 2.1 + advisories signés
Oui — /v1/trust/iocs (vide au GA par design)
Feeds Radar internes au client uniquementAucun feed publicTalos pour les menaces traditionnelles ; aucun IoC feed agent publicNonNon
Invariant de dual-control sur tier-1/-2 (appliqué dans le modèle de données)
Oui — appliqué par le schéma, pas procédural
Change-management procéduralContrôlé par le vendorContrôlé par le vendorIAM de policy clientContrôlé par le vendor

Sources : documentation publique des vendors, 23 mai 2026. AEGIS est une couche que les clients exécutent en parallèle de ces produits, pas un remplacement.

SLO publiés. Mesurés en continu.

Chiffres principaux ci-dessous. Le tableau complet — requêtes de mesure, données historiques une fois la première fenêtre de 30 jours close, et les quatre SLO de soutien — vit sur /trust/slos.

Propagation de Managed Rule
P95 ≤ 30 s

Promotion signée → chargée sur le gateway. Cible publiée ; premières mesures 30 jours après le GA.

Disponibilité du failover
99,99 %

Le gateway charge un jeu de règles vérifié à travers plusieurs niveaux de lecture indépendants.

Fraîcheur du rule-set
P99 ≤ 5 min

En fonctionnement normal. Page P0 à 24h de stale.

La première fenêtre de mesure de 30 jours est publiée 30 jours après le GA. Nous ne préannonçons pas de chiffres que nous ne pouvons pas défendre.

Voir les SLO publiés

Apportez vos outils.

L'IoC feed est en STIX 2.1 lisible par machine. La chaîne d'audit est vérifiable. Le tableau de bord est ouvert à chaque client.

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