Relations

Relations are directed edges between graph entities. They show how one entity was discovered from another, how entities are structurally connected, or how an attack path moved through the environment.

How to Read a Relation

A relation records one of these facts:

• How was this entity discovered?

• What does this entity belong to?

• Which asset runs this service?

• Which browser session, role, or identity was used?

• Which test case set produced this vulnerability?

• Which internal object can control or compromise another object?

Example:

Domain -> BrowserSession -> WebPage -> Goal -> Trajectory -> TestCaseSet -> Vulnerability

This chain means the vulnerability was found by testing a trajectory generated from a page under the domain, inside a specific browser session.

Each BrowserSession represents one recorded role or identity, such as an unauthenticated visitor, a standard user, or an admin. Pages, goals, trajectories, and test case sets are grouped under that session so the graph can distinguish what was reachable or testable from each identity.

TestCaseSet is the main testing node in this path. It contains the generated test cases for a category or trajectory. Individual TestCase details may appear in deeper finding or debugging views, but the high-level relation should be read through the TestCaseSet rather than as a separate normal hop for every graph path.

Relation Metadata

Some relations include module or submodule references. These are useful for support and debugging because they connect graph output back to Activity, logs, and LLM traces.

Triage Tips

• A vulnerability without a plausible incoming path should be reviewed carefully.

• A duplicate finding should link back to the original finding or share the same affected path.

• Internal relations involving credentials, tickets, AD objects, or delegation should be reviewed before cleanup decisions.