Acronym quick index →
New to Web4?This page tours real, runnable software, so it assumes the vocabulary (LCT, trust tensors, witness chain). If those terms are new, start with the 2-minute TL;DR, then come back - what's here is real, open-source software you can run yourself, the proof Web4 works in practice and not just on paper. Every term is spelled out in the TL;DR; definitions also live in the glossary (Aa, bottom-left).
Enterprise oversight tier
Reference

Hardbound

Hardbound is the enterprise oversight tier. It governs every actor in an organization (human and AI alike) through hardware-bound cryptographic identity, multi-witness trust, and pre-action policy enforcement, producing audit trails defensible to regulators.

Where Hestia is the local-first trust layer for a single entity, Hardbound is the tier that hardens a whole organization: it takes the same Web4 trust primitives and puts them under enterprise-grade identity, policy, and evidence. See the onramp for how the four pieces compose.

The problem it solves

Enterprises deploy AI agents faster than oversight can keep up. When something goes wrong they cannot answer the basic questions: who did what, when, why were they trusted to do it, and can you prove it? Config files and log lines do not settle those questions, and regulators are starting to ask them.

Hardbound answers each one by construction. It binds every actor to a hardware identity, records every action in signed audit bundles that carry a snapshot of the actor's trust at the moment they acted, and enforces policy before the action rather than flagging it after. It targets EU AI Act Article 12 and SOC 2 CC6 to CC8 evidence.

Three pillars

Hardware identity

Each actor (person or agent) is bound to a hardware-rooted cryptographic identity, so an action can be traced to who really took it, not just to an API key that could be anyone.

Multi-witness trust

Trust is not self-asserted. Every action lands in a signed audit bundle with a snapshot of the actor's trust standing, witnessed rather than claimed, so the record is defensible after the fact.

Pre-action policy

Policy is checked before the action, against a server-side signed policy entity. Plugins call in to ask permission; they cannot self-approve, so the thing being governed does not get to grade its own homework.

How you actually touch it

Operationally it is a CLI and a server. You stand up an organization, add the people and agents in it, then run the policy server that everything checks against.

Set up an org

hardbound init --org ..., then hardbound add-member / add-agent, then hardbound dev (server on :9400). Or bring it up with docker-compose up -d.

Wire in your orchestrator

Integrate any orchestrator (Claude Code, LangChain, CrewAI, AG2) via a single HardboundPlugin class that calls evaluateAction() against the signed policy entity. MCP servers (policy / audit / web4-trust) and Python bindings (via PyO3) are also exposed.

Where it is on the maturity ladder (read this)

Hardbound is Reference and this page will not call it "production-ready." It is a usable, actively-hardened enterprise tier with real code behind it: a single ~3.8 MB static Rust binary that cross-compiles to arm64 / Jetson, backed by 300+ Rust integration tests. It is real software you can run, not a slide deck.

But be clear about what is not yet done. The hardware binding (TPM 2.0) is not yet validated on-device: CI uses trait-based mocks, the real hardware calls exist in the code, but on-device Jetson integration is deferred. The threat model still documents about ten open gaps. This is R&D, not a fielded production product, and the wider Web4 stack is R&D too.

We call that out on purpose. An oversight tier that overstated its own maturity would defeat the point of being trustworthy.

Hardbound is the fourth of the four Web4 pieces: the core standard, the hub, Hestia, and this. See how they fit together, and what Hardbound is built on.

Glossary