Selvedge och genomförande med kvitton
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
Default deny är en bra utgångspunkt men en usel slogan om det stannar vid presentationen. Selvedge-policyn ger slogans verklig kraft. Policydefinitionen definierar WASM-funktioner som clock, random, filesystem, network, environment, stdio, process och custom. Den bär resursbegränsningar för minne, filstorlek, instruktionsantal och tid. Den validerar invarianter, avvisar dubblerade funktioner, ger strukturerade fel och mappar fel till Dweves gemensamma felvokabulär. Körningen tillämpar sedan resursbegränsningarna på exekveringskonfigurationen innan arbetsbelastningen startar.
Det innebär att policyn inte är ett frågeformulär som besvaras efter körningen. Den är indata till exekveringen. Om arbetsbelastningen begär tid, slumpmässighet, filesystem, network, environment eller processåtkomst, måste den begäran passera policyn. Om den förbrukar för mycket fuel, minne eller väggklockstid, avslutas körningen som ett kontrollerat fel. Om en policy är inkonsekvent ska den misslyckas innan artefakten börjar göra något intressant. Väldigt tråkigt. Väldigt användbart. Tråkighet är hur vi räddar helgerna.
Den viktiga poängen är att policybeslut inte är åtskilda från bevis. En sandlåda kan tillåta eller neka en bred kategori och ändå lämna granskningsspåret tunt. Selvedge är byggd kring idén att varje gate-beslut och resursavläsning hör hemma i berättelsen om körningen. Det är det som gör den användbar för agentverktyg, exekvering av tredjepartsplugin, Kera-inferens, reglerade arbetsbelastningar och partnerkod. Arbetet kan vara icke betrott. Bevisen ska inte vara det.
Determinism är där värden slutar improvisera
Replay är lätt att lova och svårt att hålla. Värden har en klocka. Värden har slumpmässighet. Flyttals-NaN-beteende kan vara besvärligt. SIMD kan skilja sig mellan arkitekturer. Filsystem, miljövariabler och processstatus är utmärkta sätt att smuggla in icke-determinism på platser där ingen förväntade sig det. Om du vill ha replay måste du ta bort eller kontrollera dessa källor innan de blir ursäkter.
Selvedge gör deterministisk exekvering till standard. README beskriver en virtuell klocka fixerad till 2024-01-01-epoken, seedad ChaCha20-slumpmässighet, fuel-mätning, transkriptgenerering och NaN-kanonisering. Den säger också att SIMD-detektering är snabbast men endast för samma arkitektur, medan inaktivering av SIMD är den fullt portabla plattformsoberoende vägen. Den sista delen spelar roll eftersom determinism inte är en bön. Det är ett konfigurations- och arkitekturbeslut, och ibland är den ärliga växlingen hastighet mot portabilitet.
Körningen använder som standard Wasmtime-backend med deterministisk exekvering aktiverad. Kera är den andra backend, inriktad på Graph IR och binära neurala nätverksarbetsbelastningar. Den uppdelningen är förnuftig. WASM är den allmänna vägen för icke betrodda komponenter. Kera är AI-grafvägen. Båda behöver samma omgivande disciplin: policy före exekvering, deterministiska inställningar, transkript efter exekvering och bevis kring resultatet.
Varför agenter gör detta mindre valfritt
Agentsystem gör oövervakad exekvering modernt igen, vilket är en mening som borde få varje säkerhetsperson att sitta lite rakare. En modell ber om ett verktygsanrop. Ett plugin kör en transformation. Ett genererat hjälpskript rör data. Ett partnerverktyg kommer via MCP. Modellen skrev inte verktyget, verktyget kanske inte granskas med samma omsorg som produktkod, och användaren förväntar sig ändå att systemet förklarar vad som hände. Lycka till med det om enda svaret är en loggkatalog och vibbar.
Selvedge har en MCP-serveryta för agentverktyg, ett CLI för bygg-, verifierings-, kör- och replay-liknande arbetsflöden, en daemon för långvarig exekvering, runner-poolning och cache-värmning, klient- och servercrates för registry samt ett gäst-SDK. Poängen är inte att varje yta är densamma. Poängen är att bevisformen ska vara jämförbar. Oavsett om en arbetsbelastning kommer in som en WASM-komponent, en Kera-graf, ett agentverktyg eller ett servicejobb, ska körningen sluta med något du kan verifiera.
Prestanda är en avvägning, inte en trollformel
Selvedge-sidan innehåller benchmark-siffror från repositoryts BENCHMARKS.md: kallstart är den stora vinsten, den varma sökvägen är mer nyanserad, Kera JIT har en varm graf-historia, och vanlig Wasmtime håller fortfarande vissa varma sökvägar för upprepade anrop. Det är rätt sätt att prata om det. Runtime-arbete är fullt av avvägningar. Om en komponentmodell producerar ett transkript och ett beviskuvert har den andra kostnader än minimivägen. Om kallstart är ditt problem kan den bevisvägen hjälpa. Om arbetsbelastningen är ett tätt upprepat anrop utan behov av transkript-overhead kan svaret vara annorlunda. Mycket obekvämt, verkligheten. Den vägrar att vara en broschyr.
Artikelversionen av prestandaberättelsen är därför enkel: välj runtime efter arbetsbelastning. Använd inte ett beviskuvert som en magisk hastighetsdryck. Använd det när kostnaden för att inte ha replaybar bevisning är högre än overheaden. För agentverktyg, reglerad databehandling, tredjepartsplugin och exekvering där en människa senare kommer att fråga vad som hände, är den kostnaden ofta verklig.
Vad du ska granska innan du använder det
Först, bestäm om du behöver avgränsning, bevisning, eller båda. Om arbetsbelastningen är betrodd och intern kan Selvedge vara mer maskineri än nödvändigt. Om arbetsbelastningen är oövervakad, partnerlevererad, modellutlöst eller granskningsinriktad börjar transkriptet förtjäna sin plats.
För det andra, granska policyn. Vilka förmågor är tillåtna? Vilka är nekade? Vilka är bränsle-, minnes- och tidsgränserna? Är deterministiskt läge krävt eller bara tillåtet? Är filsystem- och nätverksåtkomst tillräckligt snäv? Är policyn versionshanterad med artefakten? Om policyn lever i en wiki och exekveringen någon annanstans, har designen redan börjat driva.
För det tredje, testa replay som ett produktbeteende. Vänta inte på en granskning för att upptäcka om kuvertet verifieras offline. Kör samma artefakt, samma policy och samma indata två gånger. Jämför transkript. Prova nekade förmågor. Bryt checksumman. Ändra seed. Inaktivera SIMD om plattformsoberoende identitet spelar roll. De irriterande testerna är poängen.
Lärdomen
Selvedge är inte en snyggare sandlåda. Det är ett exekveringsbevislager. Det kör WASM- och Kera-artefakter, börjar med standardsväv, begränsar resurser, kontrollerar deterministiska indata, hashkodar exekvering till transkript och lindar in resultat i ett beviskuvert som kan kontrolleras senare. Det är ett annat löfte än att koden höll sig i sitt hörn.
När AI-system anropar fler verktyg, kör fler genererade hjälpprogram och tar emot fler tredjepartskomponenter, slutar den distinktionen att vara akademisk. Frågan kommer inte bara att vara om arbetsbelastningen rymde. Frågan kommer att vara vad den gjorde, under vilken policy, med vilka indata, vilka utdata den producerade, och om någon annan kan återspela det påståendet.
En sandlåda är en vägg. Selvedge försöker också vara vittnet.