AEGIS

Observabilité indépendante au niveau OS pour les agents IA de codage

Observe ce que les agents IA font réellement sur votre machine — processus, fichiers, réseau — depuis l'extérieur des agents, sans nécessiter de hooks.

AEGIS est un observateur indépendant au niveau OS pour les agents IA. Il surveille les processus des agents, l'accès aux fichiers et l'activité réseau, quel que soit le mode de lancement de l'agent ou sa coopération avec la surveillance — et il rattache chaque observation à une instance d'agent spécifique, avec les preuves de cette attribution consignées officiellement. Construit sur un moteur de surveillance JavaScript CommonJS, avec TypeScript dans le renderer et les types partagés. Open-source, local, sans télémétrie — tout reste sur votre machine.

_{Démo enregistrée à la v0.10.0-alpha ; certains libellés ont été renommés depuis.}

Téléchargement · Signaler un bug · Demande de fonctionnalité · Contribuer

---

Ce qu'AEGIS observe

Couche	Comment
Processus	110 agents (262 signatures de noms de processus), résolution de la chaîne parente, détection de l'hôte IDE, découverte WSL et des extensions IDE
Fichiers	Surveillance chokidar des répertoires sensibles (.ssh, .aws, .gnupg, .env*, configs cloud) et des chemins de configuration enregistrés des agents connus ; détection de lecture par handles ouverts et Restart-Manager sous Windows
Réseau	TCP sortant par processus d'agent, reverse DNS à confirmation directe, et un verdict par point de terminaison — allowlisted, unknown ou flagged ; un point de terminaison non identifié n'est jamais affiché comme sûr
Comportement	73 règles de détection réparties sur 8 catégories (YAML, rechargées à chaud), lignes de base glissantes sur 10 sessions, score d'anomalie sur quatre axes (réseau / système de fichiers / processus / ligne de base)
LLM locaux	Sondes d'exécution pour Ollama et LM Studio, y compris les modèles chargés ; d'autres runtimes comme vLLM et llama.cpp sont détectés par signature de processus

Les faits comptés ci-dessus ne sont pas maintenus à la main : npm run counts:check redérive chaque compteur documenté à partir de l'arborescence à chaque exécution CI et fait échouer la build lorsqu'un nombre dans la documentation s'écarte de la réalité.

Le graphe de preuves

Ce qui distingue AEGIS d'un visualiseur de processus, ce ne sont pas les capteurs — c'est que chaque événement est rattaché à une instance d'agent, avec des preuves que vous pouvez auditer :

• Identité d'instance. Un agent est identifié par pid + heure de naissance du système d'exploitation (instanceId), de sorte qu'un PID recyclé est une nouvelle instance, et non une continuation de l'historique de l'ancienne. La mise en cache de l'identité est conditionnée par un témoin, et CI exécute une preuve d'injection (npm run verify:gate, 4 mutants) qui passe au rouge si une identité pouvait être servie depuis un cache obsolète.
• Attribution avec preuves déclarées. Chaque enregistrement d'audit porte pid, instanceId et un objet attribution avec l'un des trois statuts — confirmé, inféré ou non attribué — soutenu par un registre fermé de codes de preuve. Lorsqu'AEGIS ne sait pas quel agent a touché un fichier, il indique non attribué ; il n'invente jamais un propriétaire.
• Journal infalsifiable. Les événements d'audit sont des JSONL chaînés par hachage (Event Schema v1) avec rotation quotidienne, conservation de 30 jours et marqueurs de perte explicites lorsque le tampon d'écriture déborde.
• Mesuré, non affirmé. Le mécanisme d'identité est benchmarké dans le dépôt : la parité des heures de naissance du fournisseur était exacte pour chaque processus comparable dans les deux exécutions enregistrées (542/542 et 419/419), et le sidecar d'instantané de processus coûte ~10 ms par analyse là où le fournisseur de repli coûte des centaines à des milliers. Les tableaux par exécution, les environnements et les lacunes déclarées se trouvent dans docs/bench/.

Preuves : src/main/process-identity.js · src/main/attribution.js · audit de correction · bench 2026-08-12 · bench 2026-08-13

Monitor-first

AEGIS est une caméra, pas un gardien. Il observe et journalise — il ne bloque pas les agents au niveau OS aujourd'hui. Il n'y a pas de hooks noyau ni d'application automatique. Le contrôle des processus (kill / suspend / resume) est manuel et uniquement initié par l'utilisateur. Le blocage actif figure sur la feuille de route, pas dans la version actuelle. Utilisez AEGIS pour la visibilité, l'audit et la détection d'anomalies — associez-le à du sandboxing lorsque vous avez besoin d'une application de règles.

En quoi AEGIS diffère de la supervision intégrée à l'agent

La plupart des outils de supervision des agents IA instrumentent l'agent lui-même — un plugin Claude Code, une extension IDE, un wrapper SDK. Ce positionnement présente un angle mort structurel : un agent n'apparaît que s'il (ou son utilisateur) a installé le hook. Un python autogpt.py brut, un binaire non encapsulé ou un outil qui refuse simplement de coopérer est invisible pour l'instrumentation intégrée à l'agent.

AEGIS se place plutôt au niveau OS : il surveille l'activité des processus, des fichiers et du réseau depuis l'extérieur des agents, de sorte que ce qu'il voit ne dépend pas de la coopération de l'agent — uniquement de la couverture propre d'AEGIS (voir limites connues). Ce n'est pas le seul outil observant les agents localement — AgentSight, par exemple, observe depuis la couche eBPF sous Linux — et les outils basés sur des hooks sont complémentaires plutôt que concurrents : les hooks voient l'intention (invites, appels d'outils) à l'intérieur des agents qui ont opté, tandis qu'AEGIS voit les effets (processus, fichiers, connexions) pour tout ce qui s'exécute sur la machine, liés aux instances d'agents sans exiger de coopération.

Limites connues