TECHNIQUE / AI-GUARD
Ce qui décide. Ce qui exécute.
Ce qui laisse une trace.
Une lecture de l’architecture documentée, de ses limites et de la cible du projet.
Explorer le code sur GitHub ↗Rust pour les mécanismes.
Une interface pour comprendre.
Des adaptateurs pour le terrain.
Architecture locale documentée.
Docker / Podman, rootless par défaut.
README : « Ce que le produit fait », « Lire les actions et les événements » et « Exporter, vérifier et arrêter ». Le relais HTTP d’entrée est omis pour la lisibilité ; il est distinct du relais métier inter-workers cible.
Documentation fournie · 29 octobre 2026
Architecture fournie, sections 2 et 3 ; rectification du 29 octobre 2026 dans PRODUCTION_READINESS. Le nombre de workers dessiné illustre les frontières et ne démontre aucune capacité.
Documentation fournie · 29 octobre 2026Le cadre local documenté sépare le broker de confiance, le dashboard consultatif et les workers Docker / Podman. Rootless est le mode par défaut. Cette présentation ne remplace pas les tests du runtime et de sa configuration.
LOCAL DOCUMENTÉL’interface explique. Le broker décide du lancement. Le runtime porte les restrictions d’exécution.
Ces rôles ne sont pas interchangeables. Le choix de Rust, un journal ou une décision d’IA ne suffisent pas à prouver le confinement.
README : « Ce que le produit fait », « Profils de sécurité », « Jev optionnel » et « Limites à connaître ». Architecture : section 6, cycle d’une action et reprise ; ce contrat documentaire ne constitue pas une preuve d’exécution.
Documentation fournie · 29 octobre 2026Le README décrit une copie filtrée dans un volume de session, un worker non privilégié, une racine en lecture seule et un réseau coupé par défaut. L’export vise une nouvelle destination.
Inspecter les montages, droits et restrictions sur le moteur choisi. Le broker, le moteur et leur administrateur restent de confiance.
Les profils strict, review et observe encadrent l’invocation soumise au broker. La demande et sa décision sont tracées ; un refus ou un audit obligatoire indisponible bloque ce parcours.
Cette décision ne contrôle pas individuellement toutes les commandes internes d’un agent ou d’un script. Le réseau bridge optionnel ne fournit pas de filtrage applicatif.
L’audit SQLite est indépendant du worker. Il distingue demandes, décisions, démarrages observés et résultats. Les déclarations des fournisseurs restent identifiées comme telles.
Les sorties Codex/Claude décrites sont normalisées après la session. Une valeur absente reste inconnue. Persistance, reprise et intégrations demandent leurs propres preuves.
Le README décrit un client Jev en Rust, désactivé par défaut. Il apporte une aide à la décision ; un refus déterministe ne devient pas une autorisation.
Les essais auprès du service réel restent à confirmer. Jev ne remplace ni le broker ni le confinement du runtime.
README : « Ce que le produit fait », « Exporter, vérifier et arrêter », « Limites à connaître ». Architecture : section 3, séparation des fichiers et des clients.
Documentation fournie · 29 octobre 2026Deux workers pour le client A.
Un pour le client B.
Choisissez une route. Testez la règle.
Lancez un échange pour découvrir la décision et sa trace.
Cette interaction explique le modèle d’autorisation cible, dont le relais n’est pas présenté comme livré. Elle ne démontre ni le confinement d’un runtime, ni la qualification de sécurité du produit.
Le projet est ouvert sous Apache-2.0 et poursuit son développement.
Le tableau sépare les mécanismes décrits dans la documentation des cibles et de leur qualification. Il ne remplace pas les résultats courants du dépôt.
Copie, broker Rust, workers Docker/Podman, dashboard, audit et export sont décrits dans le README. La disponibilité et les limites d’une version se vérifient dans le dépôt.
Chaque couple système/moteur, chaque intégration agent et les scénarios de panne doivent disposer de leurs propres résultats reproductibles.
Le registre multi-client, les quotas, le relais métier et le registre d’usage ne sont pas annoncés comme livrés. L’orchestration Kubernetes et l’offre cloud restent à construire et qualifier.
Le dossier de préparation à la production rectifie d’anciennes annonces de fonctions livrées. Les tests historiques ne qualifient pas automatiquement la version actuelle. Les fichiers docs/engineering/CURRENT_STATE.md et docs/engineering/VALIDATION.md sont les références d’avancement indiquées par le projet.