Meet Lumina Signals: the decision layer security has been missing

Security teams don’t have a detection problem. Every modern stack is catching plenty, and the alerts are mostly trustworthy. The problem is what comes next: out of everything the stack surfaced this week, which findings actually matter in this environment, given the crown jewels, the policies, and the decisions already made? That question lands on an engineer’s desk every day, and it rarely has a clean answer.

Today we’re unveiling Lumina Signals, built to close that gap. This post walks through what we built, why we built it in this order, and what it changes for the teams running it.

“Of these 4,000 findings, which ones actually matter?”

Every security team we talked to had a version of this question on their desk. And almost none had a structured way to answer it.

Detection has become the baseline. Every modern security stack now catches plenty, from cloud misconfigurations to identity drift to suspicious workload behavior, and the teams running them can mostly trust the alerts they get. The work that actually decides whether a security engineer has a good week or a bad one is the step after that, which is interpretation. Out of these 4,000 findings, which fourteen actually matter in this environment, today, given what the team knows about their crown jewels, their policies, their last pentest, and the decisions they’ve already made?

The interpretation question has shaped the last two years of work on Sola’s AI-native intelligence layer. Most of the platforms a security team can buy today help with the first half (find more findings) and quietly leave the second half (figure out which ones matter) on the security team’’s desk. So that engineer opens the same dashboard, sorts by severity, and starts the same triage they ran last week. The signals change. The work doesn’t.

Lumina Signals is the product we built to answer the interpretation question. The rest of this post walks through what that means in practice, why we put the data foundation before the AI, and what changes for a security team running it in production.

Combining Sola’s intelligence layer with your business context

Before getting to Lumina Signals itself, the layer underneath it deserves a quick walkthrough, because it shapes everything the product can do.

At the base sits a unified asset graph that maps every asset, identity, workload, and relationship across cloud, identity, SaaS, and endpoint as one connected model. On top of the graph runs classic ML, anomaly scoring, and graph reasoning, all working from verified, structured data rather than raw alert streams.

On top of that sits an organizational knowledge layer that ingests internal policies, pentest reports, Jira history, or past approval decisions, so the platform reasons about your environment, not an industry average. Most “AI-powered” security products probably skipped this part. Without a real data foundation, AI in security is a parlor trick that breaks the first time someone asks a real question.

Building the foundation in this order was an early product call. The work over the last couple of years has been getting that base solid enough to support the kind of reasoning Lumina Signals does today.

If you already use Sola, nothing about that goes away. The prompt-based experience you know (now Sola On Demand) stays put, and Lumina Signals runs alongside it as the proactive layer, every day, on questions you haven’t had time to ask yet.

With the foundation in place, the scoring layer is where the product gets interesting.

Risk scoring that moves both ways

Bi-directional scoring is the part of the product that changes the most for security engineers day to day. Severity in security has always moved in one direction, and Lumina Signals is the first place we’ve been able to change that.

Every severity score the industry uses today moves up. A CVSS 9.8 stays a 9.8 whether the affected asset is a crown-jewel database holding regulated customer data or an isolated dev sandbox no one has touched in eight months. That made sense in an earlier era, when “vulnerability” meant a CVE on a server and “context” meant the operating system version. It makes less sense now, when the same finding can be irrelevant on one asset and catastrophic on another sitting two hops away in your environment.

Lumina Signals scores severity bi-directionally. A generic 9.8 on an isolated asset can drop to a lower priority once the platform sees the asset is air-gapped, unused, and holds no sensitive data. A quiet medium on a crown-jewel system can rise to critical because the data sensitivity, identity weight, and blast radius push it there. The score reflects what the finding actually means in your environment, not what it would mean in a generic one.

Every shift comes with the reasoning shown on the signal itself, so engineers can inspect the call, challenge it, and learn from it. Severity that moves in both directions, grounded in your business context, with the reasoning visible on every call. Everything else we built leads to this.

The scoring engine matters most when it has cross-domain context to work with, which is where the asset graph earns its keep.

Four security domains, one graph: a short story

The clearest version of this is a short story most security teams will recognize.

A public S3 bucket, on its own, is a configuration finding. Tag it medium, move on. The same S3 bucket, with a Lambda function attached that has an over-permissioned IAM role, sitting in the same path as a federated SSO group with administrative scope, is a full account takeover waiting for one unauthenticated request. Same first signal, completely different business meaning.

Most platforms can’t see that chain because they live in one domain at a time. They watch the bucket, or they watch identity, or they watch workloads, and a human staring at three different consoles has to reconcile the connective tissue between domains afterward. So we built Lumina Signals to reason across cloud, identity, SaaS, and endpoint as one asset graph, with the connections between findings as a first-class output rather than something a human has to assemble after the fact.

Cross-domain context is what makes this difference real. The bucket finding doesn’t sit in a CSPM queue while the identity finding sits in an IAM tool, and while the SSO finding sits somewhere else entirely. Lumina Signals sees the chain as one thing, scores it for what it actually means in your environment, and pushes the resulting signal with the reasoning attached. Engineers get the chain, not the three separate findings.

With the scoring and the graph working together, what actually changes for the team running this in production is worth spelling out.

What changes for security teams running Lumina Signals

The shift is where the engineer’s day starts. With Lumina Signals running every day, each signal arrives as a pre-investigated package: business context, severity reasoning, blast radius, and recommended action already assembled. The team approves decisions instead of launching investigations.

The team measures the impact two ways: operational noise drops by up to 87% while time-to-context drops by roughly 50%. Both come from removing the work the engineer no longer has to do, which is the manual interpretation step we opened this post talking about. The investigations that do land on the queue are the ones that already passed the “does this matter in our environment” test.

Security leaders get something different from the same product. The board view becomes defensible because every Critical on the screen is a real exposure in your environment, not a generic 9.8 that may or may not apply. Engineers get a queue they can trust. Leaders get a story they can stand behind.

Key takeaways

• The bottleneck has moved from detection to interpretation. Most teams have all the findings they need. What they don’t have is a structured way to know which ones matter in their environment today.
• One-directional severity scoring is a holdover from a different era. A 9.8 that can’t go down is a model that ignores everything you know about your own environment. Bi-directional scoring is the catch-up move.
• When evaluating AI security products, start with the data layer. AI on top of unstructured security data is fragile. AI on top of a unified asset graph with organizational context is the part that can actually reason about your environment.