Your security AI shouldn’t guess which breach paths are real

By Om Moolchandani, Co-Founder, CISO and CPO, Tuskira

Every security team is now being sold AI. Most of it is built the same way. A large language model reads your alerts, your scanner output and your asset lists, and then tells you what matters.

Language models are very good at some of that work. They read messy data quickly. They explain findings in plain English. They plan the next step and write the query to get there.

There is one question they shouldn’t be trusted to answer on their own, and it’s the one that matters most. Can an attacker actually get from this weakness to something you care about, past the controls you have in place today?

A guess is not an answer

For breach paths, a guess isn’t good enough. Yet a language model answers that question the way it answers everything else. It produces the most likely-sounding response. Sometimes that response is right. Sometimes it’s a confident description of an attack path that your firewall, your EDR or your identity controls would have stopped at the first step. Sometimes it misses the path that is wide open.

For a CISO, both mistakes are expensive. A false alarm sends engineers to fix something that was never exploitable. A miss leaves a real path to a crown-jewel system open while the team works on the noise.

The wider AI field is moving the same direction. Production systems are shifting away from one general model doing everything, toward different kinds of models and methods for different jobs. Forecasting numbers, scoring records and making bounded decisions are different skills from writing text. Security is no exception.

Reasoned, predicted, proven

The useful way to look at any AI security product is to ask where each part of its answer comes from. There are three kinds.

• Reasoned. A model reads the situation, plans and explains. This is where language models shine, and it’s where they should be used.
• Predicted. A model estimates what is likely, such as which findings are probably exploitable or which assets are probably critical. Predictions are useful for sorting work. They are still estimates.
• Proven. The answer is checked against the real environment. A candidate attack path is tested against the controls actually deployed on it, to see whether they stop it.

Only the third kind should decide what your team fixes first.

How Tuskira separates the three

Tuskira uses frontier models where they are strong, to plan the work and to explain results in plain language. It doesn’t ask them to guess whether a breach path is real.

Instead, Tuskira’s Security Data Fabric builds a live digital twin of the customer’s environment from the tools they already run. Kairo, our breach path agent, works over that twin, combining deterministic path analysis, which maps every route an attacker could take to critical systems, with a neural graph that simulates which of those routes an attacker is most likely to take. Those paths are still candidates, and Tuskira treats them as such. Kairo then validates the controls on each one, so the team sees which paths are stopped today and which are not. The open paths are the ones that matter. Tuskira then closes them through the controls the customer already owns, under the customer’s own policy.

The result is a short list of breach paths that are proven to be open, not a long list of findings that might be. In one global financial-services deployment, Tuskira took 12.3 million findings down to 0.46% actionable.

The question to ask every AI security vendor

When a vendor shows you an AI that “finds what matters,” ask one thing. Which parts of this decision are reasoned, which are predicted, and which are proven?

If the answer stops at a prediction, you’re looking at a well-informed guess. If the prediction was then tested against your controls, you’re looking at evidence you can act on.

Your board won’t ask how confident the AI sounded. They’ll ask whether the path was real.

See which of your breach paths are proven open →