Three ways in. One gate.
Kryex meets an enterprise where its current tooling already is. There are three modes, in increasing order of enforcement strength and decreasing order of migration effort — most teams land in Gateway first, then expand into Native as trust deepens.
The three modes, live
Switch the pill above the diagram to trace the exact path a call takes in each mode — the dashed amber arc that appears in MCP mode is the actual claim, drawn rather than just asserted: a real second path around the gate.
Kryex CodeKryex is the agent
- For
- Teams adopting Kryex as their coding agent, not bolting it onto an existing one.
- Setup
- Nothing to configure — Kryex already is the client.
- Enforcement
- Structural. Every read, write, and execute passes through Kryex's own Tool Proxy → PDP before it runs.
Which mode should you start with?
Gateway is the fastest path to proving value — zero workflow change for developers, every prompt governed from day one. Native is where the differentiated technology lives: execution-boundary enforcement, the full brain-and-hands story in one deployment. MCP is a compatibility bridge for agents that can't point at a custom endpoint at all (Claude Code, Codex) — useful, but it's the one mode where the agent itself decides whether to call the check, not a structural wall.
MCP mode is agent-mediated, not structural. A user who insists can talk the agent into skipping the check. This is stated plainly rather than glossed over — see the dashed bypass path in the diagram above when MCP is selected.
An honest gap, drawn on the diagram instead of buried in a footnote
Most vendors describing a weaker enforcement mode either don't mention the gap at all, or bury it in fine print far from the diagram that's supposed to explain the architecture — leaving a customer to discover the limitation the hard way, in production.
MCP mode's gap isn't a caveat added after the fact — it's drawn directly into the live diagram above as a real, dashed, amber arc looping around the gate: a literal second path a call can take that skips the Tool Proxy, visible the moment MCP is selected.
Switch the pill above to MCP and the bypass arc appears immediately, labeled 'agent can choose to skip this' — the same diagram that shows Native and Gateway as fully enforced shows MCP's real limitation without needing separate text to explain it.
The trade-off is something a customer can see and decide about before they deploy, not something they discover after.
All three, in detail
NativeStrongest enforcement
The customer runs Kryex's own agent and runtime, self-hosted. Policy is enforced at the moment of action — a junior developer's agent attempting an ALTER TABLE against production is blocked before it runs, not flagged afterward. This is where Kryex's differentiated technology, execution-boundary enforcement, actually lives.
GatewayFrictionless adoption
The customer keeps whatever agent they already use — Cursor, Cline, OpenCode — and points its model configuration at a self-hosted Kryex gateway instead of a raw provider endpoint. Every prompt is now governed with zero workflow change for the developer. Governs the brain only.
MCPCompatibility bridge
Enterprise tools are exposed to any agent — not just Kryex's own — through a governed Model Context Protocol layer. Built for organizations with heterogeneous agent tooling already in place. Not the core enforcement story: the agent decides whether to call it.
The typical adoption path
Most enterprises land in Gateway first — it's the fastest way to prove Kryex governs model traffic correctly with no workflow disruption. As trust deepens and the team is ready for full execution-boundary enforcement, they expand into Native. MCP stays a compatibility bridge for whichever agents can't be pointed at a custom endpoint at all, used alongside the other two rather than as a replacement for them. See Tool Calling & Governed Actions for what happens after a call passes through whichever gate is in front of it.