Intégrité des éléments de preuve
- Hash canonique déterministe
- Contrôles de la liaison requête/réponse enregistrée
- Vérification hors ligne du bundle en mode fail-closed
AELITIUM / version v0.3.0 / Apache-2.0
Éléments de preuve d’interactions LLM enregistrées, contrôlés hors ligne.
Une bibliothèque Python open source et une CLI qui produisent des bundles d’éléments de preuve et contrôlent leur cohérence interne selon un schéma gouverné et un contrat de canonicalisation.
Même hash de requête. Hash de réponse différent. Un cas d’usage concret au sein d’un modèle d’évaluation plus large.
Capture prise en charge
OpenAI / Anthropic / LiteLLM
Éléments de preuve AELITIUM
payload canonique + manifeste
Vérificateur hors ligne
états d’évaluation distincts
Cohérence principale
- payload_integrity
- VALID
- binding_field_consistency
- VALID
- invocation_identity_consistency
- VALID
- invocation_binding_consistency
- VALID
Optionnel / selon la politique
- signature_validity
- ABSENT
- trusted_signer_identity
- UNESTABLISHED
- freshness
- NOT_EVALUATED
- authorization
- NOT_EVALUATED
Combinaison d’états fournie à titre d’exemple. Les dimensions optionnelles et dépendantes de la politique varient selon les éléments présents dans le bundle et les paramètres explicitement fournis au vérificateur.
Indicateurs d’ingénierie
v0.3.0
Version publiée
529
Tests par version de Python
3.10 to 3.12
CI Python
OpenAI · Anthropic · LiteLLM
Intégrations de capture prises en charge
release audit + public-claims guardrail
Contrôles de publication
Version actuelle
Ce qu’ajoute v0.3.0
v0.3.0 ajoute des contrôles d’évaluation distincts au-delà du flux de hash principal.
Cohérence de l’invocation
- Identité d’invocation versionnée
- Cohérence du hash d’identité d’invocation
- Cohérence de la liaison enregistrée entre le hash d’identité d’invocation et le hash de réponse
Confiance et politique
- Validité de la signature Ed25519
- Correspondance avec un trust store externe explicite
- Récence de l’horodatage déclaré selon des paramètres de politique explicites
Couverture des fournisseurs
- Parcours de capture OpenAI, Anthropic et LiteLLM
- Analyse statique des sites d’appel LLM Python potentiellement non capturés
Modèle d’évaluation
Huit dimensions, rapportées séparément.
Chaque dimension est rapportée séparément. Selon la dimension, les éléments présents et les paramètres fournis au vérificateur, un état peut être VALID, INVALID, ABSENT, UNESTABLISHED ou NOT_EVALUATED.
Contrôles de cohérence principaux
Contrat des éléments de preuve enregistrés
Évalués indépendamment lorsque leurs prérequis sont présents.
payload_integrity
contrôle du bundle
Cohérence du payload, du schéma, des octets canoniques, du manifeste et du hash du payload.
binding_field_consistency
si présent
Cohérence entre les champs enregistrés de hash de requête, de réponse et de liaison v1.
invocation_identity_consistency
si présent
Cohérence de la structure et du hash de l’identité d’invocation versionnée enregistrée.
invocation_binding_consistency
si présent
Cohérence du lien enregistré entre le hash d’identité d’invocation et le hash de réponse.
Optionnel / selon la politique
Éléments et paramètres explicites
Ces contrôles dépendent d’éléments explicites ou de paramètres fournis au vérificateur.
signature_validity
si présent
Contrôle la validité de la signature Ed25519 lorsque le matériel de signature est présent. La dimension peut être ABSENT sauf si une signature est exigée.
trusted_signer_identity
paramètre externe
Correspondance exacte de l’empreinte de clé avec un trust store externe explicitement fourni. Sinon, l’état est UNESTABLISHED.
freshness
politique explicite
La récence de l’horodatage déclaré utilise un âge maximal et une heure de référence UTC explicites. Aucune horloge implicite n’est utilisée.
authorization
non évalué
Aucune décision d’autorisation n’est implémentée. Cette dimension reste toujours NOT_EVALUATED dans v0.3.0.
Où l’utiliser
Usages concrets
Quatre workflows concrets pour les développeurs, disponibles dans v0.3.0.
Comparer des exécutions enregistrées
REQUEST_HASH
SAME
RESPONSE_HASH
DIFFERENT
Comparer les éléments de preuve de deux exécutions et détecter lorsqu’un même hash de requête enregistrée est associé à des hash de réponse enregistrée différents. AELITIUM signale la différence sans en attribuer la cause.
Contrôler un bundle hors ligne
bundle d’éléments de preuve
aelitium verify-bundle
états d’évaluation
Contrôler hors ligne la cohérence interne d’un bundle d’éléments de preuve régi par le contrat avant de l’utiliser dans une revue, une investigation ou un workflow en aval.
Repérer des lacunes potentielles de capture
source Python
aelitium scan
sites d’appel potentiels
Analyser le code source Python à la recherche de sites d’appel LLM potentiels qui peuvent ne pas utiliser un parcours de capture AELITIUM pris en charge.
Contrôler la couverture dans la CI
pull request
aelitium scan ./src --ci
résultat CI
Exécuter le scanner AELITIUM dans la CI pour signaler les sites d’appel LLM Python potentiels sans instrumentation de capture prise en charge.
Cas concret
Même hash de requête. Hash de réponse enregistrée différent.
Deux bundles peuvent avoir le même hash de requête enregistrée et des hash de réponse enregistrée différents. La comparaison n’attribue aucune cause.
A Exécution A
« Résumez en une phrase les principaux risques liés au déploiement de LLM en production. »
Les principaux risques comprennent les sorties non déterministes, les vulnérabilités d’injection de prompt, les faits hallucinés et l’absence d’éléments de preuve inspectables.
response_hash: 2f1563cc8c0b7b71…
B Exécution B
« Résumez en une phrase les principaux risques liés au déploiement de LLM en production. »
Les principaux risques sont les hallucinations, les fuites de données, les injections de prompt adverses et les changements de comportement imprévisibles après des mises à jour silencieuses du modèle.
response_hash: c41d8e3b5f9a2201…
REQUEST_HASH=SAME
RESPONSE_HASH=DIFFERENT
Les champs sélectionnés de la requête enregistrée ont le même hash de requête v1. Les hash de réponse enregistrée diffèrent. AELITIUM rapporte les champs comparés sans attribuer de cause.
Démo interactive
Examiner une variation du hash response-text.
Modifiez l’une des réponses enregistrées. Cette démo dans le navigateur compare les valeurs SHA-256 du texte de réponse. Elle n’effectue pas de vérification de bundle.
DÉMO LOCALE DANS LE NAVIGATEUR
Aucun texte ne quitte la page. Le hash de requête affiché ci-dessous est une hypothèse fixe de la démo et n’est pas calculé ici.
Mécanisme
Capture → Hash → Bind → Verify
AELITIUM crée des bundles d’éléments de preuve pour les interactions LLM enregistrées et contrôle hors ligne l’intégrité du payload ainsi que la cohérence des liaisons et des données d’invocation enregistrées. Les résultats restent séparés pour les signatures optionnelles, la correspondance avec un trust store externe explicite et la récence de l’horodatage déclaré.
Capture
Enregistre des champs sélectionnés de la requête et de la réponse sur les parcours d’adaptateur pris en charge.
from aelitium import capture_openai
Hash
Calcule des valeurs request_hash et response_hash déterministes.
request_hash
response_hash
Bind
Relie les hash de la requête enregistrée et de la réponse enregistrée avec binding_hash.
request_hash + response_hash
→ binding_hash
Verify
Contrôle hors ligne la cohérence d’un bundle régi par le contrat et échoue en mode fail-closed si les éléments de preuve sont invalides.
aelitium verify-bundle ./evidence
binding_hash = SHA256(canonical({request_hash, response_hash}))
Limite explicite
Ce qu’AELITIUM vérifie et ce qu’il ne prétend pas établir.
La cohérence interne est délibérément distincte des affirmations sur l’exécution par le fournisseur ou l’absence de modification historique.
Ce qu’AELITIUM vérifie
- Cohérence du payload régi par le contrat, de la représentation canonique, du manifeste et du hash du payload.
- Cohérence des champs enregistrés de requête, de réponse et de liaison v1 lorsque les éléments de liaison sont présents.
- Cohérence de l’identité d’invocation versionnée enregistrée et de la liaison enregistrée entre l’identité d’invocation et la réponse lorsqu’elles sont présentes.
- Validité mathématique de la signature lorsque le matériel est présent, ainsi que la correspondance avec un trust store externe et la récence de l’horodatage déclaré lorsque des paramètres explicites sont fournis.
Ce qu’AELITIUM ne prétend pas établir
- L’authenticité du fournisseur, l’exécution par le fournisseur ou un lien de causalité avec la réponse.
- La véracité, la sûreté ou la correction sémantique du résultat.
- Une référence temporelle historique fiable ou l’absence de modification historique à partir du seul bundle.
- L’autorisation, la conformité juridique ou la capture complète des événements réels.
Commencer
Examinez vous-même un bundle d’éléments de preuve.
Installez le package Python, capturez un parcours d’appel pris en charge et contrôlez hors ligne le bundle obtenu.
$ pip install aelitium · également sur PyPI