Comment ça marche

Un moteur déterministe décide

Chaque verdict — autoriser, examiner ou bloquer — est rendu par le moteur de risque déterministe. Il est déterministe à pondérations de risque fixées : les pondérations sont un état d’exécution, et elles changent lorsque vous alimentez le moteur en signal via POST /v1/risk/feedback. Même entrée, pondérations différentes, verdict différent. Les modèles d’apprentissage automatique produisent des scores que la politique peut lire, jamais la décision. Les modèles sont épinglés par empreinte et relus depuis le reçu au rejeu, pas réexécutés. C’est ce qui rend une exécution reproductible à partir de sa propre trace : quiconque détient la clé publique peut montrer que la chaîne n’a pas été altérée après signature. La non-répudiation juridique exige une signature qualifiée, qui relève d’Enterprise · prévu.

Dictum — un DSL de politique typé, à évaluation déterministe par parcours d’arbre et doté d’un vérificateur de types Hindley-Milner — se superpose lorsque vous chargez un bundle avec iaga serve --policy. La fusion suit la règle du plus strict : une surcouche ne peut que durcir le verdict du moteur, jamais l’assouplir. Les fonctions natives de Dictum agissent sur la charge utile réelle : secret_ref() détecte les identifiants et les données personnelles, et url_host() applique une liste d’autorisation de sortie par hôte. Chaque blocage ou examen inscrit sa cause dans le reçu signé, et les reçus se chaînent par hachage sur toute une session en une seule chaîne de hachage infalsifiable.

# vérifier le type d’une politique (toujours disponible)
iaga policy check no_pii_egress.dictum

# charger un bundle Dictum comme surcouche active du profil YAML
iaga serve --policy strict.dictum

Chaque verdict est signé et chaîné

Chaque verdict devient un reçu signé en Ed25519, relié au précédent dans un journal en ajout seul chaîné par hachage, propre à chaque exécution. Le rejeu revérifie hors ligne l’intégralité de la chaîne signée. Le signataire est un trait interchangeable, et la version ouverte livre une implémentation : elle lit une clé Ed25519 de 32 octets depuis un chemin de fichier, si bien que vous pouvez injecter votre propre clé (BYOK) depuis n’importe quel coffre de secrets capable de matérialiser un fichier.

# lister les exécutions, puis en rejouer une
iaga replay --list
iaga replay <run_id>

# vérifier uniquement les signatures et les liens de hachage
iaga replay <run_id> --verify-only

N’importe qui le vérifie hors ligne

Exportez une exécution, puis vérifiez-la avec le binaire autonome iaga-verify. Il fonctionne sans base de données, sans serveur et sans appel distant. Il contrôle les signatures Ed25519 et la chaîne de hachage à partir d’une seule clé publique. C’est l’artefact que vous pouvez présenter à un auditeur : un fichier, une clé, pas de serveur.

# exporter une exécution, puis la vérifier partout, entièrement hors ligne
iaga replay <run_id> --export chain.json
iaga-verify chain.json                      # -> CHAIN OK

Une couche, pas un remplacement

IAGA Sentinel consigne une preuve signée à côté de la stack d’agents que vous exécutez déjà. Pointez n’importe quel SDK vers le sidecar HTTP (POST /v1/inspect), ou lancez le proxy MCP pour signer chaque appel d’outil. Quel que soit ce qui route ou applique les règles en dessous, la couche de preuve vient se poser par-dessus. Les reçus signés peuvent aussi alimenter votre stack OpenTelemetry sous forme de spans.