> **Agent?** Fastest path: MCP at `https://api.mnemom.ai/mcp` — call `get_started` first (zero-auth, no args). Full agent guide: # The Proving Ground — Arena avversariale dal vivo | Mnemom ```json {"@context":"https://schema.org","@type":"WebApplication","name":"The Proving Ground \u2014 Arena avversariale dal vivo | Mnemom","description":"Quindici avversari con nome attaccano ogni checkpoint della nostra difesa degli agenti, 24 ore su 24. Ogni breccia diventa un rilevamento firmato che protegge ogni cliente.","url":"https://www.mnemom.ai/it/arena/","inLanguage":"it-IT","dateModified":"2026-06-24","publisher":{"@type":"Organization","@id":"https://www.mnemom.ai#organization","name":"Mnemom","url":"https://www.mnemom.ai"},"image":"https://www.mnemom.ai/api/og-image?type=arena","applicationCategory":"DemoApplication","operatingSystem":"Any"} ``` ```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":"The Proving Ground \u2014 Arena avversariale dal vivo | Mnemom","item":"https://www.mnemom.ai/it/arena/"}]} ``` Proving Ground · arena avversariale dal vivo # Quindici avversari attaccano la nostra difesa 24 ore su 24. Ogni breccia la rende più forte. Ogni persona è specializzata in una diversa classe di attacco — prompt injection, ingegneria sociale, esfiltrazione di dati, compromissione della supply chain — su tutti e quattro i checkpoint, senza sosta. Nel momento in cui una trova una falla, quella falla diventa un rilevamento esaminato e firmato crittograficamente che protegge ogni agente della rete, non solo l'arena. Vedi la Safe HouseLeggi l'architettura Feed dal vivoClassificaTecnicheEvoluzioneRilevamentiCopertura Il roster ## Quindici avversari, ogni minaccia su ogni checkpoint Ognuno dei nostri quindici avversari con nome occupa una cella della matrice delle minacce: una specifica classe di attacco a uno specifico checkpoint. The Substrate Mole, per esempio, esegue attacchi alla supply chain al checkpoint di integrità. Man mano che la difesa si rafforza, ogni avversario muta nella propria specialità — scavando più a fondo, senza divagare — così la copertura resta completa e la pressione mirata. front door Porta anteriore — prompt in ingresso e risultati degli strumenti: prompt injection, injection indiretta, frode del CEO, jailbreak, dirottamenti multi-turno, spoofing di agenti, varianti multilingue e rumore a raffica. inside.autonomy Checkpoint di autonomia — ciò che l'agente può fare: sondaggio dei limiti degli strumenti, chiamate a strumenti non dichiarati e azioni oltre il mandato dell'agente. inside.integrity Checkpoint di integrità — come ragiona l'agente: integrità della catena di ragionamento, compromissione della supply chain (The Substrate Mole), prompt-laundering e deriva dei valori. back door Porta posteriore — risposte in uscita: prevenzione della perdita di dati, esfiltrazione di credenziali e canary, fughe di PII/PHI e fughe del prompt di sistema. Ogni avversario è associato a un'unica cella fissa minaccia × checkpoint. La mutazione esplora all'interno di quella cella, mai oltre, così la matrice resta coperta in modo completo e uniforme. Pressione adattiva ## Quando la difesa inizia a vincere, gli attacchi si evolvono L'arena passa la maggior parte del tempo a cercare nuove vie d'accesso. Ma quando la difesa intercetta in modo affidabile una data classe di attacco, l'arena cambia marcia: smette di ripetere gli attacchi noti e inizia a mutarli, mettendo alla prova la difesa corretta invece di adagiarsi. Ogni classe di attacco è tracciata a sé, così l'arena può rafforzare un'area mentre ne esplora ancora un'altra. Soglia di ingresso 95% intercettati, sostenuto Volume sufficiente (180–360 sonde) per reagire in fretta senza inseguire il rumore. Finestra 48 ore rolling Finestra continua all'indietro, non periodi di calendario. Isteresi di ingresso 24 ore sostenute Un picco non lo attiva: il tasso deve reggere per un giorno intero. Isteresi di uscita 24 ore sostenute Un bucket deve restare sotto la soglia di uscita per 24 ore prima di tornare in find-mode. Soglia di uscita 90% intercettati Sotto la soglia d'ingresso così il sistema non oscilla al confine. Indipendenza per bucket per substrato, settore, pattern e origine Un agente finanziario potrebbe rafforzarsi contro la frode del CEO mentre esplora ancora la prompt injection: ciascuno tracciato a sé. Inquadramento onesto Questo meccanismo adattivo è realizzato e attivo nella nostra arena. Segnaleremo la prima attivazione in produzione su /trust/advisories: non consideriamo il codice completato come provato sul campo. Privilegio minimo per progettazione ## L'arena può trovare una debolezza. Non può rilasciare la correzione da sola. L'arena opera con una propria identità dal perimetro ristretto. Può fare esattamente una cosa: inviare un rilevamento candidato alla revisione umana. Non può promuovere una regola, modificarne una attiva, ritirarne una né toccare altro. Ogni candidato viene marcato — dal server, mai dal client — con la sua provenienza, così una scoperta dell'arena non può mai spacciarsi per una segnalazione cliente o un'azione di un operatore. ``` writer_identity = arena-bypass auth = ARENA_RECIPE_CANDIDATE_TOKEN write_scope = recipe_candidates only read_scope = none (no live-rule visibility) promote_scope = none (separate reviewer auth required) ``` Scope Le credenziali dell'arena aprono esattamente una porta — inviare un candidato alla revisione. Nessun accesso in lettura alle regole attive. Nessun accesso in scrittura a nient'altro. Origine marcata dal server L'origine di ogni candidato è impostata dal server a partire dall'identità autenticata, mai dal client. L'arena non può fingersi una segnalazione cliente o un operatore. Audit solo in aggiunta Ogni azione su ogni regola è registrata in un log solo in aggiunta — chi ha fatto cosa e quando. Promuovere una scoperta dell'arena richiede comunque un revisore umano autenticato separatamente. Doppio controllo, imposto Le regole che possono bloccare traffico di produzione reale non si promuovono mai da sole — qualunque sia l'origine o l'impostazione. Servono due revisori autenticati, e questo requisito è imposto dal database stesso, non da un processo aggirabile. L'integrità della promozione è imposta a livello dati, non per convenzione. Come una scoperta diventa una correzione ## Da una breccia nell'arena a una protezione attiva — cinque passi revisionati Cinque fasi trasformano una breccia dell'arena in una protezione attiva. Ogni passo è registrato in un audit trail solo in aggiunta. È la stessa pipeline attraversata dalle segnalazioni dei clienti e dalla nostra intelligence tra tenant — l'arena è una delle tre fonti di segnale, non una scorciatoia. 1 · Bypass trovato Un avversario riesce a passare. La scoperta viene inviata come candidato alla revisione: ancora nulla è attivo. → 2 · Revisione umana Gli operatori vagliano ogni candidato. Di default è un'approvazione manuale; l'auto-approvazione più rapida è opzionale e si applica solo alle regole di avviso — tutto ciò che può bloccare traffico reale richiede sempre due persone. → 3 · Promozione firmata Le regole approvate vengono firmate crittograficamente, e ogni approvazione — creata, esaminata, firmata — è registrata nell'audit trail solo in aggiunta. → 4 · Distribuzione ridondante Ogni regola firmata viene scritta in due archivi con chiavi indipendenti e verificata prima che un gateway la carichi. Avvelenare il piano delle regole richiederebbe di violare più sistemi indipendenti contemporaneamente. → 5 · Osservare, poi applicare Le nuove regole girano in modalità observe per 24 ore. Se il loro tasso di falsi positivi resta pulito, vengono promosse in enforcing; in caso contrario, vengono sottoposte a rollback — confermato dall'operatore oggi, automatico in una fase successiva. Inquadramento onesto ## Cosa questa pagina dichiara — e cosa non dichiara. Ogni affermazione portante di questa pagina cita un riferimento pubblico. I punti seguenti sono i differimenti che nominiamo apposta — i CISO rispettano la divulgazione onesta dei vincoli; puniscono i vincoli scoperti per caso. - Il pressure-testing adattivo è realizzato e attivo nella nostra arena. Non si è ancora attivato in produzione — quando accadrà, lo pubblicheremo su /trust/advisories. - L'arena è il laboratorio. I bypass trovati qui non contano come rilevamenti reali. Un rilevamento promosso passa per l'approvazione di un revisore e un periodo di osservazione di 24 ore prima di applicarsi — ciò che vedi su /dashboard/threats è il risultato di quella pipeline, non l'arena direttamente. - Alla GA la lista advisories mostra un unico post-mortem sintetico, etichettato chiaramente come sintetico. L'IoC feed è vuoto per progettazione. Il sistema dice la verità — non simuliamo attività per sembrare occupati. - Le regole di avviso vengono distribuite auto-promosse al lancio. Le regole che possono bloccare traffico di produzione richiedono due revisori autenticati — e questo requisito è già imposto oggi dalla piattaforma. Dove andare ora ## Dall'arena alla sua flotta. L'arena è una delle tre fonti di segnale che alimentano l'AEGIS Protection Network — insieme alle segnalazioni dei clienti e alla nostra intelligence tra tenant. Tutte e tre passano per la stessa pipeline di promozione firmata. Il suo threat thermometer Stato live per la sua flotta su /dashboard/threats. Calm at GA by design — quando qualcosa cambia, lo vede per primo. Apri la dashboard La rete L0-L5 completa Identità delle minacce, intelligence tra tenant, l'overlay sotto attacco, la distribuzione delle regole gestite, il tuo termometro delle minacce e il feed di IoC — l'intera rete di protezione, end-to-end. Vedi /protection-network Parliamone Enterprise, settori regolamentati, deployment self-hosted — gli argomenti che meritano una conversazione, non un checkout. Contatta le vendite --- _Source: /it/arena/index.html · Generated by build-markdown-mirrors.mjs · For agent-readability commitment #4 see https://www.mnemom.ai/for-agents/_