Livré
Ce que nous avons livré.
Un journal honnête de ce qui a été mis en ligne, quand et pourquoi cela compte. Pas de vernis marketing — juste les changements, la posture qu'ils débloquent et les justificatifs.
Couverture AGENTS.md mise à jour : six dépôts publics.
L'engagement n°9 (chaque dépôt public Mnemom contient un AGENTS.md) couvre désormais six dépôts publics canoniques : aap, aip, aip-otel-exporter, mnemom-types, reputation-check et docs. mnemom-platform est passé en privé en juin 2026, par décision délibérée ; il contient toujours un AGENTS.md, mais seuls les dépôts publics sont vérifiables de l'extérieur. Version du manifeste : 1.13.0.
- La vérification nocturne contrôle désormais AGENTS.md sur les six dépôts publics canoniques ; les dépôts privés (dont mnemom-platform) conservent AGENTS.md pour les agents internes mais sortent du périmètre de vérification externe.
Connectez-vous à Mnemom via le Model Context Protocol.
Deux serveurs MCP publics sont désormais en service. Le plan de contrôle sur api.mnemom.ai/mcp expose l'API du plan de confiance sous forme d'un ensemble d'outils reprenant la CLI mnemom — appelez d'abord get_started (sans authentification, sans argument) pour la cartographie ; un serveur de recherche documentaire en lecture seule sur docs.mnemom.ai/mcp répond aux questions à partir de la documentation et de la spécification OpenAPI. Pointez n'importe quel client MCP vers l'un ou l'autre point d'accès — aucun scraping nécessaire.
- <code>api.mnemom.ai/mcp</code> — serveur MCP du plan de contrôle (streamable-HTTP) doté d'outils couvrant les Trust Ratings, les Alignment & Protection Cards, la gouvernance, les postures, les équipes, les webhooks et les clés d'API. <code>tools/list</code> est public ; l'exécution des outils s'authentifie exactement comme l'API REST (JWT Bearer ou <code>X-Mnemom-Api-Key</code>).
- <code>docs.mnemom.ai/mcp</code> — recherche documentaire en lecture seule. Le plan de contrôle publie une fiche découvrable à <code>/.well-known/mcp/server-card.json</code>, et des configurations client prêtes à copier sont disponibles sur <code>/for-agents</code> et dans la documentation.
Les agents peuvent découvrir comment s'enregistrer et s'authentifier, de bout en bout.
Les métadonnées de ressource protégée de l'API Mnemom pointent désormais vers des métadonnées d'authorization-server propriétaires qui embarquent un profil d'enregistrement agent_auth — un agent peut ainsi trouver l'API, apprendre que l'émission des jetons est déléguée à Supabase et suivre le véritable flux register → claim sans lire la moindre documentation en prose.
- <code>/.well-known/oauth-protected-resource</code> (RFC 9728) répertorie désormais les métadonnées d'authorization-server propriétaires de Mnemom sur www.mnemom.ai, aux côtés de l'émetteur Supabase GoTrue en amont.
- <code>/.well-known/oauth-authorization-server</code> (RFC 8414) déclare <code>issuer: https://www.mnemom.ai</code>, délègue l'émission des jetons à Supabase et ajoute un profil <code>agent_auth</code> qui associe <code>register_uri</code> / <code>claim_uri</code> / <code>rekey_uri</code> aux véritables points d'accès <code>/v1/agents</code> — nous n'émettons toujours aucun jeton OAuth qui nous soit propre.
Les surfaces standard de découverte d'agents sont publiées et résolvables.
Un agent sans connaissance préalable peut désormais trouver l'API Mnemom, apprendre comment s'authentifier et voir quelles compétences il peut invoquer — entièrement à partir de fichiers standard sur www.mnemom.ai. Chaque URL renvoie vers quelque chose de réel ; rien n'est aspirationnel.
- <code>/.well-known/api-catalog</code> (RFC 9727) pointe vers la spécification OpenAPI 3.1 en service ; <code>/.well-known/oauth-protected-resource</code> (RFC 9728) désigne l'API Mnemom comme ressource protégée, et <code>/.well-known/oauth-authorization-server</code> (RFC 8414) délègue l'émission des jetons à notre IdP en amont (Supabase GoTrue) tout en embarquant un profil <code>agent_auth</code> pour l'enregistrement des agents Mnemom. Nous n'émettons pas nos propres jetons d'accès OAuth — c'est énoncé clairement dans <code>/auth.md</code>.
- <code>/.well-known/agent-skills/*</code> répertorie les compétences invocables adossées uniquement à de véritables points d'accès publics, et <code>/.well-known/agent-card.json</code> fournit une fiche de service de type A2A ; des directives Content-Signal dans robots.txt déclarent notre posture vis-à-vis de la recherche et de l'IA.
- Ajout de l'engagement <code>api-auth-discovery</code> au manifeste de préparation des agents, vérifié chaque nuit en production.
AEGIS L5 : advisories publics et flux d'IoC STIX 2.1 en service.
La surface de transparence du Protection Network est ouverte. /trust/advisories publie des comptes rendus post-incident signés ; /v1/trust/iocs sert un bundle d'indicateurs STIX 2.1. Vide par conception au moment de la GA — le système dit la vérité.
- <code>/trust/advisories</code> est en service avec son premier post-mortem synthétique, clairement étiqueté comme synthétique conformément au calm-at-GA contract.
- /v1/trust/iocs renvoie un bundle STIX 2.1, authentifié et limité en débit, prêt pour les pipelines de threat intelligence (curl + JSON-LD).
- Les nouveaux événements webhook <code>advisory.published</code> et <code>ioc.added</code> rejoignent le catalogue, afin que les pipelines de threat intelligence puissent réagir dès que le Protection Network publie.
Le threat thermometer lit désormais en direct l'état par axe du Protection Network.
Les clients voient désormais le panorama des menaces cross-tenant à <code>/dashboard/threats</code> : état par axe sur le substrat, le secteur vertical, le schéma et la source, actualisé toutes les 30 secondes. Calm at GA, by design.
- <code>GET /v1/network/threat-state</code> renvoie une agrégation par axe du panorama en direct du Protection Network, prête à être interrogée depuis vos tableaux de bord.
- Une page de tableau de bord à <code>/dashboard/threats</code> est livrée avec quatre cartes par axe et une carte de totaux.
- Un nouvel événement <code>network.threat_level.changed</code> vous permet de relier les transitions de niveau de menace directement à votre propre système d'alerte.
Agrégateur cross-tenant L1 : statistiques glissantes d'état de campagne entre clients.
Les statistiques glissantes par axe corrèlent désormais les signaux entre l'arena, le Sideband et le trafic d'integrity-checkpoint — le moteur de corrélation cross-tenant qui voit les campagnes qu'aucun client seul ne pourrait voir.
- Le moteur de corrélation joint les empreintes par axe entre les signaux d'integrity, d'arena et de Sideband pour construire un état au niveau campagne qu'aucun tenant seul ne peut voir.
- Machine à états par bucket avec hystérésis à fenêtre de 6 h en sortie ; états reliés à cells.ts via quatre cells campaign_state concrètes (safe-house-hardening#246).
- Le moteur s'actualise en continu, maintenant à jour le panorama cross-tenant sur l'ensemble du Protection Network.
Les webhooks Safe House par évaluation (sh.*) sont câblés de bout en bout.
Cinq événements front-door de Safe House rejoignent le catalogue AEGIS avec des contrôles de mode de livraison par organisation — un prérequis pour l'intégration SOC/SIEM. Fait passer le catalogue de webhooks AEGIS-GA de 10 à 15 événements entièrement câblés.
- Les nouveaux événements webhook <code>sh.evaluation.warn</code> / <code>quarantine</code> / <code>block</code> se déclenchent à chaque point de verdict, plus <code>sh.canary.triggered</code> lorsqu'un canari se déclenche et <code>sh.session.escalated</code> lorsqu'une session franchit un palier de risque.
- Des modes de livraison par organisation (complet, échantillonné à 10 % ou résumé uniquement) gardent les organisations à fort trafic sous contrôle, avec une livraison signée HMAC sur chaque événement.
- 13 cells sh_emission dans le harness fixent chaque chemin de déclenchement checkpoint × mode (safe-house-hardening#247).
Arène adversariale continue : 15 personas canoniques, modèle de mutation-phase.
L'arène adversariale couvre désormais chaque type de menace canonique sur les quatre checkpoints de Safe House. Les découvertes qui passent au travers alimentent directement le pipeline Managed Rules.
- Les 15 personas couvrent désormais chaque type de menace canonique sur les quatre checkpoints de Safe House, y compris un archétype de supply-chain à inside.integrity.
- Fournit un modèle de mutation-phase gating par bucket (hystérésis 0,90↔0,95) qui régulera l'évolution des attaques en fonction du taux de détection.
- Les attaques qui déjouent la détection sont capturées automatiquement comme candidats Managed Rules sur un chemin isolé et estampillé d'attribution — sans humain dans la boucle pour perdre une découverte.
Les signalements client de faux négatifs et faux positifs alimentent le pipeline Managed Rules.
Le signal client est désormais une source de premier ordre. Les signalements transitent par un point d'accès authentifié, une commande CLI et un pipeline d'e-mails d'accusé de réception livré en cinq langues — alimentant la même file de relecture des candidats que l'arène et l'agrégateur cross-tenant.
- Le point d'accès de signalement est en service, avec une diffusion du webhook <code>recipe.candidate.created</code> vers votre compte chaque fois qu'un signalement devient un candidat de règle.
- Les commandes <code>mnemom recipes report-fn</code> et <code>report-fp</code> sont disponibles dans la CLI @mnemom/mnemom.
- E-mail d'accusé de réception de FN client rendu en en/fr/de/it/es via le pipeline de templates Track D.
Trois modes de relecteur — avec un invariant structurel de double contrôle sur les tiers 1-2.
Les administrateurs de la plateforme peuvent basculer le mode de relecteur entre manuel, auto-approbation des sources de confiance et auto-approbation haute confiance. L'invariant protecteur est structurel, pas procédural : les règles de tier-1 et tier-2 ne peuvent jamais être promues automatiquement sans double contrôle humain, quel que soit le mode.
- Le mode de relecteur et le seuil persistent à l'échelle de la plateforme et sont lus et écrits via <code>/v1/admin/settings/reviewer-mode</code>, chaque modification étant inscrite dans la piste d'audit.
- Le contrôle administrateur du mode de relecteur est livré avec une étape de confirmation et une attribution d'audit complète à chaque modification.
- Trois cells reviewer_mode concrètes verrouillent l'invariant : trusted-sources promeut le tier-3, high-confidence insère UNE approbation sur le tier-1 mais ne promeut PAS, manual bloque toute auto-approbation (safe-house-hardening#245).
File de relecture administrateur avec chaîne d'audit en ajout seul.
Les administrateurs de la plateforme trient désormais les candidats de Managed Rules depuis une file dédiée : approuver, rejeter, modifications requises ou promouvoir. Chaque action se matérialise par un INSERT réservé au rôle de service sur une chaîne en ajout seul — la surface d'audit sur laquelle les RSSI et les régulateurs peuvent s'appuyer.
- Chaque action de relecture se matérialise sur une chaîne en ajout seul, ancrée à la création du candidat et courant jusqu'à la promotion ou la mise hors service — la surface d'audit sur laquelle les RSSI et les régulateurs peuvent s'appuyer.
- Une interface de file de relecture administrateur est livrée avec le détail complet des règles et la télémétrie.
- Chaque transition d'état émet un signal de gouvernance, et aucune règle ne peut devenir active sans validation à double contrôle — une approbation à deux personnes imposée par la plateforme, et non par la politique.
Managed Rules signées Ed25519 avec double écriture KV+R2 et un soak d'observation de 24 h.
Promouvoir une recipe en Managed Rule est désormais un événement signé cryptographiquement. Chaque règle est signée Ed25519, servie en fail-closed et acheminée par un soak d'observation de 24 heures avant son entrée en application.
- La promotion signe cryptographiquement chaque règle ; les passerelles vérifient la signature et servent via un chemin de lecture à plusieurs niveaux, fail-closed, avec une cible de propagation P95 inférieure à 30 s.
- La surveillance du taux de FP retire les recettes qui dépassent le seuil — confirmé par un opérateur à la cadence de publication actuelle, automatique en Phase 2 de CLPI.
- Prend en charge un balayage nocturne pour retirer les règles sans aucune occurrence après 90 jours, gardant l'ensemble des règles actives épuré.
Empreinte de substrat : chaque évaluation porte désormais l'axis identity L0.
Le fingerprinting de substrat est en service. Chaque integrity checkpoint, tentative d'arène et analyse Sideband est désormais estampillé d'empreintes de substrat, de secteur vertical, de schéma et de source — la clé de corrélation cross-tenant qui détecte les écarts comportementaux chez chaque client opérant sur le même substrat.
- Chaque évaluation est désormais estampillée de son empreinte de substrat à quatre axes au moment de l'écriture — déployé en production.
- Le modèle de données sous-jacent du Protection Network est en place, avec une isolation au niveau des lignes appliquée dès la première écriture.
- Les règles se composent comme des cards — Platform → Org → Team → Agent, la plus stricte l'emporte.
Détecteurs Safe House renforcés sur les classes de prompt injection et de fuite de PII.
Les détecteurs front-door et back-door ont reçu une passe de calibration. Moins de faux positifs sur les appels d'outils légitimes, un taux de blocage plus net sur les nouveaux schémas d'injection — sans élargir les données que nous collectons.
- Détecteurs de prompt injection réentraînés sur un corpus adversarial récent ; 12 % de faux positifs en moins.
- Le filtrage back-door capte désormais les fuites de PII sur tokens fragmentés (par ex. numéros de sécurité sociale ou de carte répartis sur plusieurs chunks streamés).
- Le format de verdict signé inclut désormais la version du détecteur, afin que les auditeurs puissent reproduire le classifieur exact utilisé.
L'identité d'agent par passkey et clé matérielle est active.
Les agents peuvent désormais être liés à une passkey ou à une clé matérielle dès le premier jour. La signature Ed25519 reste le défaut ; l'identité d'agent adossée à WebAuthn est disponible pour les équipes qui veulent un onboarding d'agent infalsifiable.
- Attestation WebAuthn prise en charge pour l'enrôlement d'agents.
- La rotation d'identité d'agent ne casse pas les chaînes de preuves historiques ; les anciennes clés restent vérifiables.
- Fonctionne sur la passerelle auto-hébergée comme sur les tenants managés.
La passerelle auto-scale désormais au plafond M0 sans changement côté opérateur.
Travail de fiabilité en coulisse. La passerelle managée provisionne élastiquement pour les pics de trafic jusqu'au plafond M0 sans aucune config côté tenant. Les déploiements auto-hébergés récupèrent les mêmes défauts d'autoscaler dans le chart Helm.
- Auto-scale de 2 à 10 réplicas selon un CPU soutenu > 70 %.
- Chemin de démarrage à froid réduit de 40 % pour l'image auto-hébergée.
- Aucun changement de tarif — la montée en charge reste dans le plafond de votre palier.
Voyez ce que la plateforme prouve réellement.
Chaque changement livré étaie l'une de deux affirmations : ce que nous prouvons, ou comment nous protégeons vos agents.
