Ogni cliente beneficia di ogni detection. Mnemom AEGIS — l'Adaptive Enforcement, Governance & Intelligence Substrate — alimenta tre loop di segnale indipendenti in una singola candidate review queue, poi firma le recipes promosse e le propaga a ogni gateway della rete. Stesso vocabolario delle cards: quattro checkpoint × quattro mode di enforcement, Platform → Org → Team → Agent, strictest-wins.
Tre loop di segnale indipendenti. Una coda di revisione. I contenuti di detection e i controlli di enforcement viaggiano attraverso la stessa macchineria firmata, così che una lezione appresa in un punto qualsiasi arriva ovunque.
Segnale 1 — Arena avversariale
15 persona canonici. Mutation-phase gated. Live in produzione.
Quindici persona avversariali coprono ogni tipo di minaccia canonico sui quattro checkpoint Safe House, incluso un infiltrato della supply chain a inside.integrity.
Il mutation-phase gating lascia evolvere gli attacchi solo finché la detection per bucket resta sopra la soglia, con isteresi sostenuta per evitare oscillazioni, valutato in modo indipendente per substrate fingerprint.
Il traffico dell'arena scorre su un proprio percorso di scrittura isolato, separato dal segnale di produzione, così che gli attacchi sintetici non possano mai contaminare i dati dei clienti. L'isolamento è applicato lato server, non per convenzione.
Segnale 2 — Report dei clienti
Falsi positivi e falsi negativi, segnalati dai clienti che fanno girare gli agenti.
I clienti segnalano i mancati rilevamenti (falsi negativi) e gli over-block (falsi positivi) direttamente dal dashboard o tramite l'API di report.
Ogni report confluisce nella stessa coda di revisione alimentata dall'arena — una coda condivisa, una pipeline firmata, indipendentemente da dove sia arrivato il segnale.
Calm-at-GA: questo segnale esiste perché i falsi positivi sono inevitabili. Il mutation-phase gating e l'auto-rollback sui falsi positivi si fondano entrambi sull'ipotesi che sbaglieremo — e che Lei ce lo dirà quando accadrà.
Segnale 3 — Aggregatore cross-tenant
Il worker L1. La visione della rete. Il lavoro veramente nuovo.
La rete mantiene statistiche mobili per ogni substrate fingerprint — la combinazione di provider, modello e SDK su cui gira un agente. Ogni valutazione nella rete è marchiata con quella fingerprint.
Quando eventi di sicurezza apparentemente non correlati presso clienti diversi condividono una substrate fingerprint, l'aggregatore li lega in un'unica firma di campagna — la vista cross-tenant che nessun singolo cliente può vedere da solo. Live in produzione.
Questo è ciò che nessun altro sul mercato ha. I guardrail degli hyperscaler, i detector in-process e i proxy per tenant vedono tutti un cliente alla volta. L'aggregatore vede attraverso tutti loro.
Tre loop. Un substrato. Firmato dall'inizio alla fine.
Tre loop, un substrato — la pipeline AEGIS dall'inizio alla fine.
Arena
15 persona + mutation-phase gate
Segnale cliente
Report dei clienti + telemetria
Aggregatore cross-tenant
Statistiche mobili per substrate fingerprint
Tabella candidati + coda di review
Ogni sorgente di segnale scrive sul proprio percorso isolato. Review manuale di default; le modalità automatiche sono opt-in.
Promozione firmata
Firmato con Ed25519 alla promozione. Le regole tier-1 e tier-2 richiedono una revisione a due persone — applicata in modo strutturale, non per processo.
Recipes promosse
Composte come le cards. Platform → Org → Team → Agent, strictest-wins.
Gateway — 4 checkpoint × 4 mode
Buste KV-signed + R2-signed. Obiettivo di propagazione P95 ≤ 30s su /trust/slos.
Il rilevamento supply-chain è una sotto-dimensione, non un sistema parallelo. Ogni valutazione porta una substrate fingerprint — provider, modello, SDK version e un lockfile hash opzionale. Lo stesso modello a quattro checkpoint porta ogni recipe.
Pipeline di promozione
Ogni recipe promossa è firmata. Tier-1 e tier-2 non vengono mai auto-promosse.
Tutti e tre i segnali alimentano la stessa coda di revisione, e ogni recipe promossa percorre la stessa pipeline firmata. L'invariante protettivo è integrato nel sistema in modo strutturale: non è una procedura né una policy che si possa aggirare.
01
Candidate
Ogni segnale scrive sul proprio percorso isolato. Il contenuto della recipe è normalizzato in un'unica forma, mentre la sorgente di origine resta allegata per la traccia di audit.
02
Review
Tre mode di review per il pattern Cloudflare-peer: manuale (default), auto-approve-trusted-sources, auto-approve-high-confidence. I candidati tier-3 sono idonei agli auto-mode; tier-1/-2 no — indipendentemente dall'impostazione del mode.
03
Promozione firmata
Firmato con Ed25519 al momento della promozione. Lo storico delle revisioni è append-only. Una regola non può diventare attiva finché non è raggiunto il quorum di revisione a due persone.
04
Soak in observe 24h
Ogni recipe promossa è rilasciata in mode observe per 24 ore, indipendentemente dal tier. Il tasso di falsi positivi è campionato in una finestra mobile di 7 giorni. Auto-rollback scatta su superamento di soglia per CLPI Phase 2.
05
Enforce + propagazione
La regola viene scritta su due livelli di storage, ciascuno firmato con una chiave indipendente, poi caricata da ogni gateway — dove le Managed Rules bloccano oggi in produzione. L'obiettivo è una propagazione P95 ≤ 30s, misurata in continuo su /trust/slos.
L'invariante protettivo
Una recipe tier-1 o tier-2 — quella che bloccherebbe davvero il traffico di produzione — non può mai essere promossa senza revisione umana a due persone, indipendentemente da quanto sia aggressiva l'impostazione del reviewer mode. Il sistema lo impone in modo strutturale. Le modalità automatiche accelerano solo il rilascio di tier-3 (observe / nudge / log), dove il blast radius di una decisione errata è limitato.
Effetto rete vendor-neutral
Substrate-aware su OpenAI, Anthropic, Gemini, e qualsiasi modello sul gateway Mnemom.
La substrate fingerprint marchiata su ogni valutazione include il provider, il modello e la SDK version — più un lockfile hash opzionale che i clienti possono inviare. Il segnale cross-tenant fluisce attraverso i provider, non solo all'interno di uno.
Nessun lock-in di provider.
AEGIS vede deviazione comportamentale attribuita al substrato attraverso ogni cliente che gira sulla stessa combinazione provider/model/SDK. Lo stream di valutazione di un cliente che fa emergere anomalie eleva la protezione per ogni altro cliente su quel substrato — su OpenAI, Anthropic, Gemini, o qualsiasi modello locale dietro il gateway.
Complementa; non sostituisce.
AEGIS è lo strato di rete. I clienti che usano Lakera Guard, NeMo Guardrails, Cloudflare WAF, AWS Bedrock Guardrails o Robust Intelligence possono far girare AEGIS in parallelo — complementa; non sostituisce. Strato diverso, segnale diverso.
AAP dichiara. AIP verifica. AEGIS firma.
AAP rende pubblico l'intento dell'agente — trasparenza, non fiducia. AIP fornisce verdict di integrità in volo. CLPI governa il ciclo di vita della card. AEGIS firma le difese cross-tenant che agiscono sull'immagine integrata. Nessuno strato pretende di essere quello precedente.
Contratto calm-at-GA
Se la rete è calma, la pagina dice calma.
Alla GA il feed IoC è vuoto per design. La lista advisories mostra un solo post-mortem sintetico chiaramente etichettato synthetic. La threat thermometer è calma. Non simuliamo attività. Il mutation-phase gating è live; la prima attivazione in produzione sarà riportata su /trust/advisories quando avverrà. Il doppio controllo tier-3 è live; il doppio controllo tier-1/-2 inizia quando il nostro secondo platform-admin verrà onboardato.
Ispezionare la rete.
Tre sorgenti di segnale. Una pipeline firmata. Ogni promozione, ogni advisory, ogni IoC pubblicamente verificabile.