The platform
Enforcement runs in your environment. Never in ours.
Governance products commonly enforce by sitting in the traffic between your agents and your tools. FaburAI is built the other way around: we produce policy, and your own environment enforces it.
FaburAI is never in the request path.
That is a specific architectural statement, so it is worth setting out precisely what it means.
FaburAI compiles your governance rules into policy and publishes it. A decision point inside your own environment retrieves that policy and evaluates every call locally. The governed request goes from your agent, through the decision point, to your tool — entirely inside your network.
Unchanged. It calls the tool as it always has, carrying the identity of the user it is acting for.
Evaluates the call against current policy, in place. Allow or deny, with the reason recorded.
Receives the call only when the decision is allow. A denial never reaches it at all.
Publishes the policy the decision point retrieves, and receives payload-free decision records. Never a hop in the call itself.
A denied call never reaches the tool, and the denial comes back naming the rule that refused it — so a developer debugging their agent gets an answer rather than a mystery.
What leaves your network, exactly.
A short answer, set out in full, because it is usually the first thing a security architect wants to establish.
Leaves your environment
- Decision records: which agent, which tool, which target, allow or deny, which policy matched, and when.
- Health and version of the enforcement component, so you can see your own fleet.
Sent asynchronously in small batches. The request path never waits on FaburAI.
Never leaves your environment
- Request payloads — the arguments your agent sent.
- Response payloads — the rows, files, or records returned.
- Your data, in any form. FaburAI governs access to it and never handles it.
When a call is allowed, data flows directly between your agent and your tool.
Policy changes reach the edge without a restart.
Author
Describe the policy in plain language. FaburAI drafts the structured rule — the roles, tools and columns it binds to — for you to review and correct.
Approve
Policies move through draft, review, approved, published. Nothing that has not been approved can reach enforcement, so no rule governs traffic without a human having signed off on it.
Publish
Approved policies are compiled together with the context they need: role definitions, column sensitivity labels, and the rules for identifying the governed object in a request.
Take effect
The decision point picks up the new policy on a short interval and swaps it in place — no restart, no dropped connections, no maintenance window.
Turn enforcement on one server at a time.
A new policy layer rarely goes in front of production traffic in blocking mode on day one. Enforcement mode is set per MCP server, so one deployment can run a mix.
Observe
Every call is evaluated and recorded. Nothing is ever blocked. Use it to learn what your agents actually do before you write a single rule.
Simulate
The platform records what it would have denied and lets the traffic through. This is how you size the blast radius of a policy before it can break anything.
Enforce
A denial goes back to the agent with the reason attached. Battle-tested servers can run here while newly onboarded ones are still in simulate.
Policy binds to columns, not just to tools.
Tool-level governance answers whether an agent may call a tool. Data owners generally need to go a level further, down to what the call can reach.
| Dimension | What it means |
|---|---|
| User role | The role of the person the agent is acting for, taken from your existing enterprise identity provider rather than re-keyed by hand. |
| AI actor | The agent or application making the call, identified from the provenance it carries. |
| MCP server | The registered server, which also carries its own enforcement mode. |
| Tool | The specific operation, and whether it reads, writes or deletes. |
| Table and column | The governed target, identified from the request itself — including columns referenced through a query rather than named directly. |
| Sensitivity | Labels applied at discovery — PII, PHI, GDPR, SOX, HIPAA — so a rule can say "no PII" without enumerating every column. |
Deny overrides allow. An explicit deny on a sensitive column cannot be widened by a broader allow rule somewhere else in the policy set.
The choices behind the architecture.
Each of these was settled deliberately, and the alternatives we considered are documented alongside them.
Policy is published, not proxied
FaburAI produces governance policy and makes it available. It does not carry your traffic, so it cannot become a bottleneck or an outage in your critical path.
Decisions are made where the work happens
The decision point runs alongside the tools it governs, inside your environment. Evaluation is local, which is why it keeps working when we are unreachable.
Your environment initiates every connection
Policy is retrieved outbound and decision records are sent outbound. Nothing connects inbound to you, so on-premises deployments open no firewall holes for us.
Governance state is isolated from the workload
The catalog, the policy model and the decision record live in their own tenant boundary, separate from the tools being governed. Blast radius stays contained.
One product, every deployment model
The same codebase runs as hosted SaaS, in your own cloud account, or fully on-premises on Kubernetes. Self-hosting does not mean a lesser product or a reduced feature set.
See the architecture in detail.
If your team is evaluating how to govern AI access to enterprise data and tools, we are glad to walk through how this works in your environment.