There is a class of software risk that most security tools are not built to see: the AI model you did not know was there.
Vulnerability scanners look for known bad code. Dependency tools read the manifests that vendors choose to publish. Neither was designed to answer a different question: is there a machine-learning model inside this binary, and if so, what is it? Sentinel is built to answer that question on software you did not write, with no source code and no help from the vendor.
This piece covers what Sentinel looks at, what it reports, where its limits are, and what to ask of any tool in this category.
Detection without asking the software
Sentinel does not trust the thing it is inspecting. It does not read a label, query an API, or take a manifest's word for what a program contains. It inspects the file itself.
That matters because the manifest describes the outside of a delivery, and an undeclared model usually sits further in. Open the layers of this example to see the gap.
Sentinel inspects compiled software, firmware images, mobile apps, and container images, as well as model files that arrive on purpose. That last case answers a different question: does this model file contain what the supplier says it contains?
Sentinel runs fully air-gapped, with offline inference. That is a requirement, because the places where an undeclared model is least acceptable are controlled networks, disconnected industrial systems, and defense supply chains. In those places you cannot send a sample to someone else's cloud to be analyzed. A detection tool that only works online does not work where this problem matters most.
Detection is the start. Attribution is the useful part.
Finding that a model exists is the first half. The second half is saying something useful about what you found.
A tool that reports "something model-shaped is in here" starts an investigation. A report that maps the model's likely origin, size, architecture, and lineage lets a team make a decision. For each finding, Sentinel reports:
- What was detected, such as a model, an inference runtime, or both
- Where it sits in the file
- What it appears to be, with its likely origin and lineage where they can be mapped
- How confident the result is
- Signs of possible tampering or backdoors, flagged for a person to review
Sentinel can also export an AI bill of materials in the CycloneDX format and findings in SARIF, formats many security teams already work with. The report is meant to drop into the work you already do: receiving inspection, an incident review, a compliance check.
Run the sample deliveries below and read what the report gives a security officer to act on.
Attribution is what turns detection into governance. You cannot write a policy about models you can only count. You can write one about models you can identify.
What it can and cannot do
Credibility in this field comes from being honest about the edges, so here are ours.
- Novel architectures are harder. A model built in a way that matches nothing known is harder to characterize, though it can still be flagged as model-like for a person to inspect.
- Heavy custom obfuscation costs more. It raises the effort needed to attribute what was found.
- Confidence is a spectrum. Sentinel reports confidence instead of claiming certainty it does not have. A low-confidence finding still deserves a person's attention.
- It is one control. Screening reduces what gets through. It works alongside your malware scanning, vulnerability management, and supplier reviews.
What to ask any hidden-model detection tool
If you are evaluating tools in this category, including ours, these questions separate a useful tool from a demo:
- Does it run fully offline? If it needs to send samples out, it cannot be used on a disconnected network.
- Does it inspect the file, or read the manifest? A tool that trusts declarations will miss undeclared models.
- What file types does it cover? Executables, firmware, mobile apps, containers, and model files are different problems.
- What does a finding contain? Look for location, likely origin, and a confidence level, not just a yes or no.
- Does it report its uncertainty? Ask what happens on a low-confidence result.
- Does the output fit your workflow? Check the export formats against the tools your security team already runs.
- What does the vendor say it cannot do? A vendor with no stated limits has not tested its own tool hard enough.
Why this matters now
The software industry spent a decade learning to ask "what code is in this?" The software bill of materials, the dependency audit, and the vulnerability scanner are all answers to that question. None of them answers the question that now matters as much: what AI is in this?
That gap widens as models get cheaper to embed and easier to hide. For a practical, step-by-step version for program teams, read screening what enters the boundary. For the background, read Sentinel: Finding the AI Nobody Told You About.
There is more on the Sentinel page. If you are deciding how to screen what comes into your network, we are glad to start with your intake process and the file types you see most.