Sécurité en détail
Comment l'architecture se protégé elle-même
La sécurité est structurelle, pas ajoutée après coup. Chaque composant est concu avec des défauts sécurisés, et les mecanismes de protection sont hors de portée de l'agent qu'ils protegent. EasyClaw v2 ajoute trois nouvelles couches -- classifieur de permissions, hooks PreToolUse et agent de vérification -- qui renforcent les defenses existantes. Cette page détaillé les 8 couches d'enforcement et d'isolation.
Un daemon indépendant qui intercepte chaque commande shell avant son exécution. Il tourne sur un canal local, hors du workspace de l'agent, avec son code et ses politiques verrouillés par des flags d'immutabilité OS. Avec EasyClaw v2, le classifieur de permissions et les hooks PreToolUse ajoutent deux couches de filtrage en amont.
Trois niveaux d'enforcement
Les commandes dangereuses (sudo, rm -rf, chmod 777) sont automatiquement rejetées. Aucune revue humaine nécessaire.
Les commandes de lecture (git status, curl, cat) sont automatiquement autorisees. Chemin rapide, aucun délai.
Les commandes sensibles (git push, rm, kill, brew install) declenchent une demande d'approbation via iMessage avec un code de vérification unique. Timeout de 2 minutes = refus automatique.
Si le daemon plante ou devient inatteignable, TOUTES les commandes non pre-autorisees sont refusees. Fail-closed par design.
Les fichiers de configuration critiques sont protégés par des flags d'immutabilité OS. L'agent ne peut pas modifier ses propres règles, son identité ou sa configuration de sécurité.
Fichier de configuration principalManifeste d'identité de l'agentPolitique de sécuritéDéfinitions des agentsIdentité et personnalitéInventaire des outilsCode du guardian d'exécutionPolitiques guardianLe deverrouillage nécessité une intervention physique du superviseur humain.
Sécurité PIN
Toute action à fort impact nécessité un code PIN numérique connu uniquement du superviseur humain. Le PIN est change après toute suspicion de compromission et n'est jamais stocke dans les sessions de l'agent.
Implementation actuelle : PIN requis pour l'envoi d'emails, le déploiement de code, la suppression de fichiers et les modifications de configuration système.
Mail-Reader sécurisé
L'agent mail-reader tourne en mode exec allowlist. Un seul script est autorise : mail-extract avec exactement 3 flags autorises (--hours, --account, --output). Tout le reste est refuse.
--hours--account--output* (everything else)Le traitement natif iMessage est désactivé. Un daemon de surveillance iMessage poll la base de données système en continu. Chaque message entrant spawne un sub-agent one-shot isolé qui traite la demande puis se termine.
- Aucune session persistante entre les messages
- Cooldown de 24h pour les greetings par contact
- Injection automatique des briefings projet
- Timeout de 300 secondes par sub-agent
Chaque agent a ses propres permissions d'outils. L'agent principal à un accès large, tandis que les sub-agents operent avec des permissions minimales scopees à leur tâche spécifique. Un mail-reader ne peut pas déployer de code. Un bridge-reader n'a aucun outil.
| Agent | Shell | Fichiers | Réseau | Git | Deploy | |
|---|---|---|---|---|---|---|
| main | ||||||
| mail-reader | ||||||
| bridge-reader | ||||||
| kickoff-coding | ||||||
| imsg-handler |
Chaque sub-agent reçoit uniquement les permissions minimales requises pour sa tâche spécifique.
Sécurité CLI iMessage
Le CLI d'envoi iMessage utilisé des flags nommes uniquement (--to, --text). Les arguments positionnels sont rejetés. Cela empeche l'injection de commandes via le contenu des messages. Timeout de 45 secondes par envoi.
Classifieur de permissions
Avant chaque action, l'agent évalué automatiquement son niveau de risque. Lire un fichier ? Exécution immédiate. Supprimer un repertoire ? Demande de confirmation. Le classifieur prend en compte le type d'action, le contexte, l'historique utilisateur et les règles definies. Trois issues possibles : exécution autonome, demande de confirmation, ou refus avec explication.
En savoir plusSystème de hooks (PreToolUse)
Le système de hooks permet d'intercepter chaque action avant son exécution. Un hook PreToolUse peut bloquer, modifier ou logger n'importe quelle commande. Plus de 15 événements couvrent l'integralite du cycle de vie de l'agent. Les hooks sont declaratifs (JSON), chainables et conditionnels.
En savoir plusAgent de vérification adversariale
Un agent indépendant vérifie les résultats produits par les autres agents. Il applique un processus adversarial : remettre en question les conclusions, chercher les failles logiques, vérifier les sources. Ce mecanisme ajoute une couche de fiabilité sans ralentir le flux principal.
En savoir plusExec-Guardian daemon
Daemon permanent (launchd)Couche d'enforcement runtime -- chaque exécution d'outil passe par le guardian avant d'être lancee.
HOW IT WORKS
- 1Daemon indépendant exposé via un canal local dédié aux approbations d'exécution. Chaque appel exec de l'agent est intercepté
- 2Moteur de décision à 3 niveaux : auto-deny (commandes dangereuses comme rm -rf, curl vers hôtes inconnus), auto-allow (commandes sûres correspondant à l'allowlist), ask-human (cas ambigus envoyés via iMessage pour approbation humaine)
- 3Politiques définies dans un fichier de configuration verrouillé — le daemon et ses politiques sont protégés par des flags d'immutabilité OS
- 4Fail-closed : si le daemon guardian plante ou est injoignable, TOUTES les exécutions sont bloquees. L'agent ne peut pas le contourner
WHY IT MATTERS
Un agent IA avec accès shell peut tout faire. Le guardian garantit que même un agent compromis ou confus ne peut pas exécuter de commandes destructrices sans approbation humaine. C'est la dernière ligne de defense.
iMessage watcher daemon
Daemon permanent (launchd)Remplace le traitement natif d'iMessage par un pipeline de traitement de messages contrôlé et isolé.
HOW IT WORKS
- 1Interroge la base de données iMessage système toutes les quelques secondes pour les nouveaux messages. L'intégration iMessage native est désactivée
- 2Chaque message entrant spawn un sub-agent one-shot jetable : nouveau contexte, outils restreints, timeout 300s. Quand le sub-agent finit, il est detruit
- 3Cooldown de 24h pour les salutations par contact pour éviter le spam. Le contexte projet est auto-injecte selon le contact
- 4L'agent principal ne voit jamais le contenu brut d'iMessage -- seul le sub-agent le voit. Si le sub-agent est compromis par un message, les degats sont contenus
WHY IT MATTERS
iMessage est un vecteur d'attaque : quiconque connaît le numéro de telephone peut envoyer des injections de prompt. Le watcher isole chaque message dans un bac à sable jetable. Un message malveillant tue un sub-agent -- l'agent principal n'est pas affecte.
permission-classifier
Actif en continu (inline)NEWDeuxième etage de contrôle au-dessus d'exec-guardian. Évalué le risque de chaque action en fonction du type, du contexte et de l'historique utilisateur.
HOW IT WORKS
- 1Chaque action passe d'abord par le classifieur avant d'atteindre exec-guardian. Le classifieur analyse : type d'action (lecture/écriture/suppression), portée (local/distant), reversibilite
- 2L'historique des permissions accordees ou refusees par l'utilisateur est pris en compte. Si l'utilisateur a déjà autorise ce type d'action 10 fois, le seuil de confirmation baisse
- 3Trois issues possibles : exécution autonome (risque faible), demande de confirmation (risque moyen), ou refus avec explication (risque élevé)
- 4Le classifieur s'adapte progressivement aux préférences de chaque utilisateur via un mecanisme d'apprentissage
WHY IT MATTERS
Exec-guardian applique des règles statiques. Le classifieur de permissions ajoute une couche d'intelligence contextuelle : il apprend quand demander et quand laisser passer, reduisant le bruit tout en maintenant la sécurité.
En savoir plushooks (PreToolUse)
Déclenchement événementielNEWSystème d'interception extensible. Un hook PreToolUse peut bloquer, modifier ou logger n'importe quelle action avant son exécution.
HOW IT WORKS
- 1Les hooks sont déclarés en JSON dans la configuration de l'agent. Chaque hook écoute un événement spécifique (on_tool_call, pre_response, etc.)
- 2Un hook PreToolUse intercepté chaque appel d'outil avant exécution. Il peut bloquer l'action, la modifier, ou la logger dans un audit trail
- 3Les hooks sont chainables : plusieurs hooks peuvent écouter le même événement, s'executant dans l'ordre de priorité defini
- 4Plus de 15 événements couvrent l'integralite du cycle de vie de l'agent, du message entrant à la réponse finale
WHY IT MATTERS
Les hooks permettent de personnaliser la sécurité sans modifier le code de l'agent. Un hook d'audit enregistré chaque action, un hook de conformite bloque les actions non autorisees, un hook de notification alerte en temps réel.
En savoir plusvérification-agent
Observation passive continueNEWAgent indépendant en lecture seule qui audite les actions des autres agents en temps réel. Ne peut pas modifier de fichiers ni exécuter de commandes.
HOW IT WORKS
- 1L'agent de vérification reçoit un flux en temps réel de toutes les actions exécutées par les autres agents (commandes, modifications de fichiers, appels API)
- 2Chaque action est évaluée contre un ensemble de règles : respect des permissions, cohérence avec les instructions, conformite aux bonnes pratiques
- 3Le système identifié les patterns suspects : répétition inhabituelle d'actions, accès a des ressources non attendues, résultats incoherents
- 4Les anomalies détectées generent des alertes classees par sévérité : info, warning, critical. Les alertes critical interrompent l'action en cours
WHY IT MATTERS
Un agent qui peut tout faire et qui se vérifie lui-même n'est pas fiable. Un agent indépendant, en lecture seule, qui observe depuis l'extérieur, apporte une couche de fiabilité fondamentale. C'est le principe de separation des pouvoirs applique à l'IA.
En savoir plus