Skip to main content
Hexgate has two policy enforcement engines that return identical decisions (a parity test suite proves it):
  • pydantic (default) — evaluates constraints in-process. Zero setup; this is what every example uses.
  • WASM — compiles policy.yaml → Rego → a WebAssembly module evaluated via wasmtime. This is the path production ships: one compiled artifact, byte-for-byte reproducible, cryptographically signed by the platform.
Why a second engine: the WASM path produces a portable, signed artifact (a “bundle”), surfaces structured deny reasons (exactly which constraints failed), and chains trust back to the platform’s signing key — the same key that signs your biscuit tokens. See internals/rego-wasm for the engineering snapshot.

​
Building a bundle

The compile step needs the opa binary — see the hexgate policy CLI.
hexgate policy build produces a directory: The manifest’s hashes authenticate the files; the signature authenticates the manifest. Verifying both proves the whole bundle came from the trusted signer, untampered.

​
Enforcing a bundle locally

Point an agent at a local source and every tool call routes through the WASM engine instead of pydantic — no platform needed. Both YAML and bundle-dir sources hot-reload on save. See local override for the two shapes and the shared refresh seam, and signing for the signature-verification matrix.