Self-hosted and air-gap-capableby construction.
Not a policy promise — an architectural one. Every component that touches your code, your data, or your credentials is designed to run entirely inside your own network, with no dependency on Kryex Labs' own infrastructure ever being reachable at all.
Credentials never reach the client
A database password, an upstream model API key — masked to its last few characters even to an administrator, used only inside the one backend process that executes the call.
sk_live_••••••••••••7f21Every check is live, not cached
Suspension, quota, and grant state are re-verified on the actual request — never trusted from a claim baked into a license token issued up to 24 hours earlier.
Default deny, everywhere
No configuration state in Kryex ever defaults to permissive. The absence of a grant is a denial, full stop — never an oversight to be caught later.
Fail closed on ambiguity
An unrecognized SQL statement, an unrecognized browser action, an unparseable URL — every classifier treats what it doesn't understand as the highest-risk category, never the lowest.
The desktop app never enforces policy on itself.
Kryex Code renders what the server already decided — it never makes that decision on its own. Every governed tool call round-trips to Kryex Server and is authorized there, against your real, current grants, every single time. Editing the local cache, running in the app's most permissive mode, or calling the API directly with curl doesn't change what the server will allow.
Kryex Code
Reads files, runs commands, proposes actions — entirely on your machine.
Kryex Server
The single, authoritative decision-maker for every governed action.
No grant on file means no access. Full stop.
Every connection an agent can touch — a database, a browser session, web research — is governed by an explicit grant, never implicit trust. Every permission resolves to one position on one ladder, in strict order, and destructive SQL — DELETE, DROP, ALTER, TRUNCATE — is classified as admin, not write, on purpose.
Separately, the desktop app has its own local permission mode — purely a UX convenience for how much confirmation you want before the agent acts. It never affects what the server-side grant allows; the governed-access column below is asked every time in every mode, because that check cannot be turned off locally. An admin can also lock which mode a user is allowed to run in, and block specific destructive shell commands outright regardless of mode — including in bypass, where auto-approval below is subject to that admin policy, not a way around it.
Shell and destructive-command policy is set by your admin, pushed from the server, signed, and stored at the OS level — default-deny unless explicitly allowed. It applies to Kryex Code's own terminal, not the user's machine as a whole: it governs what the agent can run inside the app, not what the user can run themselves outside it.
Grant changes reach a live session on its very next tool call — there's no persistent connection, so the desktop app polls a manifest on a short cache window, but every actual call is re-authorized server-side at call time regardless of what that cache currently believes. A stale cache can only delay how quickly a revoked capability disappears from the UI, never grant access the server wouldn't currently allow. New or changed tools on an existing connection start at zero access until an admin explicitly re-approves them.
Every decision writes one event. The chain proves none were edited.
Append-only, hash-chained — each event's hash incorporates the one before it, the same tamper-evidence construction built to survive an audit challenge of “how do we know this log wasn't altered after the fact?” There is no code path in Kryex that updates or deletes an audit row. One real session, four linked events:
Dev B reads the orders database.
2026-08-05 09:12:03 UTCAllowed — grant G-118 gives Dev B READ on orders_db.
Dev B's agent tries to write to the same database.
2026-08-05 09:14:41 UTCBlocked before it ran — there is no grant on file that permits a write.
Dev B requests write access, with a reason.
2026-08-05 09:15:02 UTC“Hotfix — bad price on order 43.” Lands directly in the admin's approvals inbox.
An admin grants WRITE, scoped to Dev B's own team.
2026-08-05 09:22:18 UTCThe grant is bounded — team/payments only, not the whole database.
A suspended account is blocked on the next call. Not eventually — now.
A license proves it was valid when issued. It says nothing about whether the account has been suspended since. So Kryex never trusts the license alone — suspension, quota, and grant state are re-verified on the actual request, every time. This live check is how the hosted individual tier works today; in an air-gapped deployment there is no outside call to make, so the license is instead signed and validated entirely by your own Kryex Server — see below.
In air-gapped deployments the license is signed and validated by your own Kryex Server, with no call out to Kryex Labs required. Tampering is detected and alerts your org admins.
The boundary holds even in the app's most permissive mode.
When a conversation isn't pointed at a repository you opened, its file operations are confined to a private, per-conversation sandbox — not a shared scratch space other conversations can see into. A separate check gates any attempt to touch a path outside the intended root, and it runs regardless of permission mode.
This wasn't theoretical: this check used to be disabled specifically in the app's most permissive mode, and a real incident showed why that was wrong — an agent searched the entire local drive with no approval prompt ever firing. That gap is closed; a dedicated, off-by-default toggle is now the only way to disable this check at all.
Every connection to Kryex Server is encrypted, and can't be silently redirected.
All communication with Kryex Server goes over HTTPS. The Gateway URL a desktop app is configured to use explicitly refuses a plaintext http:// target for any non-loopback host, and an organization can centrally lock that URL via policy so an end user can't silently point their own app at a different server.
Electron hardening
Context isolation on, Node integration off, sandboxing on. The preload script exposes only a small, audited set of IPC calls — not a general bridge to Node or OS APIs.
The browser pane is isolated
Pages the agent views run inside their own separate, isolated renderer process from the main app UI — never sharing a process with your conversation or your files.
Domain policy is enforced server-side
Before navigating anywhere on your behalf, the app asks the server whether that domain is currently allowed — so a modified client can't simply skip the check.
A signal for a human to review — never an automatic lockout.
A set of heuristic checks run over the audit log and device table, evaluated when an org admin opens the Security page. A false positive here should read as “worth a look,” not “your access was just cut off” — and if one heuristic fails to evaluate, it reports its own error rather than silently suppressing the rest.
Multiple devices, one account
Several devices active on the same account within a short window.
IP changing too fast
The same device's IP address shifting in a way that isn't physically plausible.
A revoked device, trying anyway
A device that was explicitly revoked attempting to re-authenticate — the one zero-ambiguity signal, always flagged at the highest severity.
A burst of policy denials
An unusually high rate of blocked calls in a short window.
Not yet built: geographic-velocity (“impossible travel”) detection, analysis of prompt or message content for abuse signals, and correlation of anomalies across different organizations. This runs on demand today, not as a continuous background job.
Federated identity, not a second directory to manage.
Once live, authentication for Kryex Desktop and Kryex Admin flows entirely through your own identity provider — Kryex never becomes a separately-managed identity source inside your organization. The grants engine already treats groups as first-class principals today, built from day one to become live mirrors of your real directory groups.
Have a security questionnaire?
Send it over — we'll fill it out against the architecture, not a template.
Request a security review