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 lo scope autorizzato dall'Alignment Card. 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 — Privilege Compromise via Identity 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 ASI06). |
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 fa emergere un verdetto firmato nella dashboard. Raggiunto solo dopo il soak observe e la disciplina di auto-rollback sul tasso di FP (CLPI Phase 2).
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 promotion firmata atterra in modo observe per 24 ore. L'auto-rollback sul tasso di FP secondo CLPI Phase 2 ritira la recipe prima che qualsiasi traffico di produzione venga bloccato.
- 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. Dove la copertura è parziale, lo diciamo. La tassonomia OWASP ASI completa (dic. 2025) è su owasp.org.
| Categoria OWASP | Copertura | Come AEGIS la affronta |
|---|---|---|
| ASI02 — Tool Misuse | Completa | Policy engine (CLPI Phase 1) + Managed Rules al checkpoint inside.autonomy. Screening delle chiamate a tool contro i limiti di autonomia dichiarati dall'Alignment Card. |
| ASI03 — Privilege Compromise via Identity Abuse | Completa | Limiti di autonomia dichiarati da AAP (Alignment Card) + verdetti d'integrità in volo AIP + screening al checkpoint inside.integrity per schemi di abuso di identità. |
| ASI06 — Agentic Supply Chain Compromise | Completa (runtime) | Substrate fingerprinting su ogni valutazione. L'aggregatore cross-tenant rileva deviazioni comportamentali che nessun singolo cliente può vedere. Completa — non sostituisce — la provenance a livello di pacchetto (SLSA, Sigstore). |
| ASI07 — System Prompt Leakage | Parziale | Screening al checkpoint back-door di schemi noti di system prompt + segreti e violazioni di Alignment Card. La detection è basata sul contenuto; gli agenti che citano legittimamente il proprio system prompt su richiesta dell'utente non vengono soppressi. |
ASI01 (Prompt Injection), ASI04 (Resource Exhaustion), ASI05 (Cascading Hallucination), ASI08 (Repudiation & Untraceability), ASI09 (Identity Spoofing), ASI10 (Overreliance) sono mappate su altre parti dello stack Mnemom (AAP cards, verdetti AIP, ancoraggio on-chain CLPI, Trust Ratings) — coperte su /protection-network e /trust.
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 .