Deployment & security
Run it where your data already lives.
Where the governance plane runs is a choice you make for your own reasons. What does not change with that choice is the part that matters: enforcement happens inside your environment, and your data never passes through ours.
Three ways to run it. One codebase.
Not three products with different capabilities — the same one, deployed differently. Choosing self-hosted does not put you on a lesser build or a slower release.
FaburAI SaaS
We run the governance plane. The decision point still runs in your environment, so governed traffic and your data behave exactly as they do in the other two models.
Fastest to start. Suits teams without a mandate to self-host the control surface.
Your cloud account
The governance plane runs in infrastructure you own, under your own controls, your own key management and your own monitoring.
Suits data-residency requirements and organizations that self-host by policy.
On-premises
Everything inside your own Kubernetes estate, including environments with no outbound connectivity at all.
Suits regulated and air-gapped environments where nothing may call out.
In all three, the decision point runs in your environment. Where the governance plane lives changes who operates it — it does not change what happens to your traffic.
The answers a review will ask for.
| Question | Answer |
|---|---|
| Connection direction | Outbound only, always initiated by your environment. Policy is retrieved; decision records are sent. Nothing connects inbound to you. |
| Governed traffic | Never leaves your network to reach us. The agent, the decision point and the tool are all inside your environment. |
| Payloads | Request and response bodies are never captured or transmitted. We govern access to your data and never handle it. |
| What we receive | Payload-free decision records — which actor, which role, which tool, which target, the outcome, the matching rule, the time — sent asynchronously in batches. |
| Credentials | Connection credentials for the systems behind a governed server are encrypted at rest rather than held in plain configuration. |
| Sign-in | Single sign-on through your existing identity provider. Roles federate in; we never become the source of truth for who someone is. |
A boundary, not a filter.
Every tenant gets its own governance data plane and its own database, in its own namespace, with a second namespace for the workload being governed.
Separation is structural
Tenants are separated by deployment boundary rather than by a condition in a query. There is no shared table where a missing filter becomes a cross-tenant incident.
Governance is separated from workload
The catalog, policy model and decision record live apart from the servers being governed, so the workload namespace can be delegated to a team without exposing governance internals.
Scale is per tenant
Each tenant's governance plane scales to that tenant's load. There is no shared tier that everyone contends for.
Blast radius is contained
A problem inside one tenant's governance plane does not reach another tenant, and does not reach the workload it governs.
Environments that never call out.
Because every connection is outbound and initiated by your side, an environment that makes no outbound connections at all is a supported deployment rather than an exception to work around.
Nothing to reach in
There is no inbound path to sever, because there was never one to begin with. What changes in an air-gapped deployment is that decision records stay local.
The governance plane is local too
In an on-premises deployment the control plane runs inside your estate, so authoring a policy, approving it and holding the record all happen without leaving your network.
What happens when we are not there.
Enforcement continues on the last known good policy, because decisions are evaluated locally. Losing us neither opens your governed tools nor stops your agents — records queue and deliver when connectivity returns.
This is the property that makes the deployment question less consequential than it first looks. We are not a runtime dependency of your agents in any of the three models.
Send us your security questionnaire.
We would rather work through it early than late, and we are glad to go into more detail than a web page can carry.