A closed loop, not a shelf of point tools
Most of this category is either detection with no stop attached, or a dashboard with no decision attached. Bairav closes the loop instead: discovery feeds scoring, scoring feeds policy, policy feeds enforcement, and the record feeds back into discovery — one system, no gap where an incident has time to happen.
A tool that only detects hands you a finding. A dashboard that only monitors hands you a chart with no button to press. That gap — "we saw it" vs "we stopped it" — is where incidents live.
Agents are not users wearing a costume
Extending your identity system to cover agents gets you no real lifecycle, no clear owner, no concept of what it's allowed to invoke. Bairav treats non-human identity as its own class — discovered, classified, registered, governed, contained, evidenced.
1 · Discovered
Has an identity and a fingerprint. Counted as ungoverned until it has a rule.
2 · Classified
A reviewer sets sensitivity, capabilities and an accountable owner. Risk recomputes live.
3 · Registered
Enters the governed system of record with an agent ID and three independent scores.
4 · Governed
Rules attach — block, approval gate, flag or notify — reported by enforcement strength.
5 · Contained
Rejected, suspended, or blocked for cause. Identity and history persist; only operation stops.
6 · Evidenced
Every action, decision and approval, retained in an append-only ledger.
More than one way to enforce, on purpose
A control plane with one integration point has one point of failure. Bairav supports several enforcement paths, so the mechanism matches the deployment — not the other way round.
Sidecar / proxy
Enforcement sits in the request path, alongside the workload. Fits container and service-mesh environments where the platform team already owns that pattern.
DNS override
Redirects model and API traffic to the enforcement point without touching application code. The path for agents nobody can safely modify — including the ones nobody formally procured.
SDK
Direct integration for teams building their own agents who want the decision made inside the application, not in front of it.
MCP gateway as a first-class enforcement point
MCP servers are where agents acquire new capability, so the gateway is a first-class enforcement point, not just a discovered artifact — it has to sit between the agent and the tool.
ABAC and RBAC, together
Role-based access answers "who is this." Attribute-based access answers "what's true right now." Agents need both — a role, plus the attributes to say whether this action should be allowed.
Scope is honest — the platform never claims control it doesn't have.
The loop, in interfaces
Discovery
Finds the entity and proposes a classification and provisional risk score.
Assessment
Scores it on four factors, checks it against OWASP, assigns an accountable owner.
Policy
Attaches enforceable rules with a declared scope and enforcement state.
Enforcement
Decides — allow, block, flag or notify — and records the reason and latency.
Audit
Writes an append-only, hash-chained entry: decision, approval and outcome.
Because the same identity carries through every stage, a question asked at the end — why was this allowed? — resolves backwards to the rule, the classification, and the person who approved it, without correlating across three tools and two teams.
Gateway config, roles and platform settings
An Administer pillar sits underneath everything above: gateway configuration, role-based administration, and platform settings for the team running Bairav day to day.
No certification claims. No named-competitor comparisons. No customer counts, deal sizes or agent volumes. Every number on this site comes from a demo environment and is labelled as such.
Architecture review, not a slide deck
A working session with your platform and security engineers on enforcement placement, identity model and evidence retention.