How it works

From your first connector
to a defensible decision.

SecSemantic is deliberately boring to deploy: agentless connectors, read-only to start, running in your environment. The interesting part is what happens after — the graph, the reasoning, and the gate.

Agentless Read-only connectors to start First graph in hours
01 — CONNECT

Plug into what you already run.

No agents to roll out, no traffic to mirror. SecSemantic reads from the tools you already pay for — exports, APIs, and the inventory workbooks your team already keeps.

SIEM & XDR

Alert and event streams from Splunk, Microsoft Sentinel, QRadar, and comparable platforms — with provenance kept, so every derived finding traces back to its source events.

EDR & endpoints

Process, file, network, and behavioural telemetry — CrowdStrike, SentinelOne, Microsoft Defender, and comparable exports — resolved onto the fleet.

Identity

Accounts, service principals, and grants. Who can reach what is half of every attack path, so identity gets first-class treatment.

Cloud & network

Cloud audit events, DNS, and firewall exports — including the humble IP-to-hostname mapping that makes everything else line up.

Business inventory

Your application and server workbooks, imported as-is. Owners, business units, and your own criticality ratings become graph semantics.

Guided intake

A short structured interview captures what no export contains: crown-jewel systems, who owns them, and which accounts should reach them.

02 — FUSE

Three names. One node.

Entity resolution is the unglamorous work that makes context possible. Every source names your systems differently; SecSemantic resolves them onto shared canonical entities, so business facts and live telemetry land on the same node.

Your workbook says db-fin-02 · “Finance reporting DB” · criticality: high
Your EDR says DB-FIN-02.corp.local · 214 process events today
Your firewall says 10.4.2.117 · inbound from BI subnet
The graph says ◆ db-fin-02 — one node · owner: Finance · high criticality · 3 sources agree · reachable by 4 identities

Resolution is deterministic — canonical host keys, not fuzzy guesses — so the same input always builds the same graph, and every merge is explainable.

03 — REASON

The graph decides what’s true.
The model decides what to say.

Everything with a number behind it is computed by graph analytics you can audit. The model never invents a figure — it reasons over computed facts and writes the explanation.

Computed on the graph

  • Blast radius — what an entity can reach, weighted by criticality
  • Attack paths — attacker-traversal search from footholds to crown jewels
  • Chokepoints — the edges whose removal collapses path families
  • Detection coverage — ATT&CK techniques vs. your real telemetry
  • Exposure trend — how reachability shifts as your environment changes

Written by your model

  • The morning briefing — posture in plain language, facts cited
  • Incident reasoning — confidence scores with a visible factor trace
  • Investigation narratives — one line per step, conclusions you can check
  • Answers to Ask — phrased for the reader, grounded in the graph

Why this split matters: when an auditor, a regulator, or your board asks “why did the system do that?”, the answer is a chain of graph queries and a reasoning trace — not “the model felt confident.”

04 — ACT

Autonomy you can defend.

Every proposed action carries an AI confidence score built from severity, ATT&CK signals, threat radius, and what the target means to the business. The gate is simple and non-negotiable.

  1. SCORE

    AI assesses

    The model reasons over computed facts and scores its confidence, factor by factor — every ▲ and ▼ visible.

  2. GATE

    100% or a human

    Full confidence auto-contains immediately. Anything less waits in the approval queue with an SLA countdown.

  3. DECIDE

    Approve or reject

    Your analyst sees the same trace the AI used. One click approves, rejects, or resolves — singly or in bulk.

  4. RECORD

    Audit, immutably

    Creation, decision, actor, and outcome are appended to an immutable trail. What happened is never a matter of memory.

05 — DEPLOYMENT

Runs where your data lives.

A In your environment

Containerized services on your VMs or cluster — x86 or ARM, cloud or on-prem. Pair with a local model endpoint and the whole system, AI included, stays inside your boundary. Air-gap-friendly by design.

B Managed by Vikat

We run the platform; you keep control of connectors and the model choice. The right fit for teams that want the graph without new infrastructure to own.

Data handling, plainly

Connectors are read-only to start. Tenants are isolated at every layer — every query carries its tenant, enforced in code and tested. Your data is never used to train models, ours or anyone’s.

Model endpoints

Ollama, vLLM, AWS Bedrock in your account, private Azure deployments, or any OpenAI-compatible endpoint. Public APIs are opt-in, clearly labeled in the console, and switchable at any time.

A typical first month

DAY 1

Connect and see the graph

First connectors in, inventory imported, entity resolution running. You’re browsing your own environment in the Explorer the same day.

WEEK 1

Attack paths and chokepoints

Crown jewels marked in the guided intake, paths computed, the first chokepoint review with your team — usually the moment priorities get rewritten.

WEEK 2+

The gate goes live

Response policies agreed, approval queue in daily use, the audit trail accruing. From here the graph keeps learning your environment as it changes.

06 — QUESTIONS

Asked often, answered straight.

Does SecSemantic replace our SIEM or EDR?

No. It sits on top of them. Your detection stack keeps detecting; SecSemantic supplies the layer they’re missing — what each signal means for your business, and what to do about it. If anything, your existing tools get more valuable, because their output finally lands somewhere with context.

Do we need to install agents on endpoints?

No. SecSemantic is agentless — it reads exports and APIs from the tools you already run. Deployment is a set of containers in your environment plus read-only connector credentials.

Does our data leave our environment?

Not unless you choose that. Self-hosted deployments keep the graph, the console, and the model inside your boundary. The one decision that moves data is choosing a public AI API over a private endpoint — it’s opt-in, labeled in the console on every AI-written sentence, and reversible.

Which AI models can we use?

Any OpenAI-compatible endpoint. In practice that means Ollama or vLLM on your own hardware, Bedrock models inside your AWS account, private Azure deployments, or public APIs if you explicitly choose them. The platform defaults to private and falls back to deterministic output if the model is unreachable — the facts never depend on the model being up.

What if our telemetry is thin?

We tell you. Detection coverage is computed from the event volumes you actually ship, so thin sources get flagged and missing ones are named with what they’d unlock. An honest map of what you can’t see is often the first win.

How long until we see value?

The first graph builds in hours, and the first chokepoint review usually happens inside week one. There’s no six-month data-lake project hiding behind the demo — the demo is the deployment path.

Is it multi-tenant? We run several environments.

Multi-tenant from day one. Every entity, query, and API call carries its tenant; isolation is enforced in code and covered by tests, not by convention. Load a subsidiary, a region, or an acquisition as its own tenant and switch between them.

How is it priced?

By environment size, on an annual subscription — no per-seat metering, no per-query surprises. We’ll scope it in the first call once we know roughly how many assets and sources you’re bringing.

The demo is the deployment path.

Thirty minutes, live in the console. Bring your architecture questions — that’s the point.