Tool Calling

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.

Research the web

A dedicated web_research tool searches, fetches, and extracts across multiple pages in parallel — governed through the same connection, grant, and audit path as a database or browser, with its own domain policy and SSRF guard.

Save and reuse skills

Turn a proven approach into a named, reusable skill — global or scoped to one repo — that later sessions can find and load on their own via search, not by re-explaining it every time.

Follow standing project instructions

Reads a project's KRYEX.md / AGENTS.md automatically every turn — nested per-directory, with the closest one taking precedence — and any edit to it goes through the same approval gate as any other file write.

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

The problem

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.

How Kryex solves it

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.

Example

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.

The impact

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.

Background jobs report back on their own

Starting a long-running command — a build, a test suite, a dev server — doesn't mean babysitting it. The job runs detached and survives an app restart; when it finishes or is stopped, the agent is woken automatically, reads the result with a read-only tool set, and reports back inline in the same conversation thread that started it — even if nobody has been watching since.

The sandbox boundary never turns off

Every file and shell action is sandboxed to the active project's root, and that check is independent of the policy engine above it — it still runs in Bypass mode, the setting that otherwise skips approval prompts for a fast, trusted local loop. Bypass mode can turn off asking; it cannot turn off containment. And with no real project attached, the agent has nothing to explore at all — there's no implicit “wherever the terminal happens to be” fallback.

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.