The Brain and the Hands.
Kryex's architecture is organized around one distinction: the brain is the model call, the hands are the execution. Everyone governs the brain, in the cloud. Almost nobody governs the hands, self-hosted. Kryex governs both — and it governs the hands where they actually run: inside your own infrastructure.
Why governing the model call isn't enough
Every serious model gateway on the market today — the hyperscaler-run ones included — inspects, rewrites, refuses, or logs a model interaction: the prompt going out, the completion coming back. That's real, useful governance, and Kryex does it too (see Model Gateway). But it's categorically all happening in somebody else's cloud, applied to a stream of text. Governing the hands means physically stopping the action an agent is about to take — before it executes, not after the fact in a log review — and that requires owning the agent's actual execution loop, running where the execution happens. That's a fundamentally harder engineering problem, and it's the one Kryex was built to solve first.
Two chokepoints, not one
A model call — the brain — goes through the Model Gateway: every prompt and completion is policy-checked, quota-checked, and logged before it ever reaches an upstream provider. A tool call — a SQL query, a browser action, a shell command, the hands — goes through the Tool Proxy / Policy Decision Point, which asks before anything executes: is this exact user, in this exact scope, allowed to perform this exact class of action against this exact resource, right now? If the answer is no, the action never runs.
Three components, one system
Kryex Cloud is the fulcrum — the only component with a database, the only one that makes an authorization decision, the only one that writes the audit log. Desktop and Admin are both thin by design: neither enforces anything on its own, they only ask Cloud and render what it decides.
Kryex DesktopThe client
Where developers work. A native, autonomous coding agent — today a Visual Studio extension in production use, migrating to a standalone Electron app ("Kryex Code") with an integrated terminal and browser pane.
Kryex CloudThe fulcrum
The backend and policy decision point. Owns identity-to-license exchange, the Model Gateway, the connection registry, the grants engine, and the hash-chained audit log. The only stateful, authoritative piece.
Kryex AdminThe control plane
The governance console. An administrator defines the org structure, decides who can do what to which system, reviews access requests, and reads the audit trail here — but never enforces anything directly.
What actually gets checked, on every call
- Model calls — caller authenticated, account status re-checked live (not from a cached license claim), model access resolved, quota enforced, then proxied and logged.
- SQL calls — the actual statement is parsed and classified (comment-and-string-aware), not declared by the developer. An unrecognized statement type is treated as the highest-privilege class, never assumed safe.
- Browser actions — classified read or write exactly like SQL, plus an independent domain policy (blocked, allowlisted, or open) checked on every navigation.
An administrator's change should reach a live session before the developer's next login
In most tools, a permission change made in an admin panel only takes effect the next time the affected user's client re-authenticates — which could be hours away, or whenever their current session happens to end. A revoked grant that hasn't taken effect yet isn't really revoked.
Every mutation an administrator makes in the Admin panel does three things atomically: it writes the change, it writes an audit event recording exactly what changed and by whom, and it bumps the affected users' session state — so a live agent session picks the change up on its very next turn.
An administrator revokes a developer's write access to a production database mid-afternoon, while that developer has an active agent session open. The very next tool call that agent attempts against that database is evaluated against the new, revoked grant — not the one that was true when the session started.
A policy change is enforced the moment it's made, not the moment a session happens to restart.
In a self-hosted deployment, all three components — desktop clients, the admin console, and the Cloud backend with its database — run inside your own infrastructure. Nothing about the architecture requires Kryex Labs' own servers to be reachable at all.