# AEGIS — Cross-tenant defensive network for AI agents

```json
{"@context":"https://schema.org","@type":"WebPage","name":"AEGIS \u2014 Rete difensiva cross-tenant per agenti IA","description":"Mnemom AEGIS \u00e8 la rete difensiva cross-tenant dietro la Safe House. Quattro checkpoint, quattro modalit\u00e0 di enforcement, Managed Rules firmate, un obiettivo di propagazione P95 sotto i 30 secondi e un IoC feed STIX 2.1 pubblico.","url":"https://www.mnemom.ai/it/security","inLanguage":"it-IT","dateModified":"2026-06-08","publisher":{"@type":"Organization","@id":"https://www.mnemom.ai#organization","name":"Mnemom","url":"https://www.mnemom.ai"}}
```

```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://www.mnemom.ai/it"},{"@type":"ListItem","position":2,"name":"Rete difensiva cross-tenant per agenti IA.","item":"https://www.mnemom.ai/it/security"}]}
```

Mnemom AEGIS

# 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.

[Dashboard cliente](/it/dashboard)[curl /v1/trust/iocs](https://api.mnemom.ai/v1/trust/iocs)[Contatta il sales](/it/contact)

## 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.

Modo →

off

observe

nudge

enforce

`front door`

Screening dei messaggi in ingresso — ogni prompt, payload di retrieval e risposta di tool prima che l'agente li processi.

`back door`

Screening delle risposte in uscita — PII, segreti, violazioni di Alignment Card, consulenza regolamentata prima che la risposta lasci il perimetro.

`inside.autonomy`

Screening delle chiamate a tool — ogni azione che l'agente esegue rispetto ai limiti di autonomia dichiarati dall'Alignment Card.

`inside.integrity`

Screening dell'integrità del reasoning — verdetti AIP sui payload thinking-block; firme di deviazione del substrate; schemi di abuso di identità.

off

Checkpoint disabilitato. Usato nei tenant canary e prima dell'onboarding.

observe

Valuta ogni transazione; emette verdetti firmati; non blocca mai. Il default per le nuove Managed Rules durante il soak observe di 24 ore.

nudge

Annota o avverte inline senza bloccare. La via di mezzo per le regole tier-3 durante la fase di ramp-up.

enforce

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.  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.  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.  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.  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.  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.

[Modello di minaccia completo su /supply-chain](/it/supply-chain)

## 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.

Propagazione Managed Rule

P95 ≤ 30 s

Promozione firmata → caricata sul gateway. Obiettivo pubblicato; prime misurazioni 30 giorni dopo la GA.

Disponibilità del failover

99,99 %

Il gateway carica un set di regole verificato su più livelli di lettura indipendenti.

Freschezza del rule-set

P99 ≤ 5 min

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 pubblicati](/it/trust/slos)

## Porti 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 .
```

[Dashboard cliente](/it/dashboard)[curl /v1/trust/iocs](https://api.mnemom.ai/v1/trust/iocs)[Contatta il sales](/it/contact)

---
_Source: /it/security/index.html · Generated by build-markdown-mirrors.mjs · For agent-readability commitment #4 see https://www.mnemom.ai/for-agents_
