The Right Pivot, at the Right Moment: Crogl's Knowledge Graph

Security investigations rarely fail because the data does not exist. They fail because the analyst cannot quickly see how the data connects.

An alert in one system may identify a person by email address. The identity platform may use a user principal name. A ticketing system may store the same person as a reporter. An endpoint platform, cloud service, or custom internal tool may use another identifier entirely.

The facts are present. The challenge is knowing which system to query next, which field carries the same identity, and whether the apparent connection is meaningful.

Today, that knowledge often lives in the heads of a few experienced analysts. It is distributed across schema notes, detection logic, scripts, runbooks, and hard-won operational memory. It does not reliably scale to every analyst, every shift, or every autonomous investigation.

Crogl's Knowledge Graph turns that operational memory into something persistent and usable.

Watch Lipyeow Lim, Head of AI at Crogl, explain how it works:

It remembers what your analysts had to memorize

The Crogl Knowledge Graph learns relationships between fields across the systems connected to Crogl. Its first job is deliberately concrete: recognize when fields in different sources carry the same identity.

For example, Crogl may learn that:

• a Splunk recipient_email corresponds to an identity provider's userPrincipalName;
• a Jira reporter.emailAddress is another representation of that person;
• a file hash, endpoint identifier, cloud principal, or Windows SID appears in more than one connected system.

This is not a threat-intelligence graph, a replacement SIEM, or another search interface that an analyst needs to learn. It is operational memory for Crogl's investigating agent.

When an investigation touches a known field, Crogl can surface the related fields and systems at that moment. The agent receives the next useful pivot as part of its normal workflow.

Crogl does not merely find data. It remembers where the investigation can go next.

In a rendered graph from a Crogl operating environment, the gold edges are those learned cross-connector relationships. They are not a manually maintained integration map. The other colored edges describe relationships inside their respective connectors, and not every system needs to be connected to every other system before the graph becomes useful. Crogl learns useful relationships as it observes evidence.

Your data strategy, not ours

Organizations have different and valid approaches to security data.

Some centralize and normalize a high-value core of telemetry in a SIEM or data lake. Others intentionally keep data in the systems that produce it, because centralization can introduce cost, latency, duplicated data, loss of source context, or governance constraints. Most organizations operate somewhere between those poles.

Crogl does not require a customer to choose one architecture before it can investigate across the environment.

Lake-first

If an organization has a normalized core, Crogl can work alongside it and help connect investigation paths that extend beyond the lake's current coverage. That may include identity systems, ticketing platforms, SaaS applications, cloud APIs, proprietary tooling, and newly introduced sources.

Source-first

If an organization keeps data in native systems, Crogl can learn relationships through those systems' connectors and native query interfaces. There is no requirement to centralize the full operational datasets before cross-system investigation can begin.

The shared outcome is the same: an analyst or agent can follow the right pivot at the right moment.

Normalization is optional. Cross-system investigation is not.

How Crogl learns relationships

Crogl builds the Knowledge Graph in the background through a practical cycle:

1. Connect. Crogl works through connectors for the security and business systems a customer already operates.
2. Observe. It explores available catalogs and captures representative samples needed to understand fields and identities.
3. Validate. Crogl looks for real value overlap in the specific fields that may be related, then evaluates whether the relationship is semantically meaningful.
4. Remember. Confirmed relationships and their supporting evidence become persistent knowledge for future investigations.

The data itself remains in the operational systems that own it. Crogl retains representative samples locally as evidence for learned relationships; it does not require a full copy of the customer's operational estate.

This approach also makes the graph useful in an environment that is never finished. New systems arrive, custom fields appear, schemas change, and security teams continually adjust the data they prioritize. Crogl can learn as the environment evolves rather than waiting for complete normalization coverage.

Evidence must prove

Cross-system correlation has to earn trust. A shared value alone is not always meaningful, and an AI system should not be allowed to invent connections.

Crogl treats an observed relationship as a claim that must be supported by evidence. It requires real, non-junk value overlap in the specific fields under consideration. Candidate relationships can be judged for semantic meaning, but server-side rules determine whether a relationship is accepted. The resulting relationship retains supporting evidence and an auditable history.

The principle is simple:

The model can propose. Evidence must prove.

Crogl also keeps the knowledge graph out of the critical path of an investigation. A missing or unavailable hint does not interrupt the underlying query or investigation. It simply means Crogl has one less piece of context to offer on that turn.

Five sources. One narrative.

The value of the graph is not a visualization of nodes and edges. The value is what happens when an investigation gets better.

Consider an investigation that begins with a Jira ticket and its reporter.emailAddress. The graph can identify the related userPrincipalName in an identity provider and recipient_email in Splunk, then guide the investigating agent to the relevant next systems. The analyst still receives the evidence and makes the final call.

At that point, the graph's value is not the graph itself. It is an evidence- backed investigation outcome: cloud instance context, VPC Flow Logs, CloudTrail activity, endpoint coverage, and threat intelligence can become one narrative, one recommendation, and a report an analyst can review, challenge, and act on.

Not more data. A decision, with its evidence.

That creates three practical benefits:

• Faster investigations. Analysts and agents spend less time rediscovering field names, source boundaries, and manual pivots.
• More consistent investigations. Useful relationships are not limited to the person on shift who happens to know the environment best.
• Compounding operational knowledge. Each learned relationship can improve the next investigation.

Useful pivots stop depending on who is on shift.

Built for your infrastructure

The Knowledge Graph runs in the customer environment, including on-premises, private-cloud, and air-gapped deployments. Credentials remain outside the agent, and relationship history is auditable.

The operational controls matter because a useful graph must also be a trustworthy one: relationships can be inspected and removed, and learning can continue as sources and schemas change.

Try it with the systems you already have

The most useful way to evaluate the Crogl Knowledge Graph is with real sources that share identities. Connect two systems, let Crogl learn their catalogs and relationships — often in hours, not months — and then run an investigation.

You do not need to finish a data-lake program first. You do not need to abandon one if you already have it. Crogl meets the environment as it exists today and helps turn scattered security data into evidence-backed operational memory.

Download Crogl to get started.