Verbond: Don't let software pull the rug from under your feet.
Even if you can't access its source code or the system its running on.
-
WASM-based workflows and applications.
-
Security Guarantees that can you (and your users) can verify automatically.
-
Remote sandboxes with trust rooted in hardware (coming in 2027).
-
Builds on tooling and practices you're likely already using.
Supply chain attacks.
STATE SPONSORED HACKING.
Data leaks
CHINA
Insider threats.
SCAMMERS.
Privacy violations.
Non-determinism.
AI AI AI
AI AI
AI
MORE REGULATION
AI AI AI
AI AI
AI
AI AI AI
AI AI
AI
You're probably aware things are a little chaotic in software right now.
Which makes it clearer than ever: The majority of software shouldn’t be trusted.
Even if you wanted to trust it, well, how could you?
Much of the code is closed source, or runs inside opaque external systems outside your control.
In cases where you do have control and access to the code, reviews are slow and only cover a point in time.
So instead of going against the grain, Verbond allows you to embrace untrusted code.
How it works
Verbond builds on top of WASM, allowing for great control on what capabilities are exposed to the code.
By default code can’t do anything but accept input data, do some computation and output a result:
If you’re a developer and your code needs more capabalities, you’re required to declare them in advance. These capabilities (and more such rules), live inside a Verbond Contract.
For example, if your code needs to communicate with a specific external API, it needs an accompanying Contract that lists that API:
Side-channels: Our approach is to mitigate when possible. If not, we communicate the risks clearly when displaying Contracts.
In the diagram, any input value provided to code can potentially
be exposed to good api.
It’s possible to structure Contracts so that input exposure is limited.
Contracts are managed in a way that’s similar to package-management as you know it.
Additionally, the tooling allows you to pin the ruleset of the Contract independent of non-rule content (like Code).
If you pin to a known-good ruleset, you will know the exact security posture of any code executed. Even if you can’t or haven’t reviewed the source code.
Just to be clear, this won’t solve every problem in the world. A dependency called add(1, 1) might start returning 3 instead of
2. However, Verbond will make it very clear when this code suddenly “needs” the capability to communicate with evil.example.com.
In our opinion, that’s pretty cool.
Local and Remote Sandboxes
A Contract is enforced by a Sandbox.
Local Sandboxes assume they run inside a trusted environment you control. They can be created via our CLI or embedded in your Go/Rust code.
More details coming soon.
In the future we’ll publish detailed information regarding threat model.
Spoiler: We’re using Confidential’s Computing Trusted Execution Environments (TEE’s), so inherit their properties.
Remote Sandboxes are a central feature to Verbond’s design.
They derive their trust from their environment.
Like a local sandbox, a Remote Sandbox enforces Contracts. But, a Remote Sandbox also exposes the available Contracts to its clients.
Before a client verifies a Contract, it will verify the integrity of the environment to ensure the integrity of the Remote Sandbox.
The code may live inside the environment, as it only has to be available to the Remote Sandbox. The client only needs the Contract.
This is what enables Verbond to provide security guarantees for remote systems, without exposing the source code to clients.
Local Runtime Beta coming in 2026
Remote runtime planned for next year
Follow us on Bluesky or subscribe below to be the first to know when the beta is available.