MCP discovery scanners
Finding a server is not the same as governing what reaches it.
Network and MCP discovery scanners are good at the same first question FaburAI asks: what servers exist, and where. That overlap is real. Where a scanner stops is everything after — which role, together with which AI actor, may reach a given tool or column, and whether that access is actually decided and enforced. A scan has no layer to hold that policy in; FaburAI does.
An AI security program needs all three answered.
Discovery, access, and enforcement sound like one capability from a distance. They are answered by different mechanisms, and a program that only has the first one has an inventory with no policy attached to it.
Discovery answers: what exists
A scan finds the servers reachable on the network — the same first step FaburAI takes.
Access answers: what may reach it
Attribute-based policy — role, AI actor, tool, table, column — decides what a discovered server is actually allowed to expose, and to whom.
Enforcement answers: what actually happened
A decision record exists because a call was evaluated, not because a scan was scheduled.
Six questions, asked the same way every time.
Every cell below states what that category actually does for that row — not a checkmark, not an X, and not left out to make the comparison look one-sided.
| Criterion | Discovery scanner | FaburAI |
|---|---|---|
| Discovery model | Finds MCP servers reachable on the network, on a schedule or a manual sweep — a snapshot of what responded. | Finds servers the same way, and also records what a sweep cannot see: an AI actor observed calling in is added the moment it appears, not at the next sweep. |
| What it governs | Which MCP servers exist and are reachable — the inventory, not the relationships around it. | The full relationship graph — role, AI actor, server, tool, table, and column — and what may pass between them, decided by attribute-based policy. |
| When it acts | On a schedule or a manual sweep — a snapshot of the network at that moment. | Continuously, at the moment of every governed call, for as long as the AI actor runs. |
| What it produces | An inventory: which MCP servers exist, where, and what they expose. | That same inventory, plus a decision record: the AI actor, the user role behind it, what it reached, the outcome, and the rule that decided. |
| Data residency | Typically the scanning vendor's own cloud platform. | Stays inside the customer's own environment and never leaves it. |
| Where enforcement happens | Nowhere — a discovery scan finds a server. It has no policy layer, and nothing to decide or enforce with. | Inside the customer's environment, at the moment of the call, evaluated locally against attribute-based policy already retrieved. |
One ends at an inventory. One ends at a decision.
Laid out side by side, the gap is what happens after a server is found. An inventory with no policy attached to it cannot say who may reach what — only a decision, evaluated at the moment of the call, can.
On a schedule, or run manually against the network.
MCP endpoints found, and what they expose at that moment.
A list of servers found. No policy attached to any of them.
At any moment, not on anyone's sweep schedule.
Role, AI actor, and target evaluated together, inside the customer's environment.
Not once — again on the next call, and the one after that.
A discovery scan and FaburAI can find the same server. Only one of them can then say who may call it, and prove what happened when someone did — because only one of them has a policy layer to decide with.
FaburAI can connect to your discovery scanner.
It becomes one more observed source in the same estate graph as every other AI surface FaburAI governs — no rip-and-replace, and nothing about the scanner itself has to change.