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.
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.
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.
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.
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.
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.
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.
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.
Parliamone
Enterprise, settori regolamentati, deployment self-hosted — gli argomenti che meritano una conversazione, non un checkout.
