Download · Segnala un bug · Richiedi una funzionalità · Contribuisci

Cosa osserva AEGIS

I fatti contati sopra non sono mantenuti a mano: npm run counts:check ricalcola ogni contatore documentato dall'albero a ogni esecuzione CI e fa fallire la build quando un numero nella documentazione si discosta dalla realtà.

Il grafo delle prove

Ciò che distingue AEGIS da un visualizzatore di processi non sono i sensori — è che ogni evento è collegato a un'istanza di agente, con prove che puoi verificare:

• Identità dell'istanza. Un agente è identificato come pid + tempo di nascita del sistema operativo (instanceId), quindi un PID riciclato è una nuova istanza, non una continuazione della storia della precedente. La memorizzazione nella cache dell'identità è vincolata da un testimone, e la CI esegue una prova di iniezione (npm run verify:gate, 4 mutanti) che diventa rossa se un'identità potesse mai essere servita da una cache obsoleta.
• Attribuzione con prove dichiarate. Ogni record di audit contiene pid, instanceId e un oggetto attribution con uno dei tre stati — confermato, dedotto o non attribuito — supportato da un registro chiuso di codici di prova. Quando AEGIS non sa quale agente ha toccato un file, dice non attribuito; non inventa mai un proprietario.
• Log a prova di manomissione. Gli eventi di audit sono JSONL concatenati tramite hash (Event Schema v1) con rotazione giornaliera, conservazione di 30 giorni e marcatori di perdita espliciti quando il buffer di scrittura va in overflow.
• Misurato, non affermato. Il meccanismo di identità è sottoposto a benchmark nel repository: la parità del tempo di nascita del provider è stata esatta per ogni processo confrontabile in entrambe le esecuzioni registrate (542/542 e 419/419), e il sidecar dello snapshot dei processi costa ~10 ms per scansione, mentre il provider di fallback costa da centinaia a migliaia. Le tabelle per esecuzione, gli ambienti e le lacune dichiarate sono in docs/bench/.

Prove: src/main/process-identity.js · src/main/attribution.js · audit di correttezza · bench 2026-08-12 · bench 2026-08-13

Monitor-first

AEGIS è una telecamera, non una guardia. Osserva e registra — non blocca gli agenti a livello di sistema operativo oggi. Non ci sono hook del kernel né applicazione automatica. Il controllo dei processi (kill / sospendi / riprendi) è manuale e solo su invocazione dell'utente. Il blocco attivo è nella roadmap, non nella release attuale. Usa AEGIS per visibilità, audit e rilevamento delle anomalie — abbinalo al sandboxing quando hai bisogno di applicazione delle regole.

Come AEGIS si differenzia dalla supervisione in-agent

