Every program network has a front door. Software updates, firmware images, vendor deliverables, data packages, and tools all come through it. Most programs already check what comes in for known malware and known vulnerabilities.
Very few check for machine-learning models. That gap is growing. This is a practical guide for program and security teams: why hidden models show up, where to screen, what to do with a finding, and how to start in one month.
Why models show up where nobody declared them
Most hidden models are not planted by an adversary. Three common paths:
- A vendor adds a feature. A small model improves the product, and nobody thinks of it as something to disclose.
- A library brings its own. A component bundles a model because it is cheaper than calling a service.
- An update swaps the logic. A firmware update replaces a rules engine with a learned model, and the release notes say "performance improvements."
The result is the same either way. A decision-making component is now inside your boundary. Nobody evaluated what it was trained on, nobody tested how it behaves, and nobody on your team knows it is there.
The paperwork rarely helps, because the model often sits several layers below anything a manifest describes. Open the layers of the example below.
A deliberate adversary would use the same path. The tools most programs run at the front door look for known bad code, and they were never designed to look for models. We covered the background in Sentinel: Finding the AI Nobody Told You About.
What Sentinel does
Sentinel screens files for hidden models, offline, and flags indicators of possible tampering or backdoors for review.
It inspects executables, firmware, and binaries directly. It does not ask the vendor, read a manifest, or trust a label. When it finds a model, it maps what it can: architecture, likely origin, and lineage. It also flags signs of possible tampering or backdoors for a person to review.
The output is a structured forensic report: what was found, where it sits in the file, what it appears to be, and how confident the result is. Security teams can drop that into the workflows they already run, whether that is receiving inspection, an investigation, or a compliance review.
Sentinel runs fully air-gapped, with offline inference. Nothing leaves the network to be analyzed. For a program on a disconnected network, that is the only way a screening tool can work at all. More on what it can and cannot do is in Sentinel, explained.
Where to screen
The front door is the obvious place. Four specific points are worth naming.
Receiving inspection for software and firmware. Anything a vendor delivers, before it is installed. That includes updates to systems you already trust.
The transfer point onto a disconnected network. If files already pass a review before they cross into the boundary, add model screening to that same step. Your team keeps the process it runs today and gains one check.
Third-party components in your own builds. If your team or an integrator builds software for the program, screen the libraries and packages that go into it.
Model files that arrive on purpose. If the program is bringing in models it intends to use, screen those too. The question becomes whether the file contains what it claims to contain.
What to do with a finding
A finding is the start of a decision. A sensible sequence:
- Identify. Read the report. What kind of model is it, where does it sit, and how confident is the result?
- Ask the supplier. Many findings will be undeclared features. The vendor should be able to say what the model does and where it came from. If they cannot, that tells you something too.
- Decide. Accept it with a written reason, require the supplier to remove it, or reject the delivery. The decision belongs to the program and its security officer.
- Keep the record. Write down what was found, who decided, and why. The next reviewer will ask, and the next delivery from the same supplier will be easier to judge.
Run five sample deliveries through the gate below and make the call on each finding.
A finding with low confidence still deserves a person's attention. Sentinel reports confidence because detection is a spectrum, and a tool that hides its uncertainty is harder to rely on.
Be honest about the limits
No screening tool catches everything. A new architecture 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 raises the cost of attribution. Screening reduces what gets through, and it works alongside the other controls your program already runs.
A one-month plan to start screening
- Week 1: pick the scope. One intake point and one category of file, for example firmware updates from a single supplier.
- Week 2: write the rule. Decide who reads findings, who decides, and where the decision is recorded.
- Weeks 2 to 4: screen everything in scope. Log every finding and every decision, including the clean results.
- End of month: review. How many findings were undeclared features? How fast did suppliers answer? Was the decision process clear? Then widen the scope.
Add one line to your supplier agreements while you are at it: suppliers declare any ML model in what they deliver, with its purpose and origin. A finding then becomes a check on that declaration.
Related reading
Screening what enters the boundary is one part of running Super Intelligence (SI) responsibly on a controlled network. The other parts are the machine the models run on, covered in what it takes to run SI on a disconnected network, and the record of what the SI does, covered in why AI in a program office needs a record.
There is more on the Sentinel page and our defense page. If your team is working out how to screen what comes into your network, we are glad to start from the process you already have.