Rilasciato
Cosa abbiamo rilasciato.
Un registro onesto di cosa è andato live, quando e perché conta. Niente vernice di marketing — solo i cambiamenti, la posture che sbloccano e le prove.
Copertura AGENTS.md aggiornata a sei repository pubblici.
L'impegno n. 9 (ogni repository pubblico Mnemom include un AGENTS.md) copre ora sei repository pubblici canonici: aap, aip, aip-otel-exporter, mnemom-types, reputation-check e docs. mnemom-platform è stato reso privato a giugno 2026 per scelta deliberata; include ancora AGENTS.md, ma solo i repository pubblici sono verificabili dall'esterno. Versione del manifesto: 1.13.0.
- Il watchdog notturno ora verifica AGENTS.md sui sei repository pubblici canonici; i repository privati (incluso mnemom-platform) mantengono AGENTS.md per gli agenti interni ma escono dall'ambito della verifica esterna.
Connettiti a Mnemom tramite il Model Context Protocol.
Due server MCP pubblici sono ora attivi. Il piano di controllo su api.mnemom.ai/mcp espone l'API del piano di fiducia come un set di strumenti che rispecchiano la CLI mnemom — chiama prima get_started (senza autenticazione, senza argomenti) per la mappa della superficie; un server di ricerca documentale in sola lettura su docs.mnemom.ai/mcp risponde alle domande sulla documentazione e sulla specifica OpenAPI. Punta qualsiasi client MCP verso uno dei due endpoint — senza alcuno scraping.
- <code>api.mnemom.ai/mcp</code> — server MCP del piano di controllo (streamable-HTTP) con strumenti per Trust Ratings, Alignment & Protection Cards, governance, posture, team, webhook e chiavi API. <code>tools/list</code> è pubblico; l'esecuzione degli strumenti si autentica esattamente come l'API REST (JWT Bearer o <code>X-Mnemom-Api-Key</code>).
- <code>docs.mnemom.ai/mcp</code> — ricerca documentale in sola lettura. Il piano di controllo pubblica una scheda individuabile su <code>/.well-known/mcp/server-card.json</code>, e configurazioni client pronte da copiare sono disponibili su <code>/for-agents</code> e nella documentazione.
Gli agenti possono scoprire come registrarsi e autenticarsi, end to end.
I metadati di risorsa protetta dell'API Mnemom puntano ora a metadati di authorization-server di prima parte che includono un profilo di registrazione agent_auth — così un agente può trovare l'API, apprendere che l'emissione dei token è delegata a Supabase e seguire il vero flusso register → claim senza leggere documentazione discorsiva.
- <code>/.well-known/oauth-protected-resource</code> (RFC 9728) elenca ora i metadati di authorization-server di prima parte di Mnemom su www.mnemom.ai, accanto all'issuer Supabase GoTrue a monte.
- <code>/.well-known/oauth-authorization-server</code> (RFC 8414) dichiara <code>issuer: https://www.mnemom.ai</code>, delega l'emissione dei token a Supabase e aggiunge un profilo <code>agent_auth</code> che mappa <code>register_uri</code> / <code>claim_uri</code> / <code>rekey_uri</code> sui veri endpoint <code>/v1/agents</code> — continuiamo a non emettere alcun token OAuth nostro.
Le superfici standard di scoperta degli agenti sono pubblicate e risolvibili.
Un agente senza conoscenze pregresse può ora trovare l'API Mnemom, apprendere come autenticarsi e vedere quali skill può invocare — interamente a partire da file standard su www.mnemom.ai. Ogni URL si risolve in qualcosa di reale; nulla è aspirazionale.
- <code>/.well-known/api-catalog</code> (RFC 9727) punta alla specifica OpenAPI 3.1 in produzione; <code>/.well-known/oauth-protected-resource</code> (RFC 9728) indica l'API Mnemom come risorsa protetta, e <code>/.well-known/oauth-authorization-server</code> (RFC 8414) delega l'emissione dei token al nostro IdP a monte (Supabase GoTrue) pur includendo un profilo <code>agent_auth</code> per la registrazione degli agenti Mnemom. Non emettiamo token di accesso OAuth nostri — dichiarato chiaramente in <code>/auth.md</code>.
- <code>/.well-known/agent-skills/*</code> elenca le skill invocabili supportate unicamente da veri endpoint pubblici, e <code>/.well-known/agent-card.json</code> fornisce una scheda di servizio in stile A2A; le direttive Content-Signal in robots.txt dichiarano la nostra postura verso la ricerca e l'IA.
- Aggiunto l'impegno <code>api-auth-discovery</code> al manifest di prontezza degli agenti, verificato ogni notte rispetto alla produzione.
AEGIS L5: advisory pubblici e feed di IoC STIX 2.1 attivi.
La superficie di trasparenza del Protection Network è aperta. /trust/advisories contiene resoconti post-incidente firmati; /v1/trust/iocs serve un bundle di indicatori STIX 2.1. Vuoto per scelta progettuale al momento della GA — il sistema dice la verità.
- <code>/trust/advisories</code> è attivo con il suo primo post-mortem sintetico, chiaramente etichettato come sintetico secondo il calm-at-GA contract.
- /v1/trust/iocs restituisce un bundle STIX 2.1, autenticato e con limitazione della frequenza, pronto per le pipeline di threat intelligence (curl + JSON-LD).
- I nuovi eventi webhook <code>advisory.published</code> e <code>ioc.added</code> si aggiungono al catalogo, così le pipeline di threat intelligence possono reagire nel momento in cui il Protection Network pubblica.
Il threat thermometer ora legge in tempo reale lo stato per asse del Protection Network.
I clienti ora vedono il quadro delle minacce cross-tenant su <code>/dashboard/threats</code>: stato per asse su substrato, verticale, schema e origine, aggiornato ogni 30 secondi. Calm at GA, by design.
- <code>GET /v1/network/threat-state</code> restituisce un'aggregazione per asse del quadro in tempo reale del Protection Network, pronta per il polling dalle tue dashboard.
- Una pagina dashboard su <code>/dashboard/threats</code> viene fornita con quattro schede per asse e una scheda dei totali.
- Un nuovo evento <code>network.threat_level.changed</code> ti consente di collegare le transizioni del livello di minaccia direttamente al tuo sistema di allerta.
Aggregatore cross-tenant L1: statistiche cumulative dello stato di campagna tra i clienti.
Le statistiche cumulative per asse ora correlano i segnali tra arena, Sideband e traffico di integrity-checkpoint — il motore di correlazione cross-tenant che vede le campagne che nessun singolo cliente potrebbe vedere.
- Il motore di correlazione unisce le fingerprint per asse tra i segnali di integrity, arena e Sideband per costruire uno stato a livello di campagna che nessun singolo tenant può vedere.
- Macchina a stati per bucket con isteresi a finestra di 6 h all'uscita; stati collegati a cells.ts tramite quattro cell campaign_state concrete (safe-house-hardening#246).
- Il motore si aggiorna in continuo, mantenendo aggiornato il quadro cross-tenant sull'intero Protection Network.
I webhook Safe House per valutazione (sh.*) sono cablati end-to-end.
Cinque eventi front-door di Safe House si aggiungono al catalogo AEGIS con controlli della modalità di consegna per organizzazione — un requisito di base per l'integrazione SOC/SIEM. Porta il catalogo di webhook AEGIS-GA da 10 a 15 eventi completamente cablati.
- I nuovi eventi webhook <code>sh.evaluation.warn</code> / <code>quarantine</code> / <code>block</code> si attivano a ogni punto di verdetto, più <code>sh.canary.triggered</code> quando un canary si attiva e <code>sh.session.escalated</code> quando una sessione supera un livello di rischio.
- Le modalità di consegna per organizzazione (completa, campionata al 10% o solo riepilogo) mantengono sotto controllo le organizzazioni ad alto traffico, con consegna firmata HMAC su ogni evento.
- 13 cell sh_emission nel harness fissano ogni percorso di attivazione checkpoint × modalità (safe-house-hardening#247).
Arena adversariale continua: 15 personas canoniche, modello di mutation-phase.
L'arena adversariale copre ora ogni tipo di minaccia canonico sui quattro checkpoint di Safe House. Le scoperte che sfuggono alimentano direttamente la pipeline Managed Rules.
- Tutte le 15 personas coprono ora ogni tipo di minaccia canonico sui quattro checkpoint di Safe House, incluso un archetipo di supply-chain a inside.integrity.
- Fornisce un modello di mutation-phase gating per bucket (isteresi 0,90↔0,95) che regolerà l'evoluzione degli attacchi in base al tasso di rilevazione.
- Gli attacchi che battono la rilevazione vengono catturati automaticamente come candidati Managed Rules su un percorso isolato e marcato con l'attribuzione — nessun umano nel ciclo che possa perdere una scoperta.
Le segnalazioni cliente di falsi negativi e falsi positivi alimentano la pipeline Managed Rules.
Il segnale cliente è ora una fonte di primo livello. Le segnalazioni passano attraverso un endpoint autenticato, un comando CLI e una pipeline di e-mail di conferma fornita in cinque lingue — alimentando la stessa coda di revisione dei candidati dell'arena e dell'aggregatore cross-tenant.
- L'endpoint di segnalazione è attivo, con una diffusione del webhook <code>recipe.candidate.created</code> verso il tuo account ogni volta che una segnalazione diventa un candidato di regola.
- I comandi <code>mnemom recipes report-fn</code> e <code>report-fp</code> sono disponibili nella CLI @mnemom/mnemom.
- E-mail di conferma FN cliente resa in en/fr/de/it/es tramite la pipeline di template Track D.
Tre modalità di revisore — con un invariante strutturale di doppio controllo sui tier 1-2.
Gli amministratori della piattaforma possono commutare la modalità di revisore tra manuale, auto-approvazione delle fonti attendibili e auto-approvazione ad alta confidenza. L'invariante protettivo è strutturale, non procedurale: le regole di tier-1 e tier-2 non possono mai essere promosse automaticamente senza doppio controllo umano, indipendentemente dalla modalità.
- La modalità di revisore e la soglia persistono a livello di piattaforma e vengono lette e scritte tramite <code>/v1/admin/settings/reviewer-mode</code>, con ogni modifica registrata nella pista di audit.
- Il controllo amministratore della modalità di revisore viene fornito con un passaggio di conferma e un'attribuzione di audit completa a ogni modifica.
- Tre cell reviewer_mode concrete bloccano l'invariante: trusted-sources promuove il tier-3, high-confidence inserisce UNA approvazione sul tier-1 ma NON promuove, manual blocca ogni auto-approvazione (safe-house-hardening#245).
Coda di revisione amministratore con catena di audit in sola aggiunta.
Gli amministratori della piattaforma ora esaminano i candidati di Managed Rules da una coda dedicata: approvare, rifiutare, modifiche richieste o promuovere. Ogni azione si concretizza come un INSERT riservato al ruolo di servizio su una catena in sola aggiunta — la superficie di audit su cui CISO e autorità di regolamentazione possono fare affidamento.
- Ogni azione di revisione si concretizza su una catena in sola aggiunta, ancorata alla creazione del candidato e fino alla promozione o al ritiro — la superficie di audit su cui CISO e autorità di regolamentazione possono fare affidamento.
- Un'interfaccia della coda di revisione amministratore viene fornita con il dettaglio completo delle regole e la telemetria.
- Ogni transizione di stato emette un segnale di governance, e nessuna regola può diventare attiva senza un'approvazione a doppio controllo — un'approvazione a due persone imposta dalla piattaforma, non dalla policy.
Managed Rules firmate Ed25519 con doppia scrittura KV+R2 e un soak di osservazione di 24 h.
Promuovere una recipe a Managed Rule è ora un evento firmato crittograficamente. Ogni regola è firmata Ed25519, servita in fail-closed e instradata attraverso un soak di osservazione di 24 ore prima dell'applicazione.
- La promozione firma crittograficamente ogni regola; i gateway verificano la firma e servono tramite un percorso di lettura a più livelli, fail-closed, con un obiettivo di propagazione P95 inferiore a 30 s.
- Il monitoraggio del tasso di FP ritira le recipe che superano la soglia — confermato dall'operatore alla cadenza di rilascio attuale, automatico nella Fase 2 di CLPI.
- Supporta una scansione notturna per ritirare le regole senza alcun riscontro dopo 90 giorni, mantenendo snello l'insieme delle regole attive.
Fingerprinting del substrato: ogni valutazione porta ora l'axis identity L0.
Il fingerprinting del substrato è in servizio. Ogni integrity checkpoint, tentativo nell'arena e analisi Sideband è ora marcato con fingerprint di substrato, verticale, schema e origine — la chiave di correlazione cross-tenant che intercetta le deviazioni comportamentali in ogni cliente che opera sullo stesso substrato.
- Ogni valutazione viene ora marcata con il suo fingerprint di substrato a quattro assi al momento della scrittura — distribuito in produzione.
- Il modello di dati sottostante del Protection Network è in atto, con isolamento a livello di riga applicato fin dalla prima scrittura.
- Le regole si compongono come le card — Platform → Org → Team → Agent, vince la più restrittiva.
Detector Safe House rafforzati sulle classi di prompt injection e di leak di PII.
I detector front-door e back-door hanno ricevuto una passata di calibrazione. Meno falsi positivi sulle chiamate a strumenti legittime, tasso di blocco più netto sui nuovi pattern di injection — senza ampliare i dati che raccogliamo.
- Detector di prompt injection riaddestrati su un corpus avversariale recente; 12 % di falsi positivi in meno.
- Lo screening back-door ora cattura i leak di PII con token frammentati (per es. SSN o numeri di carta spezzati tra chunk in streaming).
- Il formato di verdetto firmato include ora la versione del detector, così gli auditor possono riprodurre l'esatto classificatore usato.
Identità agente con passkey e chiave hardware è live.
Gli agenti possono ora essere legati a una passkey o a una chiave hardware dal primo giorno. La firma Ed25519 resta il default; l'identità agente basata su WebAuthn è disponibile per i team che vogliono un onboarding non falsificabile.
- Attestazione WebAuthn supportata per l'enrollment degli agenti.
- La rotazione dell'identità agente non spezza le proof chain storiche; le vecchie chiavi restano verificabili.
- Funziona sia per il gateway self-hosted che per i tenant managed.
Il gateway auto-scala ora fino al tetto M0 senza cambi lato operatore.
Lavoro di affidabilità sotto il cofano. Il gateway managed provisiona elasticamente per i picchi di traffico fino al tetto del tier M0, senza config lato tenant. I deploy self-hosted ricevono gli stessi default dell'autoscaler nel chart Helm.
- Auto-scale da 2 a 10 repliche con CPU sostenuta > 70 %.
- Percorso di cold-start ridotto del 40 % per l'immagine self-hosted.
- Nessun cambio di prezzo — lo scale-up resta dentro il tetto del tuo tier.
Vedi cosa la piattaforma dimostra davvero.
Ogni cambiamento rilasciato sostiene una di due affermazioni: cosa dimostriamo, o come proteggiamo i tuoi agenti.
