Search the open web, governed the same way as everything else.
A dedicated web_research tool searches, fetches, and extracts across multiple pages in parallel and hands the model a set of cited sources — the actual search → fetch → extract → synthesize loop real research runs on, not a human clicking through results one tab at a time. It is governed through the identical connection, grant, and audit architecture as a database or the browser tool — a second instantiation of one system, not a parallel one built just for this.
A different tool from the Browser pane, on purpose
The Browser pane drives one visible tab, built for local dev work — open the dev server, click through a flow, read a console error — on the assumption a person is watching it. Web research is headless: it fetches many pages in parallel and nobody is watching any of them render. Kryex keeps these as two distinct tools rather than one that tries to do both, so neither one inherits an assumption that only holds for the other.
Governed like any other connection, not a special case
Web research is available to every user the moment an administrator registers it as a connection — the same Connections page, the same grant table, the same capability ladder as a Postgres database or the Browser tool. Because the tool is read-only by nature, its capability labels collapse to what's actually meaningful:
NO ACCESS
Explicit deny. Beats every other grant, same semantics as any other connection.
OBSERVE
The agent can search and read results — this is the level almost every grant here actually is.
FULL CONTROL — reserved
There is no write/act-on-the-page capability for this tool, so Kryex doesn't invent one — this tier stays reserved rather than fabricating a distinction that isn't real.
Domain policy is the identical mechanism the Browser tool already uses — blocked entirely, an explicit allowlist, or fully open — checked on every fetched URL, not once per turn. See how the browser is governed for the shared domain-policy mechanics.
Three ways to source search results
Built-in (DuckDuckGo / Google / Bing)
Zero setup, zero signup, zero cost — one library queries any combination of the three, results merged and deduped by URL. The default for most orgs.
Self-hosted SearXNG
Point the connection at an org's own SearXNG instance instead. Nothing leaves infrastructure the org already controls, and it scales the way any self-hosted service does.
Custom endpoint
A regulated customer who won't allow public search-engine scraping points Kryex at their own approved search proxy. Swapping backends is a config value on the connection — never a deploy, never a code change.
A regulated customer who can't allow public search scraping shouldn't need a special build
Most agent research tools hardcode one search provider. A customer whose compliance posture rules out querying public search engines directly is stuck either accepting the risk or waiting on a custom integration.
The search step sits behind one small interface, configured per-connection alongside the domain policy. Swapping DuckDuckGo/Google/Bing for a self-hosted SearXNG instance, or a fully custom internal endpoint, is a configuration value on the connection — the rest of the governance (grants, domain policy, audit) doesn't change.
A regulated bank configures its Web Research connection to point at an internal SearXNG instance already approved by its security team, instead of the built-in DuckDuckGo/Google/Bing option. No code change, no separate build, no waiting on a Kryex release.
The governance model and the search source are decoupled — an org's compliance posture decides where results come from, without changing how they're authorized, logged, or audited.
Network safety, independent of domain policy
Every outbound fetch — the search call and each page fetch — passes a resolved-IP check, not a hostname string match, so a DNS rebind to a private address is still caught: loopback, private and link-local ranges, and the cloud metadata address are blocked outright, regardless of what the domain policy allows. Page fetches also respect robots.txt, and a per-page size cap, a per-page time cap, and a hard cap on total pages fetched in one turn bound both cost and the blast radius of a bad query. This SSRF guard runs independently of an org's own network egress controls — Kryex enforces its own boundary regardless of what a customer's VPN or proxy already blocks upstream, rather than assuming that infrastructure as a substitute.
A policy change mid-call only affects what hasn't happened yet
One multi-page call shouldn't run entirely under whatever policy existed when it started
Web research fetches several pages per call. If policy changes between page 2 and page 3 of the same call, a naive implementation would either apply the old policy to every page (a stale decision) or abort the whole call (unnecessarily destructive to work already done).
Every single URL is checked fresh, immediately before it's fetched — never once for the whole multi-page call up front. A policy change bounds its effect to exactly the fetches that happen after it, never retroactively invalidating pages already fetched.
An administrator tightens a connection's domain policy midway through a research call already fetching five pages. Pages 1 and 2, fetched before the change, complete normally. Page 3 onward is evaluated against the new, tighter policy and blocked if it no longer qualifies.
A policy change takes effect at the next fetch, not the next session — the same real-time enforcement guarantee every other governed action on Kryex carries.
Fetched content is data, never instructions
Every piece of text a fetch returns — a full extracted page, or just a search-result snippet — is treated as untrusted data, enforced structurally rather than left to a system-prompt convention. Two layers, not one: the content is labeled as data distinct from instructions the same way every other tool result already is, and text resembling an injection pattern (“ignore previous instructions,” a fake system-role marker embedded in page text) is stripped before it ever reaches the model. Both layers apply to search snippets too, not just full page text — a malicious page can rank itself with an adversarial snippet before it's ever fetched in full.
One audit event per URL touched
A search call and each individual page fetch each write their own audit event — decision, reason, the exact query or URL, and which search backend served it — into the same hash-chained log every other governed action writes to. A compliance reviewer can answer “what did the agent search for, and which of those pages did it actually read” from the log alone.
Stated honestly: every free search backend — DuckDuckGo, Google, or Bing queried without a paid API — carries a real, ordinary rate limit per source IP. That's true of every provider in the industry, not a Kryex gap; there is no free, unlimited, zero-signup web search API anywhere. Kryex mitigates it with automatic retry, multi-engine querying (so one engine being throttled doesn't stall research), and the option to point at a self-hosted or paid custom backend for guaranteed capacity.