La maggior parte degli strumenti di supervisione degli agenti AI strumenta l'agente stesso — un plugin di Claude Code, un'estensione IDE, un wrapper SDK. Questa collocazione ha un punto cieco strutturale: un agente compare solo se (l'agente o il suo utente) ha installato l'hook. Un python autogpt.py grezzo, un binario non avvolto o uno strumento che semplicemente non collabora è invisibile alla strumentazione in-agent.

AEGIS si colloca invece a livello di sistema operativo: osserva l'attività di processi, file e rete dall'esterno degli agenti, quindi ciò che vede non dipende dalla collaborazione dell'agente — solo dalla copertura di AEGIS stesso (vedi limiti noti). Non è l'unico strumento che osserva gli agenti localmente — AgentSight, ad esempio, osserva dal livello eBPF su Linux — e gli strumenti basati su hook sono complementari piuttosto che concorrenti: gli hook vedono l'intento (prompt, chiamate a strumenti) all'interno degli agenti che hanno aderito, mentre AEGIS vede gli effetti (processi, file, connessioni) per tutto ciò che gira sulla macchina, collegati alle istanze degli agenti senza richiedere collaborazione.

Limiti noti

Un monitor che non puoi calibrare è un monitor di cui non puoi fidarti, quindi i limiti sono dichiarati qui piuttosto che scoperti in seguito. I risultati riverificati alla base di questo elenco, ciascuno con stato OPEN/CLOSED, vivono nell'audit di correttezza; la versione breve:

• La copertura si basa su firme ed euristiche. Il rilevamento parte da 110 agenti (262 firme di nomi di processo) più euristiche (WSL, estensioni IDE, sondaggi LLM locali). Un binario di agente che non corrisponde a nessuna di queste non viene rilevato.
• Il polling ha un punto cieco. Un processo nato e morto tra i tick di scansione (~10 s) non viene mai osservato; le pagine del bench lo dichiarano esplicitamente. La cattura per evento tramite ETW è nella roadmap, con una ricognizione statica già in docs/recon/kernel-file-etw.md.
• L'identità su macOS/Linux è degradata. Quelle piattaforme attualmente non forniscono il tempo di nascita del sistema operativo, quindi l'identità dell'istanza ricade solo sul PID ed è insicura sotto il riutilizzo dei PID. Il monitoraggio dei costi dei token è solo Windows.
• Le finestre degli eventi dell'interfaccia troncano in silenzio. Il renderer mantiene finestre di eventi limitate che possono discordare dai totali, e non c'è ancora un banner di troncamento.
• La salute dei sensori è tracciata ma non ancora mostrata. Il processo principale registra la salute per sensore per i sensori di filesystem e rete, ma l'interfaccia non può ancora distinguere una macchina silenziosa da un sensore morto, e gli sforamenti della scansione dei processi vengono saltati senza un contatore.
• I marcatori di perdita dell'audit richiedono un flush riuscito. Se il processo viene terminato mentre il disco sta ancora fallendo, le voci di audit espulse possono andare perse senza un marcatore su disco.

Cosa deliberatamente non affermiamo

I numeri compaiono in questo README solo quando derivano dal repository (e sono imposti da npm run counts:check) o sono misurati con un metodo scritto. Alcuni numeri che le persone chiedono non esistono ancora, quindi non li dichiariamo:

• Tempo di avvio. Non esiste alcun benchmark di avvio; la vecchia affermazione "sotto i due secondi" è stata rimossa piuttosto che mantenuta non misurata.
• Tassi di rilevamento o falsi positivi. Esiste un bench di scenari con un oracolo indipendente (bench/, valutato contro Sysmon/Procmon), ma è solo Windows, copre uno scenario e non viene eseguito in CI — non è una base per un tasso.
• Overhead. Il costo di CPU/RAM di AEGIS stesso non è stato misurato con un metodo scritto.
• Titoli di accelerazione del benchmark. Il rapporto misurato snapshot-vs-fallback è passato da 193× a 51× tra due giorni sulla stessa macchina; l'affermazione duratura è quella più debole — snapshot ~10 ms, fallback da centinaia a migliaia di ms — ed è l'unica forma citata qui.
• Punteggi di confidenza per evento. Deliberatamente assenti dal prodotto finché non esiste un bench di verità di base.
• Conteggi dei test. I conteggi delle suite copiati a mano diventano obsoleti in silenzio; la suite stampa i propri conteggi e la CI li esegue a ogni commit.

Perché una supervisione indipendente

Gli agenti AI operano con accesso profondo a file, credenziali e comandi shell. Il rischio non è ipotetico: il resoconto di Kaspersky sul caso OpenClaw riporta che un audit di sicurezza nel gennaio 2026 ha identificato 512 vulnerabilità, otto delle quali critiche, e sostiene che il problema più profondo è architettonico — accesso locale privilegiato combinato con la capacità di comunicare esternamente (Kaspersky, 2026-02-10). Le patch correggono i bug; non ti danno visibilità su ciò che un agente ha realmente fatto sulla tua macchina. Quella visibilità è il livello che AEGIS aggiunge.

Download

Installer Windows

A partire dalla v0.11.0-alpha, le release includono un installer NSIS per Windows — scarica il .exe dall'ultima release. Le release dalla v0.13.0-alpha in poi includono anche un manifest firmato, quindi un download può essere verificato offline contro la chiave pubblica committata in questo repository — vedi Verifica di una release AEGIS. Le release precedenti non includono alcun manifest e non possono essere verificate in questo modo.

Dal sorgente (tutte le piattaforme)```bash

git clone https://github.com/antropos17/Aegis.git cd Aegis npm install npm start

Il server di sviluppo include il motore dello scenario demo — vite.config.js lo abilita ogni volta che il comando è serve, quindi la dashboard simulata viene renderizzata senza un passaggio di build separato e senza Electron. Per una build statica e condivisibile (senza server di sviluppo, senza Electron), esegui npm run build:demo e servi la directory dist/demo risultante con qualsiasi server di file statici (la build usa percorsi di asset relativi, quindi qualsiasi host funziona).

La modalità demo esegue un motore di scenario che cicla attraverso quattro fasi di minaccia — calma → elevata → critica → reset — con fino a 12 agenti AI simulati (Claude Code, Copilot, Cursor e altri). Gli eventi di accesso ai file, le connessioni di rete, i punteggi di anomalia e le valutazioni di rischio vengono tutti generati in tempo reale, così ogni scheda e funzionalità è pienamente operativa.

Usalo per valutare AEGIS prima della distribuzione, per mostrare l'interfaccia al tuo team o per sviluppare nuove funzionalità senza bisogno di un ambiente Windows live.

Cronologia delle versioni

Funzionalità

Rilevamento — 110 agenti (262 firme di nomi di processo), risoluzione della catena genitore, monitoraggio di percorsi sensibili e configurazione degli agenti, punteggio di rischio per agente con gradi di fiducia (da A+ a F), rilevamento LLM locale, marcatura dei falsi positivi

Analisi — Baseline comportamentali con medie mobili, rilevamento di anomalie multi-asse, valutazione delle minacce AI tramite l'API Anthropic (opt-in), report di minaccia HTML stampabili

Dashboard — Dashboard a griglia bento: indicatore RiskRing, TrustBadge, feed di attività con filtri, timeline delle sessioni con tooltip di attribuzione, schede agente espandibili, preset di protezione (Paranoid/Strict/Balanced/Developer), palette dei comandi (Ctrl+K), scorciatoie da tastiera (Ctrl+1-5), tema scuro/chiaro, notifiche toast, protezione OOM

Esportazione — Report JSON, CSV, HTML, archivio ZIP con un clic, log di audit JSONL con hash a catena (rotazione giornaliera, conservazione di 30 giorni)

i18n — Internazionalizzazione con base inglese (en.json); traduzioni dalla community benvenute

CLI — --scan-json per scripting, --version, --help

Ruleset YAML

• 73 regole di rilevamento in 8 categorie (config AI, segreti, SSH, cloud, browser, devtools, crypto, certificati)
• Validate rispetto a rules/_schema.json; la modifica di un ruleset ricarica a caldo senza riavvio
• Estendibile aggiungendo un .yaml in rules/. Gli ID delle regole devono essere univoci — un ID duplicato viene saltato, non sovrascritto. Un file appena aggiunto viene rilevato al successivo ricaricamento o riavvio, poiché il watcher reagisce alle modifiche nei file di primo livello esistenti

Screenshot

Catturati dalla build demo (npm run build:demo), 2026-08-21.

Architettura```

┌───────────────┐ ┌────────────────┐ ┌───────────────┐ ┌───────────────┐ │ Process │ │ File │ │ Network │ │ LLM Runtime │ │ Snapshot │ │ Watcher │ │ Monitor │ │ Detector │ │ (sidecar with │ │ (chokidar + │ │ (TCP + rDNS + │ │ (Ollama / LM │ │ CIM fallback)│ │ handle / RM) │ │ verdicts) │ │ Studio) │ └──────┬────────┘ └──────┬─────────┘ └──────┬────────┘ └──────┬────────┘ └──────────────┬───┴───────────────────┴──────────────────┘ ▼ ┌───────────────────────────────┐ │ Identity & Attribution │ │ instanceId = pid + birth time │ │ evidence codes, no guessing │ └──────┬────────────────┬───────┘ ▼ ▼ ┌──────────────────┐ ┌─────────────────────┐ │ Baselines + │ │ Audit Logger │ │ Anomaly (4-axis) │ │ (Event Schema v1, │ │ Risk Engine │ │ hash-chained JSONL) │ └──────┬───────────┘ └──────┬──────────────┘ ▼ ▼ ┌──────────────┐ ┌──────────────────┐ ┌───────────────┐ │ Dashboard │ │ Exports │ │ CLI │ │ (Svelte IPC) │ │ (JSON/CSV/HTML/ │ │ (--scan-json │ │ │ │ ZIP) │ │ --version) │ └──────────────┘ └──────────────────┘ └───────────────┘

Per-sensor health records live in the main process; surfacing them in the UI is on the roadmap.