For security engineers and architects

Built to fit your architecture.
Not replace it.

Pentra Graph reads your existing tools, models what it finds as a time-aware graph, and runs investigations under policy. Every write-back goes through review before it reaches your system of record.

Architecture and data model

A time-aware graph of your environment.

Detections and telemetry are pulled from the tools you already run and normalized into a shared entity model. Relationships carry a timestamp, so the graph reflects what was true at the moment of the incident, not just the current state.

01 | Ingest

Read-only connectors

Pentra Graph reads from your SIEM, EDR, identity provider, and case tool. It does not require standing write access to collect data.

02 | Model

Shared entity model

Actors, accounts, devices, processes, files, network, alerts, cases, evidence, and decisions are represented as entities with typed relationships.

03 | Correlate

Time-aware edges

Edges carry a validity window, so an investigation can be checked against the state of the graph as it existed at the time.

04 | Write back

Reviewed updates only

Proposed updates to your case tool or ticketing system queue for analyst review before they are committed.

What lives in the graph

  • EntitiesActors, accounts, devices, processes, files, network segments, alerts, cases, and evidence.
  • RelationshipsTyped edges between entities, each carrying the time window it was observed.
  • DecisionsThe verdict, the evidence behind it, and the analyst who signed off.

What stays in your environment

  • CredentialsConnector credentials are stored and used inside your boundary.
  • Raw logsSource logs stay in the SIEM or data lake you already run; the graph references them, it does not copy the raw store.
  • System of recordYour case tool remains the source of truth. Pentra Graph proposes updates to it, it does not replace it.

Automation and control mechanics

Policy-driven investigation, human sign-off.

Automation follows the graph under a defined policy: it can gather evidence, test benign explanations, and propose a verdict, but it stops and hands off whenever the evidence does not clear the bar.

Stop conditions

Evidence thresholds, not confidence scores

A case advances only when the evidence for a verdict clears a defined threshold. Incomplete, contradictory, or stale evidence routes the case to an analyst instead of forcing a close.

Entity resolution

Deterministic merge, explicit uncertainty

Records merge into one entity only when identifiers match under a defined rule set. A weaker match is kept as a labeled possibility instead of being folded into the entity silently.

Decision audit trail

Replayable, not summarized

Every question asked, piece of evidence reviewed, and verdict reached is logged against the case. The trail can be replayed step by step, not just read as a final summary.

Deployment boundary

Your data does not leave to train anything

Connector credentials, logs, and case data stay inside the boundary you configure. None of it is used to train models for other customers.

Talk to an architect

Bring your stack diagram. We will show you where the graph fits.

Tell us what SIEM, EDR, identity, and case tools you run today. We will walk through the connector model and the write-back boundary in detail.

Go to contact form