Skip to content

Guard and source validation

The guard includes the sasy-watch daemon, native hook and enforcing policy profile. Public usage guidance lives at guard.sasy.ai.

To use a built runtime, install the wheel for your operating system and architecture:

Terminal window
uv tool install /path/to/sasy_guard-VERSION-PLATFORM.whl
sasy-guard install
sasy-guard enable /path/to/project
sasy-guard doctor
cd /path/to/project
claude

Replace the wheel placeholder with the actual tested artifact. enable writes the project’s Claude Code hook settings. This source preparation does not publish release artifacts. A native bundle is another distribution format; its install.sh installs binaries, and its bundled plugins/sasy-guard/init-project.sh configures a project.

The core preparation export includes source for the guard and its Python runtime package. make guard uses the isolated SDK/daemon build helper. The restricted engine is built with make build-rust-restricted; it bakes the security and deny-all profiles. The release bundle script combines that engine with the daemon and native hook. Do not publish a development wheel as the restricted runtime wheel.

This export deliberately omits historical transcripts and deployment-specific test fixtures. The public core gate runs the retained hermetic source suites and engine-backed guard tests. It does not claim coverage from omitted historical fixtures. Before release, run that gate against the final export and validate installation of the built wheel in a clean environment. Missing helper paths or EXPORT-REVIEW.json dependency findings are blockers, not successful validation.

A daemon-managed local engine uses mutual TLS: both processes verify launch-generated certificates, and the daemon refuses to attach to an unrelated process already using the engine port. The shipped engine generates the certificates; OpenSSL is not an installation prerequisite. These local credentials override inherited TLS_CA_PATH, TLS_CERT_PATH and TLS_KEY_PATH, including values loaded by Bun from a checkout’s .env. Remote endpoints retain their operator-provisioned TLS configuration. An insecure remote connection must not be used to carry production credentials.

Configure a remote engine with sasy-watch setup --mode remote --endpoint engine.example:443. The first remote setup requires an explicit endpoint, including when switching from local mode; it does not inherit the local loopback endpoint or plaintext setting. Re-running setup can reuse an endpoint already saved in remote mode. Local setup continues to default to localhost:50051.