Here is a question most organizations cannot answer: how many AI models are running inside your software right now?
We do not mean the ones you bought on purpose. We mean the ones that arrived quietly: embedded in a vendor's binary, compiled into a firmware update, or tucked inside a third-party component four dependencies deep. Nobody declared them. Nobody evaluated them. In most organizations, nobody can even count them.
That is the problem Sentinel exists to solve.
How undeclared AI happens
Almost never through malice, at least at first.
- A vendor adds a small model to improve a feature and does not think of it as something to disclose.
- A component library bundles inference because it is cheaper than calling a service.
- An update swaps a rules engine for a learned model, and the changelog says "performance improvements."
Multiply that across a modern software supply chain and you get an inventory problem. Models make decisions. Each one carries training data you did not vet, behavior you did not test, and failure modes nobody in your building has looked at. In a regulated or controlled environment, an undeclared decision-maker inside your systems is a finding.
The paperwork does not help much, because the model usually sits below anything the manifest describes. Open the layers of this example update.
Supply chains are also where a deliberate adversary would put one. A model hidden in compiled software does not show up in a scan built to look for known vulnerable code. The tools the industry built for vulnerable code were never designed to see models.
Detection as a forensic discipline
Sentinel works where there is no source code, no documentation, and no vendor on the phone.
That constraint shaped the whole approach. Sentinel does not ask software what it contains. It inspects executables, firmware, and binaries directly. When it finds a model, it maps what it can about origin, size, architecture, and lineage. It flags signs of possible tampering or backdoors for a person to review. It runs fully air-gapped, with offline inference, so nothing leaves your network to be analyzed.
The output matters as much as the detection. A tool that says "something model-shaped is in here" creates work. A report that says what was found, where it sits, what it appears to be, and how confident the result is lets a team make a decision. Try it on five sample deliveries.
Start with the question
You cannot govern what you cannot see. Most AI governance programs start one step too late: they govern the models the organization knows about. The inventory of what is actually running comes first, and for software you did not write yourself, that inventory needs detection.
Three things you can do this quarter, with or without Sentinel:
- Ask your suppliers. Add one question to your next renewal: does this product contain any ML model, and if so, what does it do and where did it come from? Keep the answers.
- Pick one intake point. Firmware updates from one supplier, or the transfer point onto a controlled network. Decide who reviews what comes through it.
- Write down the decision rule. If an undeclared model turns up, who decides whether to accept it, ask for removal, or reject the delivery? Name the person before you need them.
For a step-by-step version written for program teams, read screening what enters the boundary. For how Sentinel works and where its limits are, read Sentinel, explained.
Next in this series: once you can see what is running, how do you show what it did afterward? That is Anchor'd.
There is more on the Sentinel page. If your organization runs software it did not build, and every organization does, we are glad to start from the intake process you already have.