AI Control
See the paths. Govern the paths. Prove what happened.
Governance usually starts with someone writing a rule and hoping it matches reality. AI Control starts a step earlier — with what is actually connected to what — and ends a step later, with the record of every decision the rule produced.
Understand how the estate actually connects.
A catalog tells you what exists. It does not tell you that a support agent, acting for a tier-one role, can reach a customer table through a tool nobody thought of as sensitive. Relationships are where governance problems live.
Start from the data
Open a sensitive column and see every actor that has reached it, through which tool, on whose behalf. This is the question a data owner asks first.
Start from the identity
Open a role and see everything it can reach. This is the question that comes up in an access review, and it is normally the harder one to answer.
Each path also carries where it came from — declared by someone, observed in real traffic, or approved after review. A path that shows up as observed but was never declared is exactly the thing worth looking at.
Turn a path you can see into a rule that holds.
Most policy tools ask you to describe access in the abstract and then hope the rule matches the estate. AI Control works from the other end: trace the path in the graph, then govern that path.
Every hop you traced — the role, the actor, the server, the tool, the table — becomes part of the rule. The enforcement is shaped like the access path rather than being a broad permission that happens to cover it.
Fewer accidental grants
A rule built from a real path does not quietly authorize three other paths that share one of its hops.
Reviewable by non-authors
An approver can see the path the rule came from, which is a great deal easier to judge than a rule expressed only as conditions.
Grounded in reality
You are governing access that exists, not access someone believed existed when the document was written.
Describe the rule. Review what was drafted.
Paths are one way in. The other is plain language — "customer-success agents can read customer emails but not national identifiers" — which FaburAI drafts into a structured rule with its role, tool and column bindings attached.
The draft is a starting point, not an answer. It is shown to you in full so it can be corrected before anyone approves it — the person stays responsible for the rule.
What a rule can bind to
MCP server
Everything a given server exposes.
Tool
A specific operation, and whether it reads, writes or deletes.
Resource
A named resource the server exposes.
Table
A table behind the server.
Column
An individual field — the level data owners care about.
Prompt template
A specific prompt the server exposes.
Model version
A particular version of a model.
Agent version
A particular version of an agent.
Four effects, and one rule that settles conflicts.
Allow
The call proceeds.
Deny
The call is refused, and the reason names the rule that refused it.
Warn
The call proceeds and is flagged — useful while a rule is still being tuned.
Audit
The call proceeds and is recorded with particular attention, without interrupting anyone.
Deny overrides allow. A denial on a sensitive target cannot be widened by a broader permission somewhere else in the policy set, however that permission was written.
Nothing enforces until a person approves it.
Policies move through five states. The step that turns rules into what actually enforces refuses anything that has not been approved — the gate is a property of the system, not a process people are asked to remember.
Everything to the left of approval can be edited freely and governs nothing. That is what makes it safe to draft in the open.
Two ways to find out what a rule would do
Simulate against history
Evaluate a proposed rule against activity that has already been recorded, and see what it would have allowed and denied — before it governs a single live call.
Simulate against live traffic
Run the rule for real while letting every call through, recording what it would have denied. This is how you size the impact on production without taking the risk.
Proof of what actually happened.
A policy that enforces without leaving a record is difficult to stand behind. Every governed call produces a decision record, and every record can be taken apart.
| Recorded | Why it matters |
|---|---|
| The AI actor | Which agent or application made the call, and which version of it. |
| The user role behind it | Who the agent was acting for. An agent alone is not an accountable party. |
| Server, tool and target | What was reached, down to the table and column. |
| The outcome | Allowed, denied, warned or audited. |
| The rule that decided | Which policy produced the outcome — not just that something did. |
| The conditions evaluated | Which conditions matched and which did not, so a decision can be explained rather than asserted. |
| When | Timestamped, so a period can be reconstructed rather than described. |
Identity chain
One decision expands into its full provenance — identity provider, role, actor, application, server, tool, table, column, policy — on a single screen.
Replay
Take a decision made under an older policy and see whether today's rules would decide it the same way. Drift becomes visible instead of assumed.
Export
The record is queryable and exportable, so evidence for a reviewer is a filter and an export rather than a project.
This is what turns a compliance conversation from a description of intent into evidence of enforcement — not what the policy says should happen, but what the record shows did.
Bring a policy you actually need to write.
The clearest way to evaluate this is against a real rule your organization needs — including the awkward ones with exceptions in them.