The same agent, in your network

The hosted service answers from a description you write. Some questions cannot be answered that way, because the answer is in a live system — how many orders shipped late last week, is this customer's account overdue. There are two ways to close that gap, and they sit at different points on the trust spectrum.

Enterprise plan, hosted. The agent calls an MCP server you run. You expose whatever tools make sense — a query endpoint, an inventory check, a CRM lookup — and the agent calls them at question time from our cloud. Your source data stays in your network; only the response to each tool call crosses the boundary. This is the right choice when you are comfortable with that data leaving and want no kavilo infrastructure to operate.

Self-hosted. For those who cannot send that data anywhere, the same agent runs inside your network, next to the data, serving your intranet. There is less to it than you would expect: it hosts the database bridge in-process, so there is no second service to deploy and no port to open.

Nothing is exposed

Your internal site and the agent are both inside your network, so there is no tunnel, no public hostname and no inbound firewall rule. This is the deployment where "no inbound" is not a mitigation — there is nothing listening from outside.

Read-only by construction

The bridge accepts one read-only SELECT, including a WITH … SELECT, and adds a row limit when one is missing. That is enforced in the query path rather than requested politely of the model — and it should still sit behind a database role that cannot write, because a grant is a control and a check is a second line.

What leaves, stated plainly

• With a remote model provider — ours, OpenAI, Anthropic or another configured provider — that provider sees the conversation, your schema, the queries the agent writes and the rows those queries return.
• With local inference, on your own hardware, nothing leaves at all. Not the schema, not the rows.

Those are genuinely different postures. If your requirement is that no row may cross the boundary, run local inference — the same configuration works and you change one provider setting. Do not let anyone tell you the hosted option is equivalent, us included.

What the binary contains

Not our storefront. The build you run has no payment processing, no signup flow and no price list compiled into it — those exist only in the build that runs this website. It is a deliberate line: an agent runtime inside your network should not contain a Stripe client, and "why does it" is a fair question to ask any vendor.

Where this sits

The two self-hosted rows use the same kavilo deployment. Moving from a remote model to local inference is a provider configuration change, not a data migration.

Getting started

This is not self-serve — it wants a conversation about your data and your network first. Talk to us.