Selvedge et exécution avec preuves
A sandbox is not a witness
Running untrusted code is one of those ideas that sounds fine in a meeting because nobody has drawn the incident report yet. Let the agent call a tool. Let the plugin transform a file. Let the partner module process the data. Put it in a sandbox. Lovely. The code cannot escape. Everyone nods. Then the auditor asks what the code actually did inside the sandbox, and suddenly the room discovers that containment is not the same as evidence.
A sandbox answers one question: did the workload stay inside the boundary? That is necessary. It is not enough. The harder question is what happened during the run. Which artifact executed? Which policy was applied? Which capabilities were requested? Which host calls were allowed or denied? How much fuel, memory and time did it spend? What came out? Can the run be replayed without trusting the original machine? If those answers live in logs and confidence, the system has a costume, not an audit trail.
Selvedge exists for that gap. The page calls it the execution transcript layer for untrusted code: AION proves reasoning, Ledger records system events, and Selvedge captures execution. The implementation follows that shape. The workspace is a Rust 2024 project with crates for core digests and resource limits, execution engines, Wasmtime and Kera backends, determinism, WASI and Kera hosts, policy, AION verification, CLI, MCP, registry, runner, daemon, audit and guest SDK surfaces. The public promise is intentionally plain: Selvedge executes untrusted code under deterministic execution, policy enforcement and verification discipline.
The useful distinction is small and brutal. A sandbox says the code did not leave. Selvedge is designed to say what the code did.
The transcript is not a log
Logs are useful for humans who are already debugging. They are less usefulwhen the question is whether a run can be verified later by someone who did not trust the original host. A log line can be missing, reordered, filtered, truncated, reformatted, or explained away. A transcript has to be part of the execution contract.
Selvedge core defines SHA3-256 digests, error types, path validation, authentication tokens and shared resource limits. The README describes transcripts with hashes of bytecode, settings, stdout, stderr, output, memory and globals, plus fuel consumption and host call counts. The page describes every host call being hashed into a SHA3-256 chain and the result wrapped in an AION-style proof envelope with Ed25519 sealing. That is the difference between a system saying trust me and a system saying here is the packet.
There is a healthy bit of paranoia in that design. The artifact digest names the code. The settings digest names the deterministic profile. The transcript names what crossed the host boundary. The signed envelope makes tampering visible. Offline verification means the original runtime is not the only witness. This is the part many sandbox stories skip because it is less fun than showing a plugin running in a demo. Demos rarely ask who edited the audit log. Auditors do.
Default deny needs receipts too
Le refus par défaut est une bonne posture et un terrible slogan s'il s'arrête à la diapositive. La politique Selvedge donne des dents au slogan. Le crate de politique définit les capacités WASM telles que clock, random, filesystem, network, environment, stdio, process et custom. Il porte des limites de ressources pour la mémoire, la taille des fichiers, le nombre d'instructions et le temps. Il valide les invariants, rejette les capacités en double, fournit des erreurs structurées et mappe les échecs dans le vocabulaire de fautes commun de Dweve. Le runner applique ensuite les limites de ressources à la configuration d'exécution avant le démarrage de la charge de travail.
Cela signifie que la politique n'est pas un questionnaire auquel on répond après l'exécution. Elle est une entrée de l'exécution. Si la charge de travail demande un accès au temps, au hasard, au filesystem, au réseau, à l'environnement ou aux processus, cette demande doit passer la politique. Si elle consomme trop de fuel, de mémoire ou de temps d'horloge murale, l'exécution se termine comme un échec contrôlé. Si une politique est incohérente, elle doit échouer avant que l'artefact ne commence à faire quoi que ce soit d'intéressant. Très ennuyeux. Très utile. L'ennui est ce qui nous permet de garder nos week-ends.
Le point important est que les décisions de politique ne sont pas séparées des preuves. Un sandbox peut autoriser ou refuser une catégorie large et laisser quand même la piste d'audit mince. Selvedge est construit autour de l'idée que chaque décision de porte et chaque lecture de ressource appartient à l'histoire de l'exécution. C'est ce qui le rend utile pour les outils d'agents, l'exécution de plugins tiers, l'inférence Kera, les charges de travail réglementées et le code partenaire. Le travail peut ne pas être fiable. Les preuves ne devraient pas l'être.
Le déterminisme est là où l'hôte arrête d'improviser
La relecture est facile à promettre et difficile à tenir. L'hôte a une horloge. L'hôte a du hasard. Le comportement NaN en virgule flottante peut être délicat. La SIMD peut différer selon les architectures. Les filesystems, les variables d'environnement et l'état des processus sont d'excellents moyens de faire passer du non-déterminisme dans des endroits où personne ne l'attendait. Si vous voulez la relecture, vous devez supprimer ou contrôler ces sources avant qu'elles ne deviennent des excuses.
Selvedge fait de l'exécution déterministe la valeur par défaut. Le README décrit une horloge virtuelle fixée à l'époque 2024-01-01, un hasard ChaCha20 ensemencé, la mesure du fuel, la génération de transcription et la canonicalisation NaN. Il dit aussi que la détection SIMD est la plus rapide mais uniquement pour la même architecture, tandis que la désactivation de la SIMD est la voie entièrement portable multiplateforme. Cette dernière partie compte parce que le déterminisme n'est pas une prière. C'est une décision de configuration et d'architecture, et parfois le compromis honnête est la vitesse pour la portabilité.
Le runner utilise par défaut le backend Wasmtime avec l'exécution déterministe activée. Kera est l'autre backend, destiné aux charges de travail Graph IR et aux réseaux de neurones binaires. Cette répartition est sensée. WASM est le chemin général des composants non fiables. Kera est le chemin des graphes IA. Les deux ont besoin de la même discipline environnante : politique avant exécution, paramètres déterministes, transcription après exécution et preuve autour du résultat.
Pourquoi les agents rendent cela moins facultatif
Les systèmes d'agents remettent l'exécution non fiable au goût du jour, une phrase qui devrait faire redresser un peu l'échine à tout professionnel de la sécurité. Un modèle demande un appel d'outil. Un plugin exécute une transformation. Un script d'assistance généré touche à des données. Un outil partenaire passe par MCP. Le modèle n'a pas écrit l'outil, l'outil n'a peut-être pas été examiné avec le même soin que le code de production, et l'utilisateur s'attend toujours à ce que le système explique ce qui s'est passé. Bonne chance si la seule réponse est un répertoire de journaux et des impressions.
Selvedge dispose d'une surface serveur MCP pour les outils d'agent, d'une CLI pour les flux de travail de type build, verify, run et replay, d'un démon pour l'exécution de longue durée, de la mise en commun des exécuteurs et du préchauffage du cache, de crates de client et de serveur de registre, et d'un SDK invité. Le but n'est pas que chaque surface soit identique. Le but est que la forme des preuves soit comparable. Qu'un workload entre comme composant WASM, graphe Kera, outil d'agent ou tâche de service, l'exécution doit se terminer par quelque chose que vous pouvez vérifier.
La performance est un compromis, pas un sortilège
La page Selvedge inclut des chiffres de référence du dépôt BENCHMARKS.md : le démarrage à froid est le gain phare, le chemin à chaud est plus nuancé, Kera JIT a une histoire de graphe chaud, et Wasmtime standard conserve encore certains chemins à chaud d'appels répétés. C'est la bonne façon d'en parler. Le travail d'exécution est plein de compromis. Si un modèle de composant produit une transcription et une enveloppe de preuve, il a des coûts différents du chemin minimal. Si le démarrage à froid est votre problème, ce chemin de preuve peut aider. Si le workload est un appel répété serré sans besoin de surcharge de transcription, la réponse peut être différente. Très gênant, la réalité. Elle refuse d'être un dépliant.
La version article de l'histoire de la performance est donc simple : choisissez l'exécution en fonction du workload. N'utilisez pas une enveloppe de preuve comme potion magique de vitesse. Utilisez-la lorsque le coût de l'absence de preuve rejouable est plus élevé que la surcharge. Pour les outils d'agent, le traitement de données réglementé, les plugins tiers et l'exécution où un humain demandera plus tard ce qui s'est passé, ce coût est souvent réel.
Ce qu'il faut examiner avant de l'utiliser
Premièrement, décidez si vous avez besoin de confinement, de preuve, ou des deux. Si le workload est fiable et interne, Selvedge peut être plus de mécanique que nécessaire. Si le workload est non fiable, fourni par un partenaire, déclenché par un modèle ou destiné à un audit, la transcription commence à gagner sa place.
Deuxièmement, examinez la politique. Quelles capacités sont autorisées ? Lesquelles sont refusées ? Quelles sont les limites de carburant, de mémoire et de temps ? Le mode déterministe est-il requis ou simplement permissif ? L'accès au système de fichiers et au réseau est-il suffisamment restreint ? La politique est-elle versionnée avec l'artefact ? Si la politique vit dans un wiki et l'exécution ailleurs, la conception dérive déjà.
Troisièmement, testez le replay comme comportement de produit. N'attendez pas un audit pour découvrir si l'enveloppe se vérifie hors ligne. Exécutez le même artefact, la même politique et les mêmes entrées deux fois. Comparez les transcriptions. Essayez des capacités refusées. Cassez la somme de contrôle. Changez la graine. Désactivez SIMD si l'identité multiplateforme compte. Les tests ennuyeux sont le but.
La leçon
Selvedge n'est pas un bac à sable plus joli. C'est une couche de preuve d'exécution. Il exécute des artefacts WASM et Kera, part d'un refus par défaut, contraint les ressources, contrôle les entrées déterministes, hache l'exécution en transcriptions et enveloppe les résultats dans une enveloppe de preuve vérifiable plus tard. C'est une promesse différente de « le code est resté dans son coin ».
À mesure que les systèmes d’IA appellent davantage d’outils, exécutent davantage d’assistants générés et acceptent davantage de composants tiers, cette distinction cesse d’être théorique. La question ne sera pas seulement de savoir si la charge de travail s’est échappée. La question sera de savoir ce qu’elle a fait, sous quelle politique, avec quelles entrées, produisant quelles sorties, et si quelqu’un d’autre peut rejouer cette revendication.
Un bac à sable est un mur. Selvedge s’efforce aussi d’en être le témoin.