Per i team di piattaforma

Il Learning Network.

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 alimentano un substrato.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Featured on There's An AI For That