Skip to main content
Hexgate is runtime authorization for AI agents. On every tool call, it decides whether this end user, acting in this role, may run this tool with these arguments — and returns allow, deny, or approval_required. Drop it in front of an OpenAI Agents / LangChain / Google ADK / Pydantic AI agent without rewriting the agent. The decision has three inputs and one output:

Same request, different answer

Authorization isn’t a property of the agent — it’s a property of who is calling and what they’re trying to do. A support agent and a billing agent can share the exact same code and the exact same refund_order tool, yet get different answers, because a policy maps roles → tools → argument limits:
The same refund_order($400) call resolves differently per caller: The caps live in the policy, outside the model — so a prompt-injected or confused agent can’t talk its way past amount <= 500. It never even sees the tool result for a denied call; it gets a [policy_denied] marker it can recover from.

See it enforce (no keys)

Install, then watch a role + arguments decide a tool call in one command.

Author a policy

Roles, tools, modes, and argument constraints — the full policy shape.

Request context + roles

How the end user’s identity + role reach the decision at call time.

Framework adapters

OpenAI Agents, LangChain/LangGraph, Google ADK, Pydantic AI — wrap once.

What Hexgate is

Hexgate is two things that move together:
  • hexgate — the SDK. A Python runtime that intercepts every tool call and runs it through a PolicyEnforcer, resolving the caller’s role at call time and returning a typed Decision. It wraps your existing agent without rewriting it.
  • The Hexgate platform (optional) — a control plane + dashboard for editing policy in a browser, minting per-project tokens, watching live decisions stream from a serving agent, and shipping signed policy bundles to production. Available as Hexgate Cloud (hosted — set one env var) or self-hosted.
Two things feed the decision, and one thing records it:
  • The end user’s identity and role are a decision input — carried per-request via HexgateContext, they select which role’s rules apply. (They also tag traces, but that’s secondary.)
  • The policy supplies the rules — a YAML file or signed WASM bundle, loaded locally or from the platform.
  • Every decision is written to an audit trail: who called what, and whether it was allowed.

The decision path

New here? Install and see a policy decide a tool call in 60 seconds — no API keys — then pick a path between the local chat REPL and the platform-backed serve loop.