Skip to main content
The SDK enforces policy in one of three modes. They share the same enforcement seam and the same HexgateContext scope — they differ only in where the policy lives and who runs the infrastructure. Remote enforcement is just an env var. HEXGATE_API_URL defaults to https://app.hexgate.ai, so the hosted path needs only HEXGATE_API_KEY. Self-hosting is the identical SDK code with HEXGATE_API_URL repointed.
  • Local — no platform at all. Enforce a YAML file or bundle from disk, hot-reload on save. Best for the inner dev loop and CI.
  • Hexgate Cloud — the fastest path to remote enforcement + an audit trail. Sign up, mint a token, set one env var. No infra to run.
  • Self-hosting — run the control plane, dashboard, and audit store inside your own infrastructure for data residency, air-gapped environments, or compliance.
Know which mode you want? Follow the platform workflow — mint a key, register, edit the policy, test, deploy — start to finish.

What the platform gives you (hosted or self-hosted)

The SDK works fully without it (load_local_agent, local YAML enforcement) — but with the platform you get:
  • A web dashboard for editing agent policies and viewing the project graph
  • Mintable dev tokens (fty_test_*, fty_live_*) that authenticate the SDK
  • A live Playground that streams tool calls and decisions from your running agent
  • Turn-level policy refresh — edit YAML in the UI, the next chat picks it up
  • An audit trail of every decision in ClickHouse

Start on Hexgate Cloud

The zero-infra path — see Hexgate Cloud for the full walkthrough:

Or run the platform locally

To run the whole control plane on your own machine — for self-hosting, or just to develop against it — you need three terminals:
First-time setup (each sub-project has its own deps):
Point the SDK at your local platform by setting HEXGATE_API_URL=http://localhost:8000 alongside a key minted by that instance. See control plane for the production self-hosting guide.