For the CTO
Governance your platform team can actually run.
Your teams are shipping agents faster than any central function can review them, and the governance layer you adopt becomes something platform engineering owns at three in the morning. That makes operational behavior the deciding factor, not the feature list.
One codebase, three deployment models.
Hosted by us, in your own cloud account, or entirely on-premises on Kubernetes. Not three products with different capabilities — the same one, deployed differently.
SaaS
We run the governance plane. The decision point still runs in your environment, so the traffic story is unchanged.
Your cloud
The governance plane runs in your own account, under your own controls, with your own key management.
On-premises
Everything in your Kubernetes estate, including air-gapped environments where nothing calls out at all.
Choosing self-hosted does not put you on a lesser build. It is the same codebase, which is also why the on-premises path does not lag behind.
Two namespaces, and a deliberate boundary.
| Namespace | Contains | Why it is separate |
|---|---|---|
| Governance | The data plane and its database — catalog, policy model, decision record. | Governance state is isolated from the workload it governs. A problem in one does not reach the other. |
| Workload | Your MCP servers and the decision point in front of them. | Can be handed to a team with scoped access, so they run their own servers without seeing governance internals. |
Each tenant gets its own pair. Scaling is per tenant rather than a shared tier everyone contends for.
Your environment initiates every connection.
Policy is pulled outbound. Decision records are pushed outbound. There is no inbound path into your environment, which is what makes the on-premises story straightforward rather than a negotiation with your network team.
No firewall exceptions
Nothing needs to reach into your estate. There is no listener to expose and no allowlist to maintain for us.
Nothing in the hot path
Decision records are sent asynchronously in batches. A slow or unavailable endpoint on our side does not add latency to your agents' calls.
What happens when something goes wrong.
The useful question about any new dependency is what it does on its worst day.
| Situation | What happens |
|---|---|
| FaburAI is unreachable | Enforcement continues on the last known good policy, because decisions are evaluated locally. Records queue and deliver when connectivity returns. |
| A policy is wrong | Set the affected server back to observe or simulate. Nothing is blocked while you correct the rule, and the rule cannot re-enforce until it is approved again. |
| A server stops responding | Servers are probed on an interval, so an unreachable server shows as a health signal rather than as an absence of traffic. |
| A server changes underneath you | What each server exposes is fingerprinted, so a new or removed capability is a detectable change rather than a silent one. |
Because decisions are evaluated locally, we are not a runtime dependency of your agents. That property is what makes this safe to put in front of production traffic.
Adoption that cannot break a running agent.
Enforcement mode is a property of each server, so the estate can be onboarded gradually and a mistake is contained to one system.
Observe
Every call evaluated and recorded, nothing blocked. Learn what your agents actually do.
Simulate
The platform records what it would have denied while letting traffic through. Impact becomes a number.
Enforce
Denials take effect, with the reason attached. Turned on one server at a time.
Policy changes reach the decision point on a short interval and swap in place — no restart, no dropped connections, no maintenance window.
A denial your engineers can debug.
A governance layer that refuses calls without saying why becomes a support burden on your platform team.
Refusals name the rule
A denied call comes back identifying the rule that refused it, so a developer gets an answer instead of filing a ticket.
Agents are unmodified
Applications keep calling their tools as they always have. Adoption is a deployment change, not a rewrite of every agent.
Go through the operational detail with us.
Failure modes, tenancy, upgrade path, air-gapped operation — these are the useful things to cover, and they are better covered early than late.