Entity Graph
The temporal knowledge graph your detections reason over
Every observed IP, credential, host, role, and API caller becomes a node; every session, grant, and API call becomes an edge — with timestamps, so you can query the graph at any moment in the last 180 days.
Not a CMDB. A live graph with memory.
Traditional asset inventories are snapshots. The ManySignal entity graph is a continuously updated bipartite graph: entity nodes (users, devices, services, roles) connected by relationship edges (logged-in-from, assumed-role, called-api, owns-resource). Every edge carries a timestamp range, so "who had access to this S3 bucket on March 3rd?" is a point-in-time graph query, not a manual log search.
- Nodes are deduplicated across sources — one user record whether events arrive from Okta, CrowdStrike, or AWS CloudTrail
- Relationships carry confidence scores derived from observation frequency
- Lateral-movement paths are pre-computed as shortest-path traversals, not assembled on-demand during an incident
- Blast radius is estimated at alert time, not investigation time
Graph layers that matter in practice
Identity layer
Human accounts, service accounts, API keys, and OAuth grants are unified under a single identity node. Auth events from Okta, Entra ID, Duo, and AWS STS are correlated automatically — so a single-user pivot account used across cloud and on-prem appears as one node, not four.
- Federated identity merging across IdPs
- Stale credential detection: keys not rotated in >90 days
- Privilege escalation path highlighting
Identity layer
Asset and workload layer
Hosts, containers, serverless functions, and cloud resources are nodes annotated with their current and historical configuration state. Changes to security groups, IAM policies, and container images appear as versioned edges, queryable at any time.
- EC2, EKS, Lambda, Azure VM, GCP Compute all covered
- Tag-based business context: environment, team, data classification
- Historical config diff on demand
Asset and workload layer
Behavioural baseline layer
For each entity, the baseline worker computes rolling profiles: active hours, access geographies, typical API call patterns, and event volume. Deviation scores update continuously. Detections reference the baseline at the time of the event — not the current profile — so baselines cannot be poisoned by slow reconnaissance.
- Per-entity UEBA scoring, not population averages
- Warm-up period indicated in UI so analysts know baseline confidence
- Deviation magnitude and direction stored for trend analysis
Behavioural baseline layer
Entity Graph — FAQ
How do you deduplicate identities across sources?
A resolution pipeline matches entities by stable keys first (UPN, ARN, serial number), then by fuzzy keys (display name + domain, MAC address). Confidence-scored links are surfaced in the UI when automatic merge is uncertain.
What is the 180-day retention window?
Edge and node state changes are stored with full timestamps for 180 days in the default tier. You can extend to 365 days or beyond under a data retention add-on, or configure per-source retention policies.
Can the graph ingest data from on-premises Active Directory?
Yes. A lightweight Windows agent ships changes from AD replication events to the ingestion pipeline. No domain admin rights required — read-only LDAP polling is also supported for restricted environments.
How is the graph used by detection rules?
Rules can reference graph properties directly: `entity.blast_radius > 50`, `entity.days_since_last_login > 60`, or `path_exists(source, target, max_hops=3)`. The graph is evaluated at rule compile time and at trigger time.
Does the graph handle multi-cloud environments?
Yes. AWS, Azure, and GCP resource nodes are normalized into a unified asset schema. Cross-cloud relationships — such as an on-premises service account assuming an AWS role — are captured as edges.
How is blast radius estimated before automated response runs?
At alert time, the graph traversal engine computes the set of reachable resources from the affected entity within a configurable hop limit. Blast-radius score (0–100) is attached to the finding before the triage agent evaluates it, enabling the autonomy ladder to gate high-radius actions for human approval.
Can analysts query the graph interactively during an investigation?
Yes. Natural-language search translates investigator questions into structured graph queries. You can also use the graph UI to pivot from any node — see all accounts a device has authenticated as, all resources a role can access, or all peers a service account has called in the last 30 days.
How does the graph handle non-human identities like service accounts and API keys?
Non-human identities are first-class nodes with their own edge types: assumes-role, calls-api, owns-secret, deployed-in. Cross-source correlation links, for example, a GitHub Actions token to the AWS role it assumes and the S3 buckets it touches — giving full supply-chain visibility.
Is the graph queryable via API for integration with our own tooling?
Yes. The ManySignal API exposes graph query endpoints that accept structured queries over entities and relationships. The API is documented at /platform/api and supports both point-in-time and range queries. Rate limits apply per tenant tier.
See the graph on your own data
A 60-minute session with the engineering team walks through your identity topology, lateral movement paths, and blast-radius estimates — using your own connectors.