Every action is a governed call.
The agent doesn't decide what it's allowed to do — it proposes an action, and the Tool Proxy classifies and authorizes it before anything actually executes. This is what the model call being 'allowed' has nothing to do with whether the resulting action is allowed.
What the agent can actually do
The agent's tool loop covers full autonomous engineering work, not a narrow code-suggestion surface — every one of these passes through the same governance boundary described below.
Read and write code
Read files, list directories, search code, produce and apply precise diffs, write new files — sandboxed to the selected workspace root.
Run commands
Including long-running background processes (dev servers, watch builds), with live output streaming, port detection, and process management.
Manage its own task list
Inline in the conversation, so multi-step work stays visible and resumable.
Ask clarifying questions
Mid-task, when a decision genuinely needs the developer's input, rather than guessing.
Drive a browser
Navigate, click, type, read the page, inspect console and network activity — governed exactly like a database call.
Query governed databases
Subject to the same live authorization check on every single call.
Manage the full PR lifecycle
Stage and commit, create branches, generate PR descriptions, search and assign reviewers, and push — integrated with Git, and for enterprise customers, Azure DevOps and Jira.
SQL is classified, not declared
Kryex doesn't ask a developer to declare whether a query is a read or a write — it parses and classifies the actual SQL on every single call, comment-and-string-aware so a comment or a string literal containing the word “delete” can't fool the classifier. The classification is deliberately conservative: any statement type the classifier doesn't recognize is treated as the highest-privilege class (admin), never assumed safe. A multi-statement call is classified by its single most privileged statement — one governed call can never smuggle a destructive statement in behind an innocuous one.
Approving an action and being authorized to take it are two different things
In most agentic tools, the only check before a risky action runs is the user's own confirmation click — but a user clicking 'approve' is not the same thing as that user actually being allowed to do it. A junior developer with read-only access can still click 'yes' on a write.
Kryex checks the classified action against the user's actual grant, not their consent. A developer with READ-only capability on a connection can approve a write all they want — the Tool Proxy still blocks it, because the grant, not the approval, is what's authoritative.
A developer with read-only access on orders_db asks the agent to fix a bad price. The agent writes the UPDATE and asks for confirmation. The developer approves it. Kryex still blocks the write, because the developer's grant caps out at READ — the approval never entered into the decision.
Server-side authorization can never be talked around by convincing the person in front of the keyboard — including by that person convincing themselves.
The browser is governed the same way
An agent's browser actions — navigate, click, type, read the page, inspect the console — are classified read or write exactly like SQL, and a browser connection additionally carries a domain policy (blocked entirely, an explicit allowlist, or fully open) checked independently of capability on every navigation. An administrator can grant a team write capability on the browser tool generally while still restricting exactly which domains that browser can reach.
Drift quarantine
If the tools a registered connection exposes change unexpectedly — a schema drift, an upstream tool definition changing shape — the changed or new tool is automatically quarantined: it resolves to zero capability for everyone until an administrator explicitly re-approves it. A connection approved yesterday can't silently start exposing new capability today without a human looking at it first.
Inline approvals
When an action needs a human decision — because the policy engine says so, not because the agent decided to ask — the approval happens inline in the conversation stream, never as a disruptive modal: “Allow once,” “Allow for this session,” or “Deny,” with the session remembering what was already granted. See the full approvals mechanics for what happens server-side when that decision is made.
Every one of these checks — SQL classification, browser domain policy, drift quarantine — runs inside the Tool Proxy / Policy Decision Point described in How Kryex Works, entirely inside your own infrastructure in a self-hosted deployment.