Your first governed session.
Five real steps, in the order they actually happen — from picking how Kryex sits in your stack to watching a blocked call show up in the audit log.
What Kryex actually is
Kryex is a self-hosted execution and governance platform for autonomous AI software engineering. It lets an agent actually execute — run commands, edit files, query databases, open pull requests — without your source code, your data, or your infrastructure credentials ever leaving your own walls. Most “AI governance” products on the market today govern the model call: the prompt going out, the completion coming back — real, useful work, but only half the problem. The moment an agent stops suggesting and starts executing, the real risk moves to the action itself: an ALTER TABLE, an rm -rf, a production deploy. Almost nobody governs that, self-hosted, before the action runs. Kryex does — see How Kryex Works for the full brain/hands breakdown.
Three pieces, one system
Every deployment runs the same three components, working together.
The five steps
Pick a deployment mode
Native if you're adopting Kryex as the coding agent itself — full execution-boundary enforcement, the strongest mode. Gateway if you want to keep your current editor and just govern the model traffic. MCP if your agent can't point at a custom endpoint at all. See the full deployment modes guide for the exact mechanics and the honest trade-off of each.
Connect a model — BYOM, no lock-in
Kryex doesn't sell a model; it governs whichever one you already pay for. Add a provider key (or nothing at all, for a fully local model) and the gateway handles wire-format translation transparently from there.
Register a connection
Every external system an agent might touch — a database, a browser, a governed tool — is explicitly registered by an administrator, never discovered implicitly. Database connections are live-tested before they're ever saved, so a broken connection never sits in the registry surfacing as confusing failures later. If a registered system's tools change shape unexpectedly — a schema drift, an upstream definition changing — the changed tool is automatically quarantined to zero capability for everyone until an administrator re-approves it.
Create your first grant
A grant is the atomic unit of policy: a principal, a resource, a capability level, and an optional scope. Default is deny — no grant on file means no access, full stop. See Grants & Identity for the full capability ladder and resolution rules.
Watch it get enforced
Every tool call — SQL, shell, browser, infrastructure — resolves through the same policy engine before it runs, and writes exactly one event to the append-only, hash-chained audit log. The canonical example: a junior developer with read-only access asks the agent to fix a bad price; the agent writes the UPDATE, and it's blocked before it runs — not because the agent was told to behave, but because there's no grant on file that permits the write. See Tool Calling & Governed Actions for exactly how a call gets classified and intercepted, or the live walkthrough on the home page.
A broken connection shouldn't surface as a confusing failure three steps later
In most tools, a misconfigured database connection or a stale credential doesn't fail until an agent actually tries to use it mid-task — by which point the failure looks like a bug in the agent, not what it actually is: bad registry data nobody caught.
Database connections are live-tested at the moment they're registered, before they're ever saved — and if a registered system's tools change shape unexpectedly after that (a schema drift, an upstream definition changing), the changed tool is automatically quarantined to zero capability for everyone until an administrator re-approves it.
An administrator registers a Postgres connection with a typo'd password. Kryex catches it immediately at registration, not three weeks later when a developer's agent mysteriously can't query orders_db mid-task.
Registry problems get caught by the person best equipped to fix them (the administrator, at setup time) instead of surfacing as a mystery to whichever developer hits it first.
Where to go next
Tool Calling & Governed Actions
How a SQL query, a shell command, or a browser action actually gets classified and intercepted.
Bring Your Own Model
Every supported provider, credential handling, and how local inference works.
Model Gateway
What happens to every single model call before it reaches a provider.
Context Intelligence
Auto-compression, editable working memory, and swapping models mid-session.
Enterprise identity (SSO/SAML/OIDC, SCIM sync) is roadmap, not shipped yet — see the status badges on the Grants & Identity guide. Local users and groups work today; federated identity is next.