Autonomous AI developers, running inside your own infrastructure. Kryex decides — before a command, an edit, or a query ever runs — whether this user, on this project, under this policy, is allowed to do it.
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 run. Every call is authorized against your live grant — anything beyond it is denied with a stated reason, never run silently.
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.
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.
ALTER TABLE. The rm -rf. The prod deploy.Blocked the same way, every time.Every tool call — SQL, shell, infrastructure, deploy — resolves through one policy engine before it runs. Not application logic to trust. Not a wrapper an agent can talk its way around. The same server-side boundary, on every system you connect.
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")Server-side, unbypassable — 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, the proxy runs server-side — there is nothing on the laptop to bypass, 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.
The route to Kryex changes. Whether that route can be talked around does not — except once, and we're not going to pretend otherwise.
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 — regardless of which editor or agent a developer picks.
Reflects each vendor's own public docs and 2026 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.