Why Voltx's Extension Framework doesn't run your code

When we designed the Marketplace's Extension Framework, the obvious approach was some flavor of sandboxed JavaScript execution — an iframe, a Web Worker, a WASM runtime — letting developers ship arbitrary UI code that runs inside a customer's own workspace. We decided against it.

Sandboxing arbitrary code safely is its own large, ongoing security project, not a feature you bolt onto a release. Every sandbox has a history of escapes. And for the actual use case — a marketplace app rendering a settings page, a dashboard widget, or a data table — a fixed, declarative component palette gets you nearly everything a real integration needs without ever executing a byte of third-party code in the browser.

So that's what we built: a Custom Page or Widget is a JSON manifest describing a tree of components from a fixed, versioned palette — table, stat-card, form, chart, and a handful of others — plus data-source bindings that the installing organization's own web app executes as an authenticated API call. The manifest is validated against that exact palette at submission time, before a platform admin ever reviews it, so a malformed manifest never even reaches the review queue.

Custom AI Tools follow the same philosophy from a different angle: rather than running developer code in our AI runtime, a Custom AI Tool is an HMAC-signed HTTPS call to the developer's own endpoint — the same trust model as an outbound webhook, just invoked by the model instead of an event. The response is validated against the tool's own declared JSON Schema before it's ever handed back to the model as fact.

The trade-off is real: a developer can't ship a fully custom, bespoke UI the way they could with arbitrary code. What they get instead is an app that renders through the same component system every first-party Voltx screen uses — consistent, reviewable, and running in every customer's workspace without asking anyone to trust a third party's JavaScript.