Kryex Code plans, delegates, and remembers — and still can't go around you.
Deploys into your VPC or fully air-gapped. Your models, your logs, your walls.
Describe what you want done — the agent reads, edits, and runs commands in your workspace, with approval on anything risky.
Pick a task to watch it plan, write, and run the fix. Every call is authorized against your live grant — anything beyond it is denied with a stated reason, never run silently.
A live checklist, sign-off before it touches anything — not commentary after the fact.
Subtasks run in isolated subagents, each with its own tracked budget — never pooled into yours.
Project rules, past corrections, approaches it's already ruled out — reloaded automatically, next session.
The decision to reach a database, an MCP tool, or run a command lives only in Kryex Server — never in the agent's own process.
Not a policy layer with a chat window attached to it. Kryex Code plans, delegates, remembers, and runs work on its own — the same execution boundary just applies to every one of these, the same way it applies to a single tool call.
Kryex Server 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 never holds the credential or the decision, by design — it only ever finds out what Server decided. That's what makes the boundary structural, not a setting the agent could be talked past.
In a self-hosted deployment, all three run inside your own infrastructure. Nothing about the architecture requires Kryex Labs' own servers to be reachable at all.
Not mockups — real product chrome, run to the actual end. A database incident, a governed knowledge base — whatever the task looks like, it plans, reads, writes, and checks in with the gate before it acts, every time.
ALTER TABLE. The rm -rf. The prod deploy.Resolved through one policy engine, every time.Every tool call Kryex Code makes — database, MCP, infrastructure, deploy — resolves through one policy engine on the server before it runs. Not application logic to trust, not a wrapper the agent can talk its way around. Shell commands are checked against the same policy engine, against an admin-set, default-deny shell policy.
One governed call, traced end to end— example: a developer with read-only access
Every connected system, resolved the same way — not just this one.
Manifest resolved for this user, before a single token is generated.
Every connected system, resolved the same way — not just this one.
The LLM emits a tool call — it doesn't know what it's allowed to do.
query("DELETE FROM orders WHERE id = 8841")Enforced server-side — the call never reaches the target system directly.
One policy engine for every connector, resolved deterministically, with a reason attached.
Not a dead end — a path forward the developer can act on.
“Read-only access to Orders DB. Request write access?”
Request write accessThe write never executes. Credentials live in the vault and the decision is enforced server-side — no config to edit, no key to steal. The refusal is data the model can explain, not an opaque error.
If the grant included WRITE with the approve-first modifier: the proxy holds the call, a team admin gets it in their approvals inbox, and on approval the proxy executes with vault credentials — the result streams back into the same session. The agent waits. The developer does nothing special.
The auditor replays any session as a timeline — what the agent tried, what was allowed, what was blocked, and which grant decided it.
This isn't a suggestion the model can talk itself out of. The policy gate enforces the boundary server-side, before the command runs — not a warning after the fact, not a setting a prompt can argue past.
Anthropic, OpenAI, Gemini, Mistral, Llama, DeepSeek, Moonshot — through Azure AI Foundry, AWS Bedrock, Google Vertex, or your own vLLM cluster. Swap mid-session without losing context. Kryex doesn't sell you a model. It governs whichever one you choose.
No separate client to trust, no config pointing somewhere else — Kryex already is the client, so every read, write, and execute already runs through the same gate before it happens.
Kryex CodeMost of what the market calls “governance” is a tool asking its own user for approval. The user is still the one deciding. Kryex checks the grant, not the consent — and it holds even when the user says yes.
Alex asks the agent to fix a bad price. It writes the query and asks Alex to confirm.
UPDATE orders SET price = 42 WHERE id = 43;Permission rules + managed policy — distributed through Anthropic's own channel.
Local permission modes — policy config still ties back to OpenAI's settings.
Pre-execution hooks + managed-settings.json — enforced by GitHub's cloud.
Org admin controls, self-hosted workers — orchestration still runs through Cursor's cloud.
Enterprise tier adds access controls and audit trails — scoped to Cline sessions.
Open-source and local — governance is whatever hook or plugin you wire in yourself.
AgentCore Policy evaluates every tool call — for agents built on AWS's own stack.
Agent365 governs the agent estate — Microsoft's control plane, Microsoft's policy language.
Agent governance inside Vertex — Google's cloud, Google's policy plane.
Self-hosted, one policy, built as its own coding agent from the ground up.
Every other gateway governs the model call. Kryex owns the agent that makes it — so the check happens where the action actually happens, not one layer removed from it.
Reviewed October 2026, based on vendors' public docs. Reflects each vendor's own public docs and product announcements as of this writing, not aspirational roadmaps on either side. Governance is improving everywhere — the gap is that it stops at each vendor's own boundary.