Skal LLL-værktøjer køres i en WebAssembly-sandkasse?

I takt med at Large Language Models (LLM’er) forlader forsknings­laboratorierne og bliver en integreret del af virksomheds-IT, opstår et helt økosystem af LLL-værktøjer (LLM-baserede Libraries & Layers). De mest fremtrædende kategorier er:

1. Agentrammer - fx LangChain, Semantic-Kernel og Auto-GPT, som orkestrerer værktøjer, eksterne API-kald og flertrins-reasoning på tværs af modeller.
2. Plugins/“tools” - små stykker kode der udvider en chatbot eller et agentmiljø med domænespecifik funktionalitet, databaser, e-handel osv.
3. Prompt-pipelines - skabeloner, chain-of-thought-prompts og retrieval augmented generation (RAG) workflows, ofte versioneret og delt som open source-pakker.

Trusselsbilledet: Når kreativ kode møder følsomme data

LLL-værktøjer er software-moduler, typisk skrevet af tredjeparter og distribueret via GitHub, npm/pip eller container-registre. Det giver en række sikkerheds­udfordringer:

Hvorfor isolation og kontrollerbarhed er nøglen i fremtidens it

Traditionelle modforholdsregler-code review, lintere, containerisering-dækker kun delvist. LLL-værktøjer er dynamiske; de genererer og fortolker tekst, kalder API’er på baggrund af bruger- eller modeloutput og kan ændre adfærd over tid. Derfor har vi brug for:

• Finmasket capabilities: “Dette plugin må kun læse /data/faq.json”, “må kun kalde HTTPS mod api.firma.dk”.
• Deterministisk ressourcestyring: CPU-tid, hukommelse og I/O-kvoter skal kunne sættes pr. værktøj for at undgå denial-of-wallet i skyen.
• Auditerbarhed: Det skal være spor-bart hvem (model, bruger, plugin) der forsøgte at gøre hvad - og om han fik lov.

Her kommer WebAssembly-sandkassen ind i billedet. WASM/WASI tilbyder en minimal execution engine hvor hver modul kun får de kapabiliteter værtssystemet eksplicit tildeler-præcis den isolation vi har brug for, når promptlogik og agenter pludselig skal køres side om side med virksomhedsdata.

Med andre ord: I en verden hvor AI-komponenter bliver lige så lette at installere som en browser-udvidelse, er kontrollerbar udførelse ikke længere et “nice-to-have”, men en forudsætning for at høste LLM’s produktivitets-gevinster uden at kompromittere sikkerhed og compliance.

WebAssembly (WASM) starter som nul-rettigheder. Når en LLL-komponent - fx et plugin til et agent-framework - indlæses via WASI-grænsefladen, skal host-platformen eksplicit give adgang til:

• Fil-systemet — begrænset til udvalgte mapper (pre-opened dirs).
• Netværket — fx kun HTTP GET mod en bestemt API-whitelist.
• Ur/clock — kan helt frakobles for deterministiske builds.

Dermed bliver angrebsfladen drastisk mindre end i et traditionelt Python- eller Node-plugin, hvor alt for ofte hele OS-brønden er åben. Isolationen håndhæves af den binære WASM-VM, ikke af bibliotekskode, hvilket blokerer klassiske sandbox-breakouts såsom LD_PRELOAD, ptrace eller uautoriserede syscalls.

Politikker, kvoter og audit-spor

Ud over hvad modulet må tilgå, kan hosten styre hvor meget:

• CPU-tid / instruktionstæller - stop infinite loops og crypto-mining.
• RAM-kvoter - WASM-heapen er let at måle og nuke på OOM.
• I/O-rate - f.eks. max 10 MiB netværk/minut.

Alle syscalls passerer gennem et entydigt API-lag - ideelt til structured logging. Resultatet er et audit-spor, der både tilfredsstiller sikkerheds- og compliance-teams og letter debugging af prompt-pipelines, hvor output ofte afhænger af eksterne API-svar.

Portabilitet fra browser til edge og cloud

Én og samme .wasm-artefakt kører problemfrit:

• I browseren som client-side agent-plugin (ingen serverlatens, fuld GDPR-kontrol).
• På edge-platforme som Cloudflare Workers eller Fastly Compute@Edge - starttid < 1 ms.
• I cloud-backends via run-times som Wasmtime, WasmEdge eller container-orkestrering med runwasi.

Dermed undgår man “write once, port everywhere”-mareridtet, hvor udviklere ellers skal opretholde separate builds til browser (ESM), server (Docker) og embedded.

Sammenligning: Wasm vs. Containere og vm’er

Containers giver dog stadig mening, hvor vi bevidst vil køre komplekse sprog-runtimes eller har behov for fuld POSIX. VM’er bevarer relevans til legacy-systemer med kernel-afhængigheder. For LLL-værktøjer, der hovedsageligt laver API-kald og håndterer teksttokens, er WASM-profilen ofte den optimale balance.

Compliance og data-minimering

Ved at lade hosten kontrollere datadioderne opfyldes GDPR’s princip om “privacy by design”:

• Adgang til PII kan begrænses til nødvendige felter.
• Outbound-trafik kan proxy-es eller pseudonymiseres før exit.
• Audit-loggen muliggør dokumentation af behandlingsaktiviteter til datatilsynet.

Derudover forhindrer sandboxen utilsigtet dataeksfiltration via prompt-injection eller bibliotekssårbarheder – en væsentlig faktor når tredjeparts-plugins får lov at “tale” med sprogmodeller, der i værste fald kan lokkes til at udlevere følsomme oplysninger.

Bottom line: WASM/WASI giver en letvægts-, portabel og granulært kontrollerbar køreplatform, der matcher LLL-økosystemets behov for hurtig iteration uden at gamble med sikkerhed eller compliance.

Når man taler om Large Language-Linked-værktøjer (LLL) - agent-rammer, plugin-økosystemer og avancerede prompt-pipelines - er ydelse ofte det første spørgsmål, der melder sig: Er WebAssembly ikke bare endnu et tolkningslag, der sænker hastigheden? Svaret er både ja og nej og afhænger af, hvordan man pakker og kører sin kode.

Jit vs. Aot & opstartstid

• JIT (Just-In-Time): Standarden i mange WASM-runtimes i dag. Byte-koden kompileres til maskinkode ved første kørsel. Fordel: hurtigere build-tid og fleksibel cross-platform. Ulempe: kold opstart kan ligge 5-40 ms højere end native.
• AOT (Ahead-Of-Time): Runtimes som WasmEdge og Wasmtime tilbyder pre-kompilering til host-arkitektur. Det skærer 80-90 % af opstartstiden væk og giver ~5-10 % bedre steady-state-performance, men byggerne bliver platform-specifikke.
• For LLL-workloads med mange short-lived lambda‐invocationer er AOT klart at foretrække; til langlivede agenter er forskellen marginal.

Simd, tråde og ffi-kald

WASM SIMD (128-bit) er nu udbredt, og de fleste ML-libraries (fx onnx-runtime-wasm) udnytter det. Multi-trådede WASM med atomics virker i server-runtimes, men kræver flags i browseren. Til datasultne LLL-plugins kan man derfor:

1. Uddelegere tunge tensor-operationer til et internt onnx eller ggml modul, der kører SIMD.
2. Bruge host-calls til et native bibliotek. Men: hvert FFI-hop ~ 50-300 ns; tusindvis af hops per token kan æde hele gevinsten.

Tommelregel: Hold inferens inde i WASM, og lad kun I/O gå via FFI.

Gpu & andre acceleratorer

• WebGPU: Eksperimentelt i Wasmtime og i browseren; kan mappes til Vulkan/CUDA/Metal. Velegnet til in-tab Browser-inferens, men driver-support halter stadig i server-miljøer.
• WASI-NN: Abstraktions-layer hvor WASM-modulet udsteder neurale inferens-kald, og værten vælger CPU, GPU eller TPU. Endnu preview, men allerede anvendt af Shopify til edge-ML.
• Samlet overhead i dag ~ 3-10 % ift. native CUDA, primært pga. to ekstra kopier ind/ud af WASM-heap’en.

Ressourcekvoter, determinisme & cache

WASI tillader granular allokering af --max-mem=<MB>, CPU-tid og endda wall-clock adgang. Kombineret med epoch-based interruption kan man stoppe runaway-plugins deterministisk uden at dræbe hele processen.

LLL-modeller er dog ofte > 200 MB. Strategi: Cache modellen i delt hukommelse udenfor WASM (tmpfs/ramdisk) og map den read-only ind i flere WASM-sandkasser; man får isolation uden duplication.

Udvikleroplevelse (dx): Toolchains & runtimes

De fleste udviklere starter i Rust/C, men tinygo, jco (Java--> WASM) og pyodide sænker barrieren. Continuous profiling via wasm-tools + perf giver desuden overraskende nøjagtige call-graphs til optimering.

Overhead vs. Native - Den praktiske bundlinje

I rene CPU-workloads ligger WASM typisk 5-20 % bag native C/Rust i steady state. I LLL-workflows domineret af I/O og netværk er forskellen sjældent målelig. Den ekstra sikkerheds- og governance-gevinst fra capability-modellen overstiger derfor ofte omkostningen - hvis man vælger AOT, minimerer FFI-hops og udnytter model-caching.

Så konklusionen for ydelses- og DX-spørgsmålet er enkel: WebAssembly er ikke et gratis måltid, men det er heller ikke junkfood. Brug de rigtige opskrifter, og du får et letvægts-containerlag med tilstrækkelig rå muskelkraft til de fleste LLL-scenarier.

Arkitekturmønstre i praksis

1. Plugin-sandbox
   Formål: Indkapsle tredjeparts-plugins fra et LLL-økosystem (f.eks. agent-skills eller prompt-filtre).
   Implementering: Hvert plugin kompileres til et selvstændigt WASM-modul, som hosten loader dynamisk og kun giver eksplicitte WASI-capabilities (filer, net, env). Tilpassede host calls kan begrænse API-overfladen yderligere.
   Fordel: Plugins kan skrives i valgfrit sprog → større community; minimeret blast-radius hvis koden er ondsindet eller bare fejlbehæftet.
2. Data-diode
   Formål: Sikre envejs-flow af følsom data (eks. fra on-prem til public cloud).
   Implementering: To WASM-instanser kører i samme host: én læser rådata og sender kun validerede felter over en in-memory kanal til den offentligt eksponerede instans. Manglende capability til at åbne sockets fra “indre” modul håndhæver dioden på runtime-niveau.
   Fordel: Ingen trafik slipper ud, selv ikke ved RCE; lettere at auditere end iptables-magi.
3. Policy-enforcement layer
   Formål: Central håndhævelse af sikkerheds- og compliance-regler (GDPR, dataminimering).
   Implementering: Rego/OPA-lignende policies kompileres til WASM og injiceres i pipelinen, så alle forespørgsler og svar passerer igennem samme verificerbare bytecode.
   Fordel: Hot-swap af regler uden at genudrulle baseline-kode; deterministiske auditable beslutninger.
4. Netværks-proxy i edge-miljøer
   Formål: Køre letvægts-gateways tæt på brugeren (CDN pops, 5G MEC) uden at vedligeholde fulde containere.
   Implementering: WasmEdge eller Wasmtime indlejret i Nginx/Envoy; hver request spinner en WASM-handler med <1 ms cold-start.
   Fordel: Multi-tenant isolering med langt lavere memory-tryk end micro-VM’er.

Hvornår giver wasm (ikke) mening?

• Giver mening: Når du har uens build-miljøer, hyppig plugin-rotation, begrænsede CPU-/RAM-kvoter eller brug for streng capability-styring.
• Tvivlsomt: Hvis du allerede kører i trusted, homogene containere hvor alle værktøjer kompilere+driftes samlet; hvis du kræver massiv GPU-offload (endnu eksperimentelt i WebGPU/WASI-NN); eller hvor in-process FFI latency er mission-critical (f.eks. HFT-trading).

Typiske use cases

Roadmap: Wasi preview 2 & component model

• Preview 2 (Q4 2023 → 2024): Stabiliseret streams, reactor og async; lettere binding til host-events.
• Component Model: Modulært import/export af typer, så forskellige sprogkomponenter kan linkes uden FFI-smerte (tænk “npm for WASM”).
• Interface Types v2: Automatisk serialisering af komplekse struct-typer, hvilket gør det muligt at udstille LLM-API’er direkte imellem moduler.
• GPU-extensions: WebGPU-backends og wasi:nn for on-device inference; stadig prototype men hurtigt modnende.

Pragmatisk beslutningsguide

1. Klassificér trusselsbilledet: Har du uautoriseret tredjepartskode eller følsomme data? Ja → WASM værd at teste.
2. Mål latens & throughput: Kør A/B-benchmarks (native vs WASM) med realistisk workload. Overhead <10 %? Sandsynlig grøn lys.
3. Evaluer økosystem: Findes der WASI-bindings til den ML- / NLP-ramme du bruger? Hvis nej, budgettér tid til wrappers.
4. Start småt: Isolér kun de mest risikable plugins i første iteration. Mål driftsomkostninger (RAM, cold-start).
5. Iterér & automatisér: Brug CI-pipelines til automatisk kompilering til WASM, security-scan og policy-signering.

Bottom line: WebAssembly er ikke et sølvkugle-panser, men et skræddersyet værktøj til de dele af LLL-stakken hvor usikker kode, portabilitet og ressourcekontrol krydser hinanden. Vælg det dér - og kun dér - hvor forretnings- og sikkerhedsværdien klart opvejer den ekstra kompleksitet.