Rete difensiva cross-tenant per agenti IA.
Mnemom AEGIS — Adaptive Enforcement, Governance & Intelligence Substrate — è la rete di sicurezza runtime dietro la Safe House. Filtra ogni transazione dell’agente a quattro checkpoint — front door, back door, inside.autonomy, inside.integrity — ciascuno configurabile in modo indipendente in quattro modalità di enforcement. Le Managed Rules firmate portano un obiettivo SLO di propagazione cross-tenant P95 sotto i 30 secondi (prime misurazioni pubblicate 30 giorni dopo il GA).
AAP dichiara. AIP verifica in volo. CLPI governa e ancora. Safe House filtra. AEGIS firma le difese cross-tenant.
Il modello di minaccia.
Sette schemi d'attacco definiscono oggi la superficie di minaccia agentica. Ciascuno è mappato su uno dei quattro checkpoint — così i clienti possono regolare l'enforcement per superficie, non come postura globale unica.
| Minaccia | Checkpoint | Come si presenta |
|---|---|---|
| Prompt injection | front door | Tentativi diretti di sovrascrivere le istruzioni dell'agente, invertire il ruolo o aggirare lo scope dichiarato alla superficie in ingresso. |
| Injection indiretta | front door | Istruzioni nascoste dentro documenti recuperati, output di tool e payload di vector store — il prompt che l'agente non sapeva di aver ricevuto. |
| Tool misuse | inside.autonomy | Chiamate a tool coercite o concatenate che eccedono i limiti di autonomia dichiarati dall'agente o violano la superficie protetta della Protection Card dell'organizzazione (operazioni vietate, asset protetti). Attacchi sulla forma degli argomenti contro schemi sotto-validati (OWASP ASI02). |
| Esfiltrazione dati | back door | PII, PHI, segreti, credenziali o dati cross-tenant rimandati nelle risposte dell'agente, nei trace d'errore o in schemi split-token. |
| Frode BEC / impersonificazione | front door | Richieste in stile frode del CEO, pressione di urgenza e autorità, social engineering che prende di mira il contratto di escalation dell'agente. |
| Spoofing dell'agente | inside.integrity | Tentativi di abuso di identità che rivendicano un'autorità non dichiarata dall'Alignment Card. OWASP ASI03 — Identity & Privilege Abuse. |
| Compromissione della supply chain | inside.integrity | Firme comportamentali coerenti con un SDK compromesso, un fine-tune di modello o un template di prompt vendored — rilevate cross-tenant tramite substrate fingerprinting (OWASP ASI04). |
Quattro checkpoint × quattro modi di enforcement.
Ogni checkpoint è configurabile in modo indipendente. La composizione segue il principio strictest-wins lungo Platform → Org → Team → Agent: l'impostazione più restrittiva di qualunque livello prevale sempre. Funziona in modo analogo a come Cloudflare WAF Managed Rules Le consentono di definire severity × action per ogni regola.
front doorback doorinside.autonomyinside.integrityCheckpoint disabilitato. Usato nei tenant canary e prima dell'onboarding.
Valuta ogni transazione; emette verdetti firmati; non blocca mai. Il default per le nuove Managed Rules durante il soak observe di 24 ore.
Annota o avverte inline senza bloccare. La via di mezzo per le regole tier-3 durante la fase di ramp-up.
Blocca la transazione e mostra un verdetto firmato nella dashboard. Raggiunta solo dopo il soak in modalità observe e la disciplina di rollback sul tasso di FP — confermata dall'operatore oggi, automatica nella Fase 2 di CLPI.
Cascata di composizione: Platform → Org → Team → Agent, strictest-wins. Gli admin clienti possono stringere a qualsiasi livello.
La pipeline Managed Rules.
Le recipes sono contenuto di detection. Le Managed Rules sono lo stato firmato del control-plane che le avvolge. La pipeline è vincolata strutturalmente — non procedurally — per cui le regole tier-1 e tier-2 non possono auto-promuoversi, indipendentemente dal modo impostato dall'operatore.
- 1. Arena
Quindici personas avversarie canoniche sondano Safe House 24/7. La mutation-phase gating si attiva per bucket solo quando il tasso di detection supera il 95 % su una finestra mobile di 48 ore con isteresi di 24 ore.
- 2. Candidate
I candidati che superano l'arena entrano in una coda di revisione isolata con un percorso di scrittura rigorosamente separato, così il sistema che propone il contenuto di detection non può mai essere lo stesso che lo approva. Le segnalazioni di falsi negativi e falsi positivi dei clienti e i segnali di rete cross-tenant confluiscono tutti nella stessa coda.
- 3. Review
Tre modi di reviewer — manual (default), auto-approve-trusted-sources, auto-approve-high-confidence. Tier-1 / tier-2 richiedono sempre review in dual-control sotto una catena d'audit append-only.
- 4. Soak observe 24h
Ogni promozione firmata atterra in modalità observe per 24 ore. Il monitoraggio del tasso di FP ritira la recipe prima che venga bloccato qualsiasi traffico di produzione — confermato dall'operatore oggi, automatico nella Fase 2 di CLPI.
- 5. Enforce
Il failover tiered KV+R2+isolate-cache con catene di firma indipendenti spinge la regola verso ogni gateway. P95 ≤ 30 s tra promotion firmata e caricamento sulla gateway.
L'invariante protettivo
Una Managed Rule di tier-1 o tier-2 — una che bloccherebbe davvero traffico di produzione reale — non può mai essere promossa senza una revisione umana a quattro occhi, per quanto aggressiva sia l'impostazione della modalità di auto-promozione. La garanzia è applicata in modo strutturale, nel modello di dati stesso: una regola attiva non può esistere finché non è stato raggiunto il suo quorum di revisione. È una proprietà del sistema, non una procedura che qualcuno deve ricordarsi di seguire.
Garantito dal modello di dati, non dalla disciplina dell'operatore.
Substrate fingerprinting + detection della supply chain.
Ogni valutazione viene marcata con un substrate fingerprint — il provider, il modello e la versione dell'SDK dietro la richiesta, più un lockfile hash facoltativo fornito dal cliente e inviato tramite l'header `X-Mnemom-Lockfile-Hash`. AEGIS osserva la deviazione comportamentale su tutti i clienti che girano sullo stesso substrate, simultaneamente.
L'11 maggio 2026 — il worm Mini Shai-Hulud ha compromesso oltre 170 pacchetti npm e 2 pacchetti PyPI, inclusa la suite SDK di Mistral AI e il pacchetto PyPI di Guardrails AI. Le versioni compromesse di `@tanstack/*` sono state distribuite con attestazioni SLSA Build Level 3 valide — il primo caso documentato di un worm che produce provenance firmata legittima per pacchetti malevoli. La detection per tenant e la verifica Sigstore a livello di pacchetto non possono strutturalmente intercettare questa classe di attacco.
OWASP Top 10 for Agentic Applications.
Mappatura onesta rispetto all'autorevole OWASP Top 10 per le applicazioni agentiche (OWASP Gen AI Security Project, pubblicata il 09/12/2025). Dove la copertura è parziale o assente, lo diciamo — la tassonomia ASI completa è su genai.owasp.org.
OWASP Top 10 per le applicazioni agentiche (genai.owasp.org)
| Categoria OWASP | Copertura | Come AEGIS la affronta |
|---|---|---|
| ASI02 — Tool Misuse | Partial | Motore di policy (CLPI Fase 1) con applicazione delle azioni delimitate + Managed Rules con regole di divieto al checkpoint inside.autonomy, più lo screening back-door dell'esfiltrazione di dati tramite strumenti. L'applicazione dell'ambito dichiarato è il controllo primario; Mnemom non intercetta ogni invocazione non sicura di strumenti al gateway. |
| ASI03 — Identity & Privilege Abuse | Full | Limiti di autonomia dichiarati da AAP (Alignment Card) applicati dal motore di policy CLPI + verdetti di integrità AIP in volo + screening al checkpoint inside.integrity delle rivendicazioni di privilegio/abuso di identità in fase di esecuzione. |
| ASI04 — Agentic Supply Chain Vulnerabilities | Full (runtime) | Il fingerprinting del substrato a ogni valutazione + l'aggregatore cross-tenant rilevano deviazioni del comportamento a runtime coerenti con una dipendenza/un substrato compromesso che nessun singolo cliente può vedere. Integra — non sostituisce — la provenienza dei pacchetti in fase di build (SLSA, Sigstore). |
| ASI07 — Insecure Inter-Agent Communication | Partial | Il checkpoint back-door tratta per progettazione come sospette le rivendicazioni di autorità/identità non autenticate che arrivano come messaggi in ingresso a runtime. Questo filtra il contenuto dei messaggi inter-agente; l'autorità legittima da agente ad agente deve essere codificata nelle Alignment Card. Non è uno schema di autenticazione del trasporto. |
Le categorie rimanenti sono coperte altrove nello stack Mnemom, esposte onestamente: ASI01 (Agent Goal Hijack) — screening front-door di Safe House, rilasciato per l'injection diretta e con copertura sostanziale del dirottamento dell'obiettivo multi-turno (residuo su sequenze multi-turno/multi-vettore inedite); ASI09 (Human-Agent Trust Exploitation) — rilevamento front-door rilasciato della manipolazione di autorità/urgenza/segretezza; ASI10 (Rogue Agents) — coperto a livello di governance (Alignment Card AAP + ciclo di vita CLPI + Trust Ratings), non un singolo pattern front-door. Lacune oneste: ASI05 (Unexpected Code Execution) e ASI06 (Memory & Context Poisoning) oggi non sono intercettati al front-door (il motore di policy riduce la superficie d'azione; AIP offre osservabilità parziale a valle — abbinalo a una sandbox a livello applicativo / tratta la memoria come input non attendibile), e ASI08 (Cascading Failures) è una questione di architettura applicativa (timeout, bulkhead, circuit breaker). Vedi /protection-network e /trust.
Framework di gestione del rischio IA del NIST.
Come i controlli di runtime già rilasciati di Mnemom supportano le quattro funzioni del NIST AI RMF. Mappatura onesta — Mnemom è un substrato di fiducia a runtime, non un programma di gestione del rischio IA; dove una funzione è responsabilità organizzativa del cliente, lo diciamo.
| Funzione AI RMF | Copertura | Come Mnemom la supporta |
|---|---|---|
| GOVERN | Partial | Alignment Card come artefatto di policy leggibile dalla macchina per agente (principal, supervisione, perimetro di autonomia) + governance del ciclo di vita CLPI + promozione delle Managed Rules con doppio controllo. Il tuo programma di governance organizzativa (ruoli, autorità di approvazione, onboarding di modelli di terze parti) resta tuo. |
| MAP | Partial | L'Alignment Card inquadra lo scopo + i limiti dichiarati di autonomia/integrità di ogni agente; la classificazione del rischio dell'EU AI Act + la mappatura OWASP Agentic Top 10 inquadrano il contesto di rischio. Inquadramento per agente rilasciato; l'inquadramento dell'intero parco è del cliente. |
| MEASURE | Partial | Checkpoint + verdetti di integrità AIP (per decisione), il Trust Rating (0–1000), gli SLI pubblicati su trust.mnemom.ai/slos, la telemetria dei falsi positivi di Safe House e il substrate fingerprinting di AEGIS. Misurazione di runtime in tempo reale; la valutazione dei modelli pre-deployment è complementare + eseguita dal cliente. |
| MANAGE | Partial | L'applicazione delle azioni delimitate del Policy Engine + Safe House observe/nudge/enforce trattano il rischio rilevato; il CMS degli avvisi + il transparency log comunicano gli incidenti; il failover di AEGIS + il responder sempre attivo gestiscono risposta/ripristino. L'allocazione delle risorse di rischio + il processo IR della tua organizzazione restano tuoi. |
"Parziale" è onesto: l'AI RMF è un framework volontario e non certificabile, gestito dalla tua organizzazione. Mnemom fornisce i controlli di runtime + le prove verificabili su cui ogni funzione può basarsi; non solleva dalle tue responsabilità GOVERN né certifica la conformità. Mappatura completa in /guides/eu-compliance.
Come si confronta AEGIS.
Sintesi dalla ricerca sul panorama competitivo del 23 maggio 2026. AEGIS è il layer di rete; i vendor sotto sono complementari, non sostituti — vedi /governance per la storia di integrazione completa.
| Capacità | Mnemom AEGIS | Cloudflare WAF | Lakera Guard | Cisco AI Defense | AWS Bedrock Guardrails | Google Model Armor |
|---|---|---|---|---|---|---|
| Managed Rules cross-tenant con promotion firmata | Sì — firmate Ed25519, propagazione P95 ≤ 30 s, catena d'audit pubblica | Managed Rules WAF (layer web, non layer agente) | Threat-intel curata dal vendor; nessun segnale derivante dalla rete dei clienti | SDK embed in build-time; nessuna rete cross-tenant runtime | Solo AWS; nessun apprendimento cross-client | Filtro in-process; nessuna rete |
| Modello quattro-checkpoint × quattro-modi per agente | Sì — front door / back door / inside.autonomy / inside.integrity, ciascuno configurabile in modo indipendente | Regole WAF per route; non sagomate per transazione agentica | Detector singolo a runtime | Integrazione NeMo Guardrails; policy in build-time | Bedrock Guardrails per policy (denylist, PII, contextual grounding) | Filtri prompt-injection + URL + contenuto dannoso |
| Substrate fingerprinting (provider + model + versione dell'SDK) su ogni valutazione | Sì — detection cross-tenant della supply chain | No | No | No | No | No |
| IoC feed pubblico STIX 2.1 + advisories firmati | Sì — /v1/trust/iocs (vuoto al GA per design) | Solo feed Radar interni al cliente | Nessun feed pubblico | Talos per le minacce tradizionali; nessun IoC feed agentico pubblico | No | No |
| Invariante di dual-control su tier-1/-2 (applicata nel modello di dati) | Sì — imposto dallo schema, non procedurale | Change-management procedurale | Controllato dal vendor | Controllato dal vendor | IAM di policy cliente | Controllato dal vendor |
Fonti: documentazione pubblica dei vendor, 23 maggio 2026. AEGIS è un layer che i clienti eseguono accanto a questi prodotti, non un sostituto.
SLO pubblicati. Misurati in continuo.
Numeri principali sotto. La tabella completa — query di misurazione, dati storici una volta chiusa la prima finestra di 30 giorni, e i quattro SLO di supporto — vive su /trust/slos.
Promozione firmata → caricata sul gateway. Obiettivo pubblicato; prime misurazioni 30 giorni dopo la GA.
Il gateway carica un set di regole verificato su più livelli di lettura indipendenti.
In funzionamento normale. Page P0 a 24h di staleness.
La prima finestra di misurazione di 30 giorni viene pubblicata 30 giorni dopo il GA. Non preannunciamo numeri che non possiamo difendere.
Vedi gli SLO pubblicatiPorti i suoi tool.
L'IoC feed è STIX 2.1 leggibile da macchina. La catena d'audit è verificabile. La dashboard è aperta a ogni cliente.
curl -s https://api.mnemom.ai/v1/trust/iocs | jq .