The gap
You already own tools that decide things about software every day. The question is not whether they work. It is what they can see.
What you already have
Every one of them answers a different question.
Almost every organisation running Windows endpoints has three things, whatever they are called in your stack: something watching for malicious behaviour, something controlling network traffic, and some way of governing what gets installed. Larger organisations add privilege management, a software catalog, and Microsoft Store and app install restrictions on top.
Each of those answers its own question, and answers it well.
Not one of them was built to answer a different question:what is this file, who made it, and what category does it belong to. So each one substitutes something adjacent and correlated, because it has to decide something and that is the nearest fact available.
The substitutions are reasonable. They are also substitutions, and each leaks at a different edge.
Five controls, five proxies, one missing fact
Not one is failing at its own job.
Each of these products answers its own question well. None of them was built to answer what is this file, who made it, what category does it belong to, so each substitutes something adjacent and correlated. The proxies are reasonable. They are also proxies, and each leaks at a different edge.
| control | decides on | not designed to answer |
|---|---|---|
| CASB | web domain and category | the binary on diskDesigned around traffic. A file that arrives once and runs locally is outside the question it asks. |
| Microsoft Store and app install restrictions | distribution channel | anything from any other channelClosing a channel closes that channel. A direct download needs no channel permission. |
| PAM | elevation rights | installs that never request elevationOperates on the elevation boundary. A user-scope install presents nothing to gate: that is the boundary working as designed. |
| EDR | runtime behaviour | identity, and only once something runsBuilt to answer what a process did, not what a file is before it does anything. |
| Allow / block lists | human curation | scaleAccurate exactly as far as someone has curated it, which makes coverage a staffing question rather than a tooling one. |
Read the third column together and the shape becomes obvious: five controls improvising around the same absent input. Not one of them is failing at its own job. The job nobody has is identification.
The endpoint in the register runs CrowdStrike, BeyondTrust, Zscaler, Tanium, Qualys, Splunk and Intune. They are all in the inventory, listed alongside the twenty-three items none of them enumerated. That is not a failure of any of them: it is what happens when five controls each answer a different question and none of them answers this one.
Software that never asks for permission
The elevation boundary works. Nothing approaches it.
Tools like pinokio, Ollama and LM Studio install under the user profile. No elevation is requested, so privilege management, the most expensive control in the stack, has nothing to gate. This is not a bypass or a defect. It is the elevation boundary working exactly as designed, applied to software that never approaches it.
The class is not only AI tooling, and treating it that way is how organisations end up with a blocklist instead of an answer. RustDesk is unattended remote access distributed as a single portable executable: no installer, no elevation, nothing to intercept.ngrok and cloudflared open inbound tunnels from a binary sitting in a downloads folder.
Editor extensions are the same problem with less ownership. An extension that ships its own language server or compiler front end puts an executable on disk that no inventory tool enumerates, because it is not an installed program and never claimed to be. Application security teams say plainly that nobody is managing this.
Why catalogs run out
A catalog can only recognise what was curated into it.
Software catalogs are real, mature products, and within their coverage they are good. The coverage is the constraint: a curated catalog can only recognise what has been curated into it. Internal applications, contractor deliverables, build artifacts, renamed portable tools and the long tail of open-source utilities are not in it and will not be.
Stated precisely: catalog-based categorization fails on anything not in the catalog. Categorization derived from the file itself has no catalog to fall out of.
That difference has an honest cost, and it is worth naming. Deriving identity from content sometimes produces certainty and sometimes produces a best guess. Both are useful; conflating them is not. Confidence is reported as a graded value rather than a yes or no, because a best-guess attribution that admits it is a best guess is worth more than one that does not.
The same gap, off the endpoint
The question is not confined to software somebody installed.
The question is not confined to software somebody installed.
Connect a cloud storage tenant and the same categorization runs across what is in it. Not the filename, not the folder it was filed under: what the document actually is.Q3-final-v2.xlsx tells you nothing. The contents can tell you whether it is a newsletter draft, an invoice, or an export of a customer list that should never have left a database.
Worth being precise about what that is and is not. The categorization is derived from the file itself, which makes it a judgement with a confidence attached rather than a lookup with a correct answer waiting at the end of it. It is reported that way, graded, exactly as attribution is on an endpoint. A confident categorization and a best guess are different things and the report does not blur them.
This is also not what a cloud access security broker is for. CASBs are primarily web-oriented, and they lack a clear mapping between the applications installed on an endpoint and the URL traffic those applications generate. That is a statement about what they were designed around, not a shortcoming: the question a broker answers is about traffic, and the question here is about the thing generating it.
What an application talks to
We derive these associations. We do not look them up.
Knowing which application is on a machine, and knowing which network destinations that application reaches, are two halves of one question. Most stacks keep the halves in different products that never join up, so the endpoint team knows the software and the network team knows the traffic and nobody owns the sentence connecting them.
We derive associations between an application and the destinations it is likely to reach.
Derive is doing real work in that sentence, and it is meant to. This is inference from what is known about the software. It is not a lookup in an authoritative registry of application endpoints, because no such registry exists to consult. An inferred association is a lead worth checking. It is not a fact, it will sometimes be wrong, and a page that presented it as a finished answer would be describing a product nobody has built.
We would rather say that plainly than have it discovered. This page is written for people who test claims, and a single overstated sentence would fairly put every honest one next to it in doubt.
A layer, not a product category
None of this argues for replacing anything.
None of this argues for replacing anything. Identification is not enforcement, and the systems already deployed are the right place for enforcement to happen: they hold the policy, the workflow and the audit trail.
What is missing sits underneath all of them: a supply of the fact each one is currently approximating. Feed it in, and the existing investment starts working on better inputs.
More of this
New posts on what a file tells you before you run it: headers, signatures, manifests, overlays, the fields most inventory never reads. Only when there is something worth the write-up.
We intend to offer a tool that does this across every file on an endpoint. You get one message when you can use it.