Skip to main content
The platform lets you author an agent’s policy in a browser and enforce it in production without redeploying. This is the end-to-end sequence a developer follows. (Platform overview covers where it runs — local, Hexgate Cloud, or self-hosted; this page covers what you do, in order.) 
  AUTHOR TIME (dashboard)                    RUN TIME (your deployed agent)
  ───────────────────────                    ──────────────────────────────
  register → starter policy                  HEXGATE_API_KEY set
        │                                            │
        ▼                                            ▼
  edit /policies                             SDK pulls the signed bundle,
  (roles × tools × args)  ──────────────►    refreshes each turn:
                                             304 = reuse · 200 = new policy

​
1. Mint an API key

On Hexgate Cloud (or your self-hosted instance): sign up, open your project, go to Tokens, mint one, and set it: 
# .env  (HEXGATE_API_URL defaults to https://app.hexgate.ai)
HEXGATE_API_KEY=fty_live_<project>_<biscuit>
The key and URL are coupled — a fty_live_… key only verifies against the platform that minted it.

​
2. Register your agent

Push the agent’s manifest (its tools, model, system prompt) to the platform. On first register, the platform auto-generates a starter role-aware policy from the tool list — a read_only mixin plus default, member, and admin roles, fail-closed (writes and shells gated). See CLI: register. 
hexgate register --agent my_app.agents:my_agent
Or register from code — same manifest, same platform call: 
from hexgate.cli.register import register_agent

register_agent(my_agent)   # pushes the manifest to the platform
register vs serve. You rarely call register yourself — hexgate serve auto-registers the agent on first run.

​
3. Edit the policy

Open the dashboard’s /policies page and shape the generated starter into your real rules: which role may call which tool, with which argument constraints (args.amount <= 500, …). See Dashboard, policy YAML shape, and constraints. Re-registering later never overwrites your edits — it only updates the manifest snapshot.

​
4. Test in the Playground (optional)

Bring the agent up and drive it from the browser to watch decisions stream live: 
hexgate serve my_app.agents:my_agent
Then open /playground, pick a role (“acting as…”), and send a message — allow / deny / approval-required render per tool call. Edit the policy in /policies and the next turn picks it up, no restart. See CLI: serve.

​
5. Deploy with the policy enforced

In production, your agent process just needs HEXGATE_API_KEY set. The SDK resolves the agent’s policy from the platform and enforces it on every tool call — no policy files shipped in your image, no enforce_policy(...) call to remember: 
from hexgate import load_hexgate_agent, stream_agent, User

agent, handler = load_hexgate_agent("my_agent")   # pulls the signed bundle

async with User(user_id=request.user_id, role=request.role):
    async for event in stream_agent(agent, handler, message):
        ...
Existing framework agent instead? Wrap it once with an adapter — same behavior, the runner pulls the policy from the platform. Edits reach production without a redeploy. At the top of every turn the SDK calls the platform with an If-None-Match (the bundle’s wasm_hash): a 304 reuses the cached WASM module, a 200 swaps in the new one. So a policy change in the dashboard lands on the next request your live agent serves — the code, model, and tool list stay fixed for the process lifetime; only the policy refreshes. See policy decision for the refresh seam.

​
The two systems of record

Source of truthChanges via
Code — tools, model, system promptyour Python (the manifest)redeploy / re-register
Policy — roles, tools, arg constraintsthe platformdashboard edit → next turn
That split is the point: operators tune authorization in the dashboard and it takes effect live, while developers own the agent’s code.