Breach Paths

5 min read

How Tuskira's Digital Twin Validates Breach Paths

Published on

October 26, 2026

By the Tuskira Engineering Team

Your scanner can tell you a pod has a critical CVE. Tuskira’s digital twin tells you whether anyone on the internet can reach that pod, what they could get to from there, and which of your controls would stop them, see them or miss them.

This post covers how Tuskira’s twin is built, how a breach path goes from a projection to a proven finding, and where the AI stops. If you want the short version first, start with What is a digital twin in cybersecurity?

What comes out is a short list of proven paths, the controls that held or failed on each one, and the control change that closes it.

That focus is what changes the workload. In one global financial-services deployment, checking reachability, exploitability and deployed controls this way cut 12.3 million raw findings to 0.46% actionable. The scope and method are in the published case study.

Build order

Topology first. Findings last.

The twin is built in five layers, in a fixed order. Findings come last on purpose. A CVE means very little until you know which workload it sits on, what can reach that workload, and which controls stand in front of it.

Layer	What we connect	What it adds to the twin
1 · Exposure	DNS (Route 53, Azure DNS, Cloud DNS, Cloudflare), cloud networking, load balancers, security groups, routes	`app → url → dns → ip → load balancer`
2 · Runtime	Kubernetes (EKS, AKS, GKE), API gateways, service mesh	`cluster → namespace → ingress → service → pod`
3 · Defenses	WAF (Cloudflare, AWS WAF, Akamai, F5), runtime and endpoint (Falco, CrowdStrike, Defender), SIEM (Sentinel, Splunk, Elastic, Chronicle)	Which control protects which asset, and which logs can see it
4 · Risk	Vulnerability and cloud scanners (Tenable, Qualys, Rapid7, Wiz, Prisma), exploit intelligence (CISA KEV, VulnCheck, Exploit-DB)	Each finding attached to the pod, image or service it affects
5 · Identity	Entra ID, Okta, AWS IAM, CMDB, data security posture tools, ticketing	Who and what can act on each asset, and where sensitive data lives

Entities are resolved against the topology rather than matched to each other. DNS resolution decides which cloud resources belong to an application, and every later layer attaches to nodes that already exist. Connectors query your tools in place, so your logs stay in your SIEM.

Diagram of one application path in the Tuskira digital twin across five layers: exposure from app to app gateway, runtime from cluster to pod, defenses attached to the gateway and pod, findings attached to the URL and pod image, and identity from the pod service account to a data bucket — One application path across the five layers. Defenses and findings attach to nodes the topology already holds, which is what lets the twin say which control stands in front of which finding.

Around sensitive data

The path to the data is rarely direct.

A public application rarely connects straight to sensitive data. The route usually crosses an API gateway, a workload, a service identity, a cloud role and a network boundary first.

Because the twin holds those relationships together, it can test whether compromising the application gives an attacker the identity and permissions needed to reach the data. It also checks whether the WAF, endpoint, identity, network and detection controls you already run would stop that path or see it.

Validation

A projected path is a lead. A proven path is a finding.

Every path in the twin starts as a projection. It becomes a finding only when each hop is proven.

Project

Kairo, Tuskira’s breach path agent, walks the graph from an entry point to a crown-jewel asset, either outside-in from the internet or from an assumed-breach foothold, and maps each hop to an ATT&CK technique.

Validate each hop

A validator tests every hop inside the scope you approve and marks it proven or not proven. The path carries a confidence level until it is.

Pass three gates

Reachability, initial access, and achieved objective. A path that stops at a gate is recorded as stopped short or blocked, not discarded.

Record every control

Each defense on the path is recorded as blocked, detected or missed. A WAF rule left in count mode shows as missed, not as protection.

Keep the evidence

Each path keeps its replay, findings, assets, control results, ATT&CK matrix and an audit of what ran and what deliberately did not.

Illustrative hop ledger for one outside-in breach path, showing each gate, the ATT&CK technique, the hop, a proven result and whether the control on that hop blocked, detected or missed it — Illustrative. One validated path as a hop ledger. The control column is where most programs get surprised. A detection that never fired is a gap, even when the tool is deployed and licensed.

Each hop is checked from two sides. The attacker’s view is what an unauthenticated adversary can run from the internet. The defender’s view is a privileged read of your own configuration, the WAF rules, identity policies and endpoint coverage that an attacker can’t see. Pairing the two is what turns “this looks exposed” into “this is reachable, and nothing stands in the way.”

Kairo attack path storyboard step pairing the attacker command run from the internet with the Lattice blue-team validation that reads WAF rule coverage for the same endpoint — One hop in the product. (1) The command an unauthenticated attacker runs. (2) The privileged read by Lattice, Tuskira’s exposure prioritization agent, checking whether a WAF rule actually covers the exposed API docs. (3) The ATT&CK technique for the hop. Demo tenant with fictional domains.

The output is a short list of proven paths and the specific control that breaks each one. Not a ranked list of findings.

Tuskira Red and Blue Team Operations summary cards for a 90-day window, showing 2 of 20 breach paths reached a crown jewel and 5 of 14 defense checks held — Every Kairo run in a 90-day window, in a lab tenant. (1) Two of twenty paths reached a crown jewel. (2) Five of fourteen defense checks held, eight missed, and one technique worked with no alert.

Breach graph from gate 2 initial access through gate 3 achieved objective to crown jewels, with data accessed on two paths, one path blocked by a control and two paths reaching S3 buckets — The same runs through the last two gates. (1) Two paths reached data. (2) One was blocked by a control. (3) Both successful paths ended at the same crown jewel.

Agents

Five agents, one twin

Tuskira runs five AI agents on the same twin. Each answers one question, and a finding from one is context for the others.

VectorAutonomous red team agent

Can they get in? Probes your external perimeter within an approved scope. Kairo validates what it finds.

KairoBreach path agent

Where can they go? Projects and proves breach paths to crown-jewel assets across network, cloud and identity.

LatticeExposure prioritization agent

What matters most? Keeps only the findings that are exploitable, reachable and undefended in your configuration.

QuellZero-day response agent

Does this new CVE create a path? Checks reachability and existing control coverage before a patch exists.

IrisAI SOC agent

What happened, and what should we do? Investigates alerts and uses the path model to map blast radius.

The same twin carries through the whole incident lifecycle.

Before

Prove which paths can reach critical systems and data, then close them through controls you already own.

During

Iris investigates alerts against the same assets, identities, controls and paths, so blast radius starts from what is already known.

After

Apply the approved control change. Vector tests again from outside, so closure is confirmed by an attempted attack instead of assumed.

Compared

Alert-centric operations start from a signal. The twin starts from the environment.

AI SOC tools have moved well past triage. Many now hunt and tune detections, and they do it well. The difference is where the work starts and what evidence it rests on.

Question	Alert-centric operations	Environment-led defense with a digital twin
Starting point	An alert, a hunt or an analyst question	A continuously modeled environment
Primary evidence	Telemetry gathered during an investigation	Topology, identity, exposures, deployed controls and validation results
Breach paths	Reconstructed while investigating suspicious activity	Projected and validated before an incident
Control assessment	What observed or responded to the activity	Whether each control interrupts the path as configured
Exposure management	Often a separate workflow	Exposure and SOC agents share the same model
Closure	Respond, remediate and document	Change the control, retest the path, verify it is closed

Guardrails

Where the AI stops

The model doesn’t decide reachability

The language model forms hypotheses, selects evidence and writes explanations. Reachability comes from the graph and Kairo. What is allowed to run comes from your policy.

Mapping touches nothing

Projecting and ranking every route to a crown jewel runs against the model, not against production.

Validation is scoped

Techniques run only inside the scope you approve, and every run records what it did and what it deliberately did not do.

Targeted context, not bulk data

Connectors query your tools in place and pull only the context a decision needs. Logs stay in your SIEM, and application and user data is not copied.

Tenant isolation

Each customer’s twin, connector credentials and agent learning stay inside that tenant.

Human approval and a full audit trail

Control changes go through your existing tools and wait for approval where your policy requires it. Every agent run is logged with its reasoning chain, tool calls, evidence and token cost.

See the twin on your own stack.

Pick a crown-jewel system and a scope. We connect the layers in order and show you the proven paths, the controls that held, and the ones that didn’t.

Request a demo →

New to the concept? Start with What is a digital twin in cybersecurity?

Blog Tag:

Breach Paths