Selvedge e execução com provas
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
Defaultdeny é uma boa postura e um péssimo slogan se ficar pelo diapositivo. A política Selvedge dá dentes ao slogan. O crate de política define capacidades WASM como clock, random, filesystem, network, environment, stdio, process e custom. Transporta limites de recursos para memória, tamanho de ficheiro, contagem de instruções e tempo. Valida invariantes, rejeita capacidades duplicadas, fornece erros estruturados e mapeia falhas para o vocabulário comum de falhas Dweve. O runner aplica então os limites de recursos à configuração de execução antes de o workload começar.
Isto significa que a política não é um questionário respondido depois da execução. É uma entrada para a execução. Se o workload pedir tempo, aleatoriedade, filesystem, network, environment ou acesso a process, esse pedido tem de passar pela política. Se gastar demasiado fuel, memória ou tempo de relógio, a execução termina como uma falha controlada. Se uma política for inconsistente, deve falhar antes de o artefacto começar a fazer algo interessante. Muito aborrecido. Muito útil. É o aborrecimento que nos garante fins de semana.
O ponto importante é que as decisões de política não estão separadas das evidências. Uma sandbox pode permitir ou negar uma categoria ampla e ainda assim deixar o registo de auditoria fino. Selvedge é construída em torno da ideia de que cada decisão de gate e leitura de recursos pertence à história da execução. É isso que a torna útil para ferramentas de agentes, execução de plugins de terceiros, inferência Kera, workloads regulados e código de parceiros. O trabalho pode não ser de confiança. As evidências não devem ser.
Determinismo é onde o host deixa de improvisar
Replay é fácil de prometer e difícil de manter. O host tem um relógio. O host tem aleatoriedade. O comportamento de NaN em vírgula flutuante pode ser complicado. SIMD pode diferir entre arquiteturas. Filesystems, variáveis de environment e estado de process são excelentes formas de introduzir nondeterminismo em sítios onde ninguém o esperava. Se quiser replay, tem de remover ou controlar essas fontes antes de se tornarem desculpas.
Selvedge torna a execução determinística o padrão. O README descreve um relógio virtual fixado na época 2024-01-01, aleatoriedade ChaCha20 com seed, medição de fuel, geração de registo e canonicalização de NaN. Também diz que a deteção de SIMD é a mais rápida mas apenas para a mesma arquitetura, enquanto desativar SIMD é a via totalmente portável entre plataformas. Essa última parte importa porque determinismo não é uma oração. É uma decisão de configuração e arquitetura, e por vezes a troca honesta é velocidade por portabilidade.
O runner usa por defeito o backend Wasmtime com execução determinística ativada. Kera é o outro backend, orientado para Graph IR e workloads de redes neuronais binárias. Essa divisão faz sentido. WASM é o caminho geral para componentes não confiáveis. Kera é o caminho para grafos de IA. Ambos precisam da mesma disciplina envolvente: política antes da execução, definições determinísticas, registo após a execução e prova em torno do resultado.
Porque é que os agentes tornam isto menos opcional
Os sistemas de agentes tornaram a execução não confiável novamente elegante, o que é uma frase que deveria fazer qualquer profissional de segurança sentar-se um pouco mais direito. Um modelo pede uma chamada de ferramenta. Um plugin executa uma transformação. Um script auxiliar gerado toca em dados. Uma ferramenta de parceiro chega via MCP. O modelo não escreveu a ferramenta, a ferramenta pode não ser revisada com o mesmo cuidado que o código de produto, e o utilizador ainda espera que o sistema explique o que aconteceu. Boa sorte com isso se a única resposta for um diretório de logs e intuições.
Selvedge tem uma superfície de servidor MCP para ferramentas de agente, uma CLI para fluxos de trabalho de construção, verificação, execução e repetição, um daemon para execução de longa duração, agrupamento de executores e aquecimento de cache, crates de cliente e servidor de registo, e um SDK convidado. O ponto não é que cada superfície seja igual. O ponto é que a forma da evidência deve ser comparável. Quer uma carga de trabalho entre como um componente WASM, um grafo Kera, uma ferramenta de agente ou um trabalho de serviço, a execução deve terminar com algo que se possa verificar.
Desempenho é uma troca, não um feitiço
A página da Selvedge inclui números de referência do BENCHMARKS.md do repositório: o arranque a frio é a vitória principal, o caminho quente é mais matizado, o Kera JIT tem uma história de grafos quentes, e o Wasmtime simples ainda detém alguns caminhos quentes de chamadas repetidas. Essa é a forma correta de falar sobre isso. O trabalho de runtime está cheio de trocas. Se um modelo de componente produz um transcript e um envelope de prova, tem custos diferentes do caminho mínimo. Se o arranque a frio é a sua dor, esse caminho de evidência pode ajudar. Se a carga de trabalho é uma chamada repetida apertada sem necessidade de sobrecarga de transcript, a resposta pode ser diferente. Muito inconveniente, a realidade. Recusa-se a ser um folheto.
A versão em artigo da história de desempenho é, portanto, simples: escolha o runtime para a carga de trabalho. Não use um envelope de prova como uma poção mágica de velocidade. Use-o quando o custo de não ter evidência reproduzível for maior do que a sobrecarga. Para ferramentas de agente, processamento de dados regulado, plugins de terceiros e execução onde um humano mais tarde perguntará o que aconteceu, esse custo é frequentemente real.
O que rever antes de usar
Primeiro, decida se precisa de contenção, evidência, ou ambos. Se a carga de trabalho é confiável e interna, a Selvedge pode ser mais maquinaria do que o necessário. Se a carga de trabalho é não confiável, fornecida por parceiros, acionada por modelo ou sujeita a auditoria, o transcript começa a ganhar o seu lugar.
Segundo, reveja a política. Quais capacidades são permitidas? Quais são negadas? Quais são os limites de combustível, memória e tempo? O modo determinístico é obrigatório ou meramente permissivo? O acesso ao sistema de ficheiros e à rede é suficientemente restrito? A política é versionada com o artefacto? Se a política vive num wiki e a execução vive noutro lugar, o design já está a derivar.
Terceiro, teste a repetição como um comportamento de produto. Não espere por uma auditoria para descobrir se o envelope verifica offline. Execute o mesmo artefacto, a mesma política e as mesmas entradas duas vezes. Compare os transcripts. Tente capacidades negadas. Parta o checksum. Mude a seed. Desative SIMD se a identidade entre plataformas for importante. Os testes irritantes são o ponto.
A lição
A Selvedge não é uma sandbox mais bonita. É uma camada de evidência de execução. Executa artefactos WASM e Kera, começa com negação por defeito, restringe recursos, controla entradas determinísticas, transforma execução em transcripts com hash, e envolve resultados num envelope de prova que pode ser verificado mais tarde. Essa é uma promessa diferente de o código ficou no seu canto.
À medida que os sistemas de IA chamam mais ferramentas, executam mais auxiliares gerados e aceitam mais componentes de terceiros, essa distinção deixa de ser académica. A questão não será apenas se a carga de trabalho escapou. A questão será o que ela fez, sob que política, com que entradas, produzindo que saídas, e se outra pessoa consegue reproduzir essa alegação.
Uma sandbox é uma parede. A Selvedge tenta ser também a testemunha.