A Finding Is a Fact. Exposure Is a Relationship.

Ask three of your security tools about the same server and you can get three different names for it.

The scanner knows it by hostname. The cloud console knows it by instance ID. The endpoint agent knows it by its own device ID. The CMDB says one team owns it. The fix for the critical vulnerability on it turns out to live in a base image that a different team owns.

Every one of those tools is telling the truth from where it stands. None of them can tell you whether that vulnerability matters.

That question is not really about the finding. It is about everything around it: what can reach the server, what the server can reach, which identities run on it and what they can get to, who can actually change it, and whether any of that has changed since the scan.

A finding is a fact. An exposure is a relationship.

The easy version of this argument

You have probably seen the standard example. The same CVE sits on two systems. One is internal, isolated and connected to nothing sensitive. The other is internet-facing, runs under a service account with broad permissions, and sits one step from a privileged cloud role. Same finding, very different exposure.

It is true, and good tools already combine signals like these inside their own view. A cloud security tool can tell you a workload is public and has a risky role attached. A scanner can tell you the vulnerability is being exploited in the wild.

The hard part starts where one tool's view ends. The path from that internet-facing service to the cloud role might run through an identity your identity provider knows about, a role your cloud console knows about, and a trust relationship neither of them owns. No single tool holds the whole relationship, so no single tool can answer the question.

Collection is not context

The usual response is to collect more. Pull in scanner data, cloud data, identity data, tickets and ownership, put it all in one place, and call it context.

Before Unizo, we spent years building application security products, and we ran into this wall again and again. The findings were never in short supply. There were far more than anyone could work through. What we lacked was everything the findings could not tell us. Who owned the fix? Ticket history and commit history were supposed to answer that, and mostly did not. Was it even worth fixing? Without knowing whether the vulnerable code was reachable, often we could not say. We tried to stitch static analysis, dependency scanning and dynamic testing together so each could check the others. It stayed a goal we never fully reached.

The same wall stands wherever findings come from: infrastructure, cloud, identity. The lesson that stuck with me is that getting the data was rarely the hard part. Getting the tools to agree on what the data described was.

That work is unglamorous. It means recognizing that two tools describe the same asset under different names. Separating assets that are running from ones that only exist in a stale inventory. Settling who owns a system when three sources disagree, and knowing that the owner of the asset is often not the owner of the fix. Connecting code to what is actually deployed. Knowing that an identity in one system can assume a role in another.

Without that, a central store is just more raw material. With it, you have something you can reason over. Context is the resolved state of the environment.

Exposures have lifetimes

Resolve the environment and something else becomes possible. You can treat an exposure as an object you track, with a beginning, an end and evidence for both.

A finding is a moment: one tool saw something at one time. An exposure is a condition that holds across systems. It opens when the relationships line up: the vulnerable version is running, something can reach it, and an identity on it can get somewhere that matters. It closes when the environment changes so that one of those is no longer true. And if a redeploy brings the old image back, the exposure should come back with it, on its own, and go straight back to the owner with the evidence.

That is a different thing from a prioritized finding, and it changes the questions a team asks: which exposures still exist after their tickets closed, and who owns the change that actually breaks the path.

It also raises a question most programs never get to ask: who decides what counts as an exposure in the first place? Today that decision usually arrives inside a vendor's scoring model. I think it belongs to the team that owns the risk. Nobody wants to hand-author every path. But the defaults should be visible, and which paths matter, to which systems, under which conditions, should be yours to question and override.

Why this matters more now

For years, getting context wrong cost you time. The wrong finding got fixed first, a sprint went to the wrong place, and the real path stayed open a little longer.

That is changing. AI agents are moving from summarizing findings to drafting the fixes, raising the tickets and, more and more, making the changes. An agent that acts on incomplete context is no longer a productivity problem. It is a change-management problem with your name on it.

In an earlier Field Note we called this failure mode improvised context: an agent assembling its picture of your environment on the spot, from whatever its tool calls return, in the seconds before it reasons. The reasoning can be excellent. What it stands on is partial by construction and stale as soon as it is built.

An AI agent should not be discovering your environment while it decides what to do in it. It should reason over a model of the environment that is already resolved and current, with evidence for every relationship it relies on and clear limits on what it is allowed to change. The more autonomy you hand an agent, the less that model is a nice-to-have and the more it is the precondition.

A word on "current," because it gets used loosely. It does not have to mean instant. It means every conclusion is re-evaluated when the facts underneath it change: a new version deployed, a security group opened, a role granted. A conclusion that was true on Monday can be false by Thursday. If your model does not notice, every decision after Monday is made against yesterday's environment.

Try this on Monday

Here is a test you can run without buying anything.

Take your five most recent critical findings. For each one, try to answer five questions with evidence, not a best guess:

Time it. Then count how many answers needed a second tool, a spreadsheet, a Slack thread, or the one person who just knows.

That count is the size of your context gap.

The hard part

Finding issues stopped being the hard part years ago. Most enterprises have more findings than they will ever work through. Knowing what those findings mean, in this environment, right now, is the hard part. It is the gap we started Unizo to close.

A finding is a fact. An exposure is a relationship. Build on the facts alone, and AI will just help you fix the wrong things faster.

Praveen Kumar, Co-founder & CEO, Unizo