Your data runs through code you can’t check.
Know where your data can go before third-party code runs. Verbond shows the worst case up front and blocks everything else.
Why data leaks
AI-authored code, dubious dependencies and stressed-out developers.
None of this is what causes supply chain attacks and data leaks. Mismatched assumptions between the environment and the code are.
So you don’t need to check all of the code. You need to check the assumptions.
The most important assumptions are about data flow: who and what may receive which information.
Verbond makes these assumptions explicit and encodes them in its contracts. Anyone can see where a function’s inputs may travel before they invoke that function.
Verbond won’t prevent bugs in your functions, but it can stop them from sending data to https://evil.example.com unexpectedly.
Verbond contracts are designed so that:
- Their guarantees can be independently verified, without access to the source code the contract covers.
- They are efficient to review. When you depend on a contract, you choose the level of detail you’re interested in.
Who it’s for
Where it fits, and where it doesn’t yet
A good fit
- Your module runs in your customer’s infrastructure. Every security review asks what it sends home, and you answer with a questionnaire nobody can check.
- You run a plugin platform. Any plugin update can reach somewhere new, and your reviewers can’t read every diff.
- One function handles the sensitive data. It runs in your customer’s environment, yet the whole release gets the scrutiny meant for that one function.
Not a fit yet
- A customer who must check a service they don’t run. That needs attested remote environments, which are on the roadmap.
- Long-running jobs, stateful services and GPU workloads.
- Code that can’t compile to a WebAssembly component.
How it works
From code to enforced contract
You declare where your functions may send data. Your users approve that once, and Verbond holds every call to it until a release changes what they approved.
Declare
Publisherat development timeCompile
Publisherin CI/CD- shape
- 9f3a·41c2
- impl
- c71e·08bd
- exposure
- 2 hosts
- binaries
- 3 × .wasm
- pinned by
- SHA-256
Endorse
Userin CI/CD, or by handEnforce
Userat runtimeOn a release
An example contract
What you’d review before depending on a function
This is a single function of a contract, as the contract page shows it when you endorse that contract. It’s not a mock-up: Verbond compiled this example’s contract and drew the page from it.
Security
What we promise you, and how we check it
Everything here rests on the contracts and the runtime isolation. If isolation fails, no contract can hold. So we don’t ask you to take it on trust: the threat model names every assumption and says how far each promise is. The assurance case, which argues each promise from the source code, is published with the source.
If you find an issue in the design or code, we’d love to hear it at security@verbond.dev.
- 01
Data goes only where the contract says.
in progress
Through data flow, a task’s data reaches only the services the contract names for that task. Exceptions are explicitly documented.Still to do: some tests and structural checks. - 02
The exposure doesn’t rely on the author’s word.
in progress
Verbond derives it as an upper bound: each service learns about the caller’s data only what its exposure lists.Still to do: reviewing the written proof. - 03
What runs is what was checked.
in progress
The binaries that run are the ones the contract was checked against.Still to do: some tests, and the checks that there’s only one way to load code. - 04
Digests change exactly when the contract does.
in progress
Any change to a contract changes its identity digest. Its shape digest changes only when its API or exposure does, so a release with the same shape digest can’t change where your inputs may go.Still to do: the written proofs and some tests. - 05
Code execution requires endorsement.
planned
The runtime only runs a function under a contract the user has endorsed.Still to do: the design is done; the runtime doesn’t check endorsements yet.
- planned
- Designed, not built. Don’t rely on it yet.
- in progress
- Built in full or in part, and the evidence that it holds isn’t complete yet.
- holds
- Built, every test passes, and the argument for it has no open items. No promise holds yet.
how it’s checked
Each promise rests on named claims. Every built claim names the code that keeps it and the tests that show it does, and most add a mutation test: a deliberate break the tests must catch.
- claims
- 57
- code complete
- 42
- code partial
- 8
- planned
- 7
182 of 251 tests, mutants and structural checks written
as of 27 Oct 2026 · from the assurance case
Limits
- Timing is a signal. A task can signal a service it may call by how long it takes, up to its timeout. Whether it finishes is counted in the exposure; closing the timing signal is designed, not built.
- The promises rest on assumptions stated in the threat model: a trusted environment, Wasmtime’s sandbox, and TLS and SHA-256.
- Exposure is an upper bound. It’s derived per input, down to record fields, and counts a task as sending everything it was given to every service it may call.
- Network access is the only capability covered. Storage is being designed.
Out of scope
- Whether your code is correct. Verbond runs code it doesn’t inspect, so it can’t promise that
sum(1, 1)returns2. It can promise that callingsumsends nothing to anyone the contract doesn’t name. - What allowed services do with your data. Once data reaches a service the contract names, what happens to it is up to that service, including handing it to a later task in a response.
- The integrity of your machine. Verbond assumes the environment it runs in is trusted.
- Remote environments. The promises cover machines you control. Attested remote environments come later.
- Hardware side channels. When Verbond runs on your machines, it doesn’t control the hardware, so micro-architectural side channels are out of scope.
Roadmap
What’s built, and what’s next
What exists today, and what we’re building next. Early access partners can use what’s built.
built
- Contract compilation
- Contract measurement and exposureexposure per input, down to record fields
- Contract-driven runtime
- HTTP capability
- Command-line tool
- Local environment
- Execution via manual linkingyou supply each contract’s binaries yourself, until registries are built
- Public threat model
next
- Endorsement checks in the runtimesingle-party first; the design is done
- Contract management via OCI images and registries
- Source published under Apache 2.0with the assurance case and claims register
later
- Capabilities beyond HTTPstorage first; the design is under way
- Multi-party endorsement
- Attested remote environments
Early access
Try it on one function.
We’re looking for a few design partners. Tell us which function handles your customers’ data and who needs to check it. We’ll reply to set up a short call and get you running on the local runtime.
Not ready yet?
Get an email when something ships.
You’ll get a link to confirm first, and can unsubscribe from any email. Sent with Kit; see privacy.