An ONNX model that uses custom operators needs extra native code to run, usually a shared library loaded by ONNX Runtime. The model file alone is data, but the library is a program. If a vendor sends you both, review the library like any native dependency before you load it.
What a custom operator is
ONNX Runtime documents custom operators as operators that are not official ONNX operators. They are different from contrib ops, which are selected unofficial operators built directly into the runtime. A custom operator is something you or a third party writes and registers.
The documentation shows custom operators written in C++ as functions or structs. It also describes packaging them: custom operators can live in a separate shared library, a dll on Windows or an so on Linux, which must export and implement a function called RegisterCustomOps. That function adds the library's operators to the session options.
So the path is: the model graph names an operator, your application loads a library, and that library supplies the code for the operator. The library runs inside your process with the same access your application has.
Why this matters for intake
Most model intake checks look at the model file. Reviewers ask about format, license, hash and origin. A custom operator library is not a model file. It is compiled native code, and it is easy to miss because it arrives in a different folder or as a separate download.
This is an inference from how shared libraries work, not a claim about any incident: loading a native library from a third party gives that library the ability to do whatever your process can do. The ONNX Runtime page documents how to build and register such libraries. It does not say they are sandboxed, and nothing on the page suggests they are.
What to ask the model supplier
| Question | Why it matters |
|---|---|
| Does the model use any custom operators | If no, the runtime's built in operators are enough |
| If yes, where is the source code | You may need to build it yourself |
| Which platforms and runtime versions does it support | Compatibility and patching |
| Who signs and publishes the library | Provenance of native code |
| How will updates be delivered | A library update is a code update |
A short intake rule
- Check the model for operator domains that are not the standard ones. Tooling for inspecting an ONNX graph can list the operator domains it uses.
- If only standard operators appear, treat the model like other data files, with hash, license and origin checks.
- If a custom domain appears, treat the library as a native dependency. Build from source where you can, record the hash, scan its third party components, and run it in a container with no network and a minimal file system.
- Record the library in your inventory next to the model, so removal and updates are tracked together.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a dependency inventory lists components, which is where a native library belongs.
Safeguard's SBOM and dependency scanning can list the libraries and packages your project declares, so a native component can be tracked and reviewed through policy gates. Start with the free scan.
Quick check
Is an ONNX file with only standard operators the same risk as a custom operator library?
No. Standard operators come from the runtime. A custom library is separate native code that you load.
Does the ONNX Runtime page say custom operator libraries are sandboxed?
No. The page describes how to write and register them and does not describe a sandbox.
Sources
Last reviewed: 19 October 2026.
