# ai-guard — Cadrage du projet Dépôt : https://github.com/Needdoliprane/ai-guard Licence : Apache-2.0, selon le README fourni. Domaine cible : https://ai-guard.ovpt.ai Référence documentaire : 29 octobre 2026. ## Objet ai-guard est un projet open source local-first pour exécuter une commande ou un agent dans une copie isolée d'un projet, consulter les décisions et événements, puis exporter les résultats. Le nom du binaire documenté est `agentsandbox`. Cette synthèse distingue les mécanismes décrits dans les documents fournis, leur qualification à vérifier et la cible encore à réaliser. Elle ne constitue ni un audit du code courant ni un compte rendu de tests du produit. ## Mécanismes locaux documentés - La CLI et le broker Rust pilotent Docker ou Podman depuis le poste de confiance. Aucun conteneur applicatif ne reçoit le socket du moteur. Aucun repli métier sur l'hôte n'est prévu si le moteur est absent. - Chaque session utilise une copie filtrée dans son volume. Le projet original n'est pas monté ; l'export crée une destination neuve et contrôlée. - La politique décide avant le lancement. Un refus ou une indisponibilité de l'audit bloque le parcours. Les profils `strict`, `review` et `observe` portent sur l'invocation confiée au broker. - Le worker est configuré sans privilèges, avec racine en lecture seule, réseau `none` par défaut et limites de ressources. L'application effective de ces restrictions dépend du moteur et doit être observée sur la machine cible. - L'audit SQLite reste indépendant du worker. Le dashboard Rust sert un frontend TypeScript et reste séparé du domaine de confiance de l'agent ; son rôle est consultatif. - Le relais d'entrée HTTP local décrit dans le README publie le dashboard et le collecteur. Il est distinct du relais métier inter-workers encore prévu. - Jev est optionnel et désactivé par défaut. Il ne peut pas élargir une permission refusée par la politique déterministe et ne fournit pas le confinement. ## Essai local documenté Le README fourni fixe Rust 1.99.1 pour la CLI. Docker avec le plugin Compose ou Podman avec un fournisseur Compose est nécessaire. Les ports locaux 4000 et 8787 doivent être libres. Node 24 est utilisé pour le build des images et n'est nécessaire sur l'hôte que pour le développement direct du frontend. Le mode rootless est exigé par défaut. L'exception `--allow-rootful-runtime`, notamment pour Docker Desktop lorsqu'il ne signale pas rootless, doit être choisie explicitement sur les commandes concernées ; les sessions enregistrent `runtime.security_downgrade`. Une VM n'est pas une preuve de rootless. Le premier scénario du README lance `/usr/bin/id` avec le profil `strict` et la capture de sortie. Les résultats attendus comprennent l'UUID de session, le volume, le code de sortie et le nombre de fichiers modifiés si le scan aboutit. Ce parcours n'a pas été exécuté pour réaliser la vitrine. ## Observation et limites Demande, décision, soumission au runtime, démarrage observé et résultat sont distincts. La provenance observée, déclarée ou inférée est séparée du niveau d'intégration Native / Observée / Générique. Une donnée absente reste inconnue. Les parseurs Codex et Claude décrits traitent le stdout borné en fin de session ; ils ne prouvent pas le contrôle préalable de chaque outil et ne reconstruisent pas les sous-agents natifs. L'image générique ne contient aucun CLI fournisseur. Les versions, comptes, images et interfaces réelles doivent être vérifiés pour chaque intégration. Le réseau `bridge`, lorsqu'il est explicitement demandé, ne fournit pas de filtrage applicatif sortant. Un secret injecté reste lisible par le code du worker ; le masquage dans l'audit ne change pas cette propriété. La chaîne de hashes locale ne résiste pas à une réécriture complète par l'administrateur. ## Qualification actuelle à vérifier Le README décrit des essais locaux et renvoie aux résultats courants, mais le code de la révision actuelle et ses preuves n'ont pas été audités pour cette vitrine. Aucun résultat historique ou sur fixture n'est transféré à une plateforme, une version fournisseur ou une release différente. Les couples moteur/plateforme, les restrictions réellement appliquées, les sessions fournisseurs, la reprise et la restauration demandent leurs preuves propres. La qualification production n'est pas acquise d'après les documents fournis. Le site n'annonce aucune certification ni compatibilité universelle. ## Fonctions prévues : relais, multi-client et cloud La rectification placée en tête de `PRODUCTION_READINESS.md`, datée du 29 octobre 2026, indique l'absence constatée des modules `tenancy.rs`, `control.rs`, du registre, des quotas, du relais métier et du ledger auparavant annoncés comme livrés. Ces affirmations historiques sont contredites ; elles ne servent pas de preuve de disponibilité. La cible prévoit une identité client authentifiée, l'appartenance exclusive des workers, des autorisations dirigées de communication, leur révocation, des quotas et un ledger d'usage. L'adaptateur Kubernetes, les transports cloud, le stockage, les politiques réseau et la résilience demandent une implémentation et une qualification dédiées. Aucun service hébergé, tarif ou mécanisme de facturation disponible n'est annoncé. Le scénario cible A1/A2 chez le client A et B1 chez le client B sert à vérifier les autorisations, les refus entre clients et la révocation sur de vrais runtimes. Le scénario interactif de la vitrine en simule seulement les décisions dans le navigateur : il ne lance aucun conteneur et ne prouve pas l'isolation. ## Sources et suite - [Dépôt et README](https://github.com/Needdoliprane/ai-guard) - [Démarrage Docker ou Podman](https://github.com/Needdoliprane/ai-guard#démarrer-avec-docker-ou-podman) - [Tests et test moteur explicite](https://github.com/Needdoliprane/ai-guard#vérifier-le-logiciel) - [Limites documentées](https://github.com/Needdoliprane/ai-guard#limites-à-connaître) - [Index des documents, dont validation courante et acceptation](https://github.com/Needdoliprane/ai-guard#documentation) Le README fourni, `architecture(2).md` et la rectification de `PRODUCTION_READINESS.md` fondent cette synthèse. Les liens partent de la racine du dépôt ; aucune branche par défaut n'est présumée. Le raccordement du domaine cible reste distinct de la publication de la vitrine.