A traditional SIEM is a log warehouse with a query language stapled on. Every detection is a search that scans rows, re-joins indices, and tries to reconstruct context the schema threw away at ingest. Netgraph inverts the model: events are ingested into a security knowledge graph where identities, assets, sessions, processes, network flows, vulnerabilities, and controls already know about each other. Detections are graph traversals, not text searches.

The practical consequence: a query that takes a SIEM 90 seconds across 30 days takes Netgraph under two seconds, because the joins are already materialised as edges. Read Graph-native correlation and Why the graph is the product for the architectural argument.

Three reasons, in order. One: ingest cost. Legacy SIEMs charge by ingested volume, which means your detection coverage is gated by your finance team. Two: correlation debt. Every new log source means new joins, new lookups, new field-extraction rules; six months in, your engineers spend more time keeping detections alive than writing new ones. Three: closed-loop ops. The SIEM tells you what happened; the SOAR runs a runbook; the EDR contains the host; nothing learns. Netgraph collapses ingest, detection, investigation, response, and feedback into one graph. See MTTD vs correlation debt for the quantitative case, and the BFSI case study for what the migration actually looked like.

Search engines answer "find me events matching this pattern". Graphs answer "what is connected to what, and how far". Real attacks are not patterns in one log stream — they are paths across identity, endpoint, network, cloud control plane, and data store. A search-first tool sees five disconnected alerts; a graph sees one path with five hops and a blast radius.

Concretely: when a service account in your finance VLAN authenticates to a workload it has never touched, Netgraph already knows the account's normal neighbourhood, the workload's owner, the data it stores, the controls that should have stopped it, and which other hosts share the same lateral-move risk. A search engine knows only that an auth event exists. That difference is the entire product.

Three engineering choices. First, columnar tiered storage with hot, warm, and cold tiers — most data lives in cheap object storage, not in expensive search indices. Second, ingest-time normalisation into graph nodes and edges, so we never re-parse the same event at query time. Third, no per-GB licence: Netgraph is priced by sustained event-rate and seats, not by what your finance team had to ration last quarter.

In practice, customers consolidating from a legacy SIEM see ingest-tier costs fall 55–75 percent at parity coverage, and they ingest more sources because the marginal cost approaches the marginal cost of disk. The MSSP case study documents the unit-economics shift.

SOAR-on-top is a workflow engine reading alerts the SIEM produced from logs it threw away. Every playbook starts by re-fetching context the SIEM didn't keep, calling APIs that time out, and bolting together a story the analyst then rewrites. The result is a runbook that looks automated but spends 70 percent of its execution time on enrichment.

Netgraph's response layer reads from the same graph that produced the detection — context is already there, the asset owner is already known, the blast-radius is already computed. Playbooks shrink from 40 steps to 6. See SOAR without tears for a worked example, and Blast-radius as a first-class concept for why bolt-on SOAR can't reason about containment scope.

No. An entity page in a search-first SIEM is a saved query that aggregates rows about a user or host. It is a view, not a data structure. You cannot ask it "show me every path of length ≤ 4 from this compromised identity to a crown-jewel data store, weighted by privilege" — because the edges don't exist in storage, only in the analyst's head.

Netgraph's graph is the storage layer. Identities, devices, sessions, processes, files, flows, and controls are nodes; relationships are edges with type, time, and weight. Detections, investigations, and response actions all traverse this graph. A dashboard showing an "entity" is the symptom; a real graph is the cause.

Replaces, in the operational sense that matters: one data model, one query layer, one detection-as-code workflow, one response layer, one audit trail. UEBA stops being a separate product because behavioural baselines are a property of nodes in the graph. TIP stops being a separate product because indicators are just edges with a provenance attribute. SOAR stops being a separate product because playbooks are graph-mutating actions with the same RBAC as queries.

Best-of-breed-lite would mean four products with a shared logo. Netgraph is one product with four surfaces. See UEBA after the honeymoon for why separate UEBA products usually fail by month nine.

Leading vendor Type A wins on installed base, marketplace, and the comfort of a brand your auditor recognises. It loses on ingest economics, time-to-detection on cross-domain attacks, and any scenario that requires reasoning about relationships rather than matches. The bolted SOAR adds latency; the bolted UEBA adds another silo; the marketplace adds drift.

Netgraph is not trying to be a friendlier Type A. It is a different architecture: graph-first storage, detection-as-code by default, closed-loop response, air-gap-ready deployment, no per-GB licence. If your renewal is more than 18 months away you have time to evaluate properly; if it's closer, run a paid PoV on your three hardest detections and measure MTTD and engineer-hours side by side.

An AI-SOC overlay sits on top of your existing SIEM and EDR, reads their alerts, and tries to summarise, triage, or auto-close them with an LLM. It is a thin reasoning layer on someone else's brittle data model. When the underlying SIEM mis-correlates, the overlay confidently mis-triages — faster and at scale.

Netgraph owns the data model. The agent layer reasons over a graph it can trust, with provenance on every edge and a deterministic query layer underneath the LLM. The agents propose; the graph verifies; the human approves the irreversible actions. Read AI-SOC overlays vs graph-native platforms for the side-by-side, and Closed-loop detection engineering for why "owning the loop" matters.

Leading vendor Type B is attractive when your workloads are already on one hyperscaler — the integration is free, the bundle discount is real, and the first six months feel cheap. The trade-offs hit later: data gravity locks you to that cloud, multi-cloud blind spots widen, and the detection content is optimised for the host platform's telemetry rather than your business.

Netgraph runs in your environment — your VPC, your on-prem cluster, your air-gapped enclave — and treats every cloud as a peer. For regulated Indian customers this matters: see Air-gapped and DPDP-first. If you are single-cloud, single-region, and unregulated, Type B may be fine. If you are multi-cloud, hybrid, or regulated, the bundle becomes a moat against you.

Leading vendor Type C is what the market calls "AI-SOC" — products that promise to reduce L1 toil by auto-triaging alerts from your existing stack. The demos are genuinely impressive on cherry-picked alerts. The production reality is more sobering: the overlay inherits every correlation gap and false-positive bias of the SIEM underneath, then amplifies confidence with prose.

Netgraph's agent layer is not an overlay — it is a participant in the same graph the detections fire from. It can verify its hypotheses by traversing edges, query control state, and roll back its own actions through the same audit trail as a human analyst. If you already pay for Type C, keep it on your noisy stack and run Netgraph on your crown-jewel domain in parallel for one quarter. The comparison writes itself.

Most are graph-flavoured, not graph-native. The difference matters. Graph-flavoured means there is a visualisation that draws nodes and edges on top of a relational or columnar store; the edges are computed at render time by joining tables. Graph-native means the storage layer itself is a property graph: edges are first-class, traversals are O(degree), and detections are written as paths rather than joins.

The litmus test: ask the vendor for a 5-hop traversal across 90 days of identity, endpoint, and network data, returning in under three seconds on a single mid-range cluster. Graph-flavoured products either time out, sample, or quietly degrade to a similarity score. Graph-native correlation walks through the benchmark methodology.

Three guards. First, grounded reasoning: agents cannot cite a fact that isn't a node or edge in the graph; every claim in an investigation summary carries the underlying node IDs and timestamps. Second, deterministic tools: agents call typed graph queries and signed playbooks, never free-form code, so the action space is bounded and auditable. Third, human-in-the-loop on irreversibles: containment, isolation, account disable, and data-store quarantine require an approval token from a named human, with the agent's proposed action diffed against current state.

Hallucination doesn't disappear — it becomes visible. If the agent says "this user accessed payroll", you can click the edge and see the session. If the edge isn't there, the claim is rejected before the analyst ever sees it.

No. The agent layer supports three modes. Mode 1 — fully on-prem: a self-hosted open-weights model runs inside your cluster, nothing leaves the boundary. This is the default for air-gapped and regulated deployments. Mode 2 — sovereign hosted: a managed inference endpoint inside your chosen region under a tenant-isolated contract, with prompt and completion logs retained in your storage, not the provider's. Mode 3 — managed hybrid: routing low-sensitivity reasoning to a hosted model and high-sensitivity reasoning to the on-prem model, configurable per data class.

Customers under DPDP, RBI, SEBI, IRDAI, or MeitY scrutiny almost always pick Mode 1 for production. See Air-gapped and DPDP-first for the deployment topology.

We don't ship that, and we're explicit about why. Detections that mutate without engineer review are untestable, unreviewable, and unauditable. The first time one auto-tunes a threshold past a real attacker, your post-incident review will not be able to reconstruct what the rule was on the day of the breach.

Netgraph supports suggested tuning — the graph surfaces noisy detections, proposes baseline adjustments, and lets engineers accept, reject, or rewrite as a code change. Every accepted change goes through CI, replay against historical data, and version control. "The detection wrote itself" is a great demo and a terrible audit answer. See Detection-as-code without a platform team.

An overlay closes the alert. Netgraph closes the loop. When an analyst triages an incident, the outcome — true positive, false positive, benign-but-interesting — is written back to the graph as an annotation on the detection. The detection-engineering surface aggregates those annotations, flags rules with degrading precision, and proposes concrete changes (a missing exclusion, a tightened threshold, a new context join).

The engineer reviews the diff, runs it through replay against the last 90 days, watches the precision/recall projection, and merges. The new detection is live within hours, not weeks. That is closed-loop. See Closed-loop detection engineering and Retrospective detection — the quietly overlooked superpower.

Truly air-gap-ready. The full stack — ingest, graph, detection engine, agent layer, response layer, UI — runs on a disconnected cluster with no outbound calls required for steady-state operation. Updates ship as signed offline bundles; threat-intel ships as signed delta files on the schedule of your choice; telemetry to the vendor is opt-in and off by default.

"Air-gap-ready" is not the same as "we can turn off telemetry" — that's a checkbox, not an architecture. Read Air-gap-ready isn't a checkbox and the air-gapped manufacturing plant case study for what a real disconnected deployment looks like, down to the bundle-signing key ceremony.

Per-tenant isolation is enforced at four layers: storage namespace, graph partition, query authorisation, and key envelope. Every tenant's data is encrypted under a tenant-specific data-encryption key wrapped by a tenant-specific key-encryption key. Crypto-shredding means: deleting the KEK renders the tenant's data unreadable in seconds, regardless of where the ciphertext physically sits (hot tier, warm tier, cold object storage, backups). For MSSPs this turns offboarding from a week-long export into a key-destruction ceremony.

Cross-tenant query is impossible by construction — the query planner never receives a partition the requesting principal cannot read. See the MSSP case study and MSSP multi-tenant pitfalls for the failure modes we explicitly designed against.

Wherever you put the cluster. Netgraph is a self-hosted platform: you choose the region, the data centre, the rack. For Indian customers, the common topologies are (a) on-prem in your own DC, (b) on-prem with a DR site in a second Indian region, (c) inside an Indian sovereign-cloud tenant, or (d) air-gapped inside an OT or critical-infrastructure enclave.

No data leaves the cluster unless you explicitly configure an outbound integration. Threat-intel updates are pull-based and signed; the vendor has no standing read access to your graph. This satisfies the data-residency requirements under DPDP Act 2023, RBI's IT-framework circulars, and the MeitY guidance for government workloads. See Air-gapped and DPDP-first.

DPDP Act 2023: data-residency by deployment topology, purpose-binding via tagged ingestion, right-to-erasure via crypto-shredding, 72-hour breach-notification clock instrumented as a workflow with audit trail. See DPDP Act 72-hour clock.

CERT-In 6-hour: incident notification pre-templated from the graph, with timeline, affected assets, indicators, and containment status auto-populated. See CERT-In 6-hour reporting from the graph.

RBI / SEBI / IRDAI: log-retention, immutable audit trail, segregation of duties, and incident-reporting timelines are first-class. MeitY: air-gapped deployment topology, signed update bundles, and source-available detection content satisfy the empanelment posture for government workloads.

No. Raw events land in open columnar formats on object storage you own; the graph layer is materialised on top and can be rebuilt from the raw tier at any time. Detections are plain text in version control. Playbooks are declarative YAML. Schemas are documented and versioned. There is a documented bulk-export path that produces open-format files plus a schema manifest — no professional-services engagement required.

The architectural commitment is simple: your data, your format, your storage, our compute. If you decide to leave, you walk out with everything in a form a competent engineer can read, not a tarball that needs our DLL to open. This is also why ingest economics work — we are not selling you back your own data.

Yes. The reference small-tier deployment runs comfortably on three nodes — roughly 32 vCPU and 128 GB RAM total — and sustains 5–10k events per second with 90-day hot retention. That is well inside what a mid-market bank, hospital network, or manufacturing plant already runs for far less impactful workloads. The mid-tier (10–30k EPS, 180-day hot) is six nodes. Large-tier (>50k EPS, multi-region DR) scales horizontally.

Because the licence is not per-GB, you can right-size on workload rather than rationing data sources. The healthcare case study documents a 4-hospital deployment that replaced a six-figure annual SIEM bill with a three-node cluster and a part-time platform engineer.

It means every detection is a file in a Git repository, with an author, a reviewer, a test case, and a deployment pipeline. No more "Bob tuned the rule in the UI on Tuesday and nobody remembers what it used to be". Pull requests run the new or modified detection through historical replay, surface precision and recall projections, and block the merge if precision drops below a configured floor.

For your SOC the day-to-day shift is small: analysts still write detections in a human-readable DSL, not in code. The infrastructure underneath is what changes — review, replay, versioning, rollback, blame. See Detection-as-code without a platform team for the workflow without hiring a whole platform team to support it.

Three stages. Static validation: the detection is parsed, type-checked against the current graph schema, and screened for known anti-patterns (over-broad selectors, missing time windows, expensive traversals). Replay: the detection runs against the last 30–180 days of your real data; the platform reports how many alerts it would have raised, on which entities, with what overlap to existing detections. Canary: the detection is deployed in shadow mode to live traffic for a configurable window, alerts are scored but not actioned, and the engineer promotes to live once precision holds.

This is how detections that would have lit up the SOC at 3 a.m. get caught at 3 p.m. on a Tuesday in code review.

Replay re-runs detections against historical raw data in cold storage. Two use cases. One: when a new TTP is published, you write the detection today and ask the graph "would this have caught anything in the last 12 months?" — often the answer is yes, and the resulting incidents are real, recent, and previously missed. Two: when an existing detection is changed, replay tells you exactly which past alerts the new version would have raised or suppressed, so you can ship the change with eyes open.

Without raw-tier replay, detection engineering is faith-based. With it, you can answer "are we getting better?" with numbers. See Retrospective detection — the quietly overlooked superpower.

The five are: Triage (alert clustering, dedup, initial severity), Investigator (graph traversal, hypothesis testing, narrative summary), Hunter (proactive pattern search against the graph), Responder (proposes and — with approval — executes containment playbooks), and Detection Engineer (proposes detection changes from accumulated outcomes).

Governance: each agent has a typed tool catalogue, a per-action RBAC policy, a rate limit, and a human-approval threshold for irreversibles. Every agent action lands in the same audit log as a human's. Agents cannot escalate their own privileges, cannot edit their own policies, and cannot disable the audit pipeline. Bounded autonomy under a deterministic graph is the design rule. The agent layer is enabled per-module with explicit consent.

When a detection fires, Netgraph computes the blast radius as a graph neighbourhood: every node reachable from the indicator within N hops, weighted by edge type (auth-session, network-flow, shared-credential, shared-key, shared-secret-store). The containment playbook is parameterised by this neighbourhood — isolate these hosts, rotate these credentials, revoke these tokens, quarantine these data stores — not a static asset list defined six months ago.

The analyst sees the proposed action as a diff against current state, approves or trims the scope, and the playbook executes through signed connectors with every step audited. Read Blast-radius as a first-class concept. The H1 2026 top-20 vulnerabilities research walks through three real blast-radius scenarios from the past six months.

Six, in order of honesty. MTTD on cross-domain detections (not single-source — the easy wins are misleading). MTTR including containment and validated closure, not just acknowledgement. Detection precision measured weekly with analyst-confirmed outcomes. Coverage of your declared TTP catalogue with replay evidence. Engineer-hours per new detection shipped (this should fall by month three). Total cost of ownership including ingest, storage, licence, and engineer headcount against the legacy baseline.

Pair these with two negative KPIs: alert fatigue (alerts per analyst per shift) and correlation debt (detections that have been broken for more than 7 days). If those don't fall, something is wrong and we want to know. See MTTD vs correlation debt.