Security Considerations#
This page collects TensorRT security guidance that appears across the documentation. Use it as a single entry point for trust boundaries, engine handling, and production deployment patterns.
Engine Deserialization and the Trust Boundary#
Caution
Serialized TensorRT engines are executable artifacts. Deserializing an engine from an untrusted source is equivalent to running untrusted native code on the GPU and host.
The canonical guidance lives in Engine Deserialization and the Trust Boundary in How TensorRT Works. In summary:
Deserialize only engines you built yourself, or engines received over a trusted, authenticated channel.
Never deserialize engines from third parties, the public internet, user uploads, or any source you do not control end-to-end.
For multi-tenant deployments, build engines on a trusted host and ship serialized plans over a signed, integrity-checked transport.
Note
IRuntime::getEngineValidity is not a tamper-detection mechanism. In TensorRT 11.4.0 it can report EngineValidity::kVALID for engine data that was modified after serialization, so a tampered or truncated plan can pass the check. Enforce integrity with the signed transport described above rather than with this API. Refer to Known Issues in the TensorRT 11.4.0 Release Notes.
Plugin Trust#
Custom plugins extend the TensorRT execution graph with native code. Treat plugin libraries with the same care as application binaries:
Load only plugin libraries you built or received from a trusted vendor channel.
Register plugins through the documented
IPluginRegistry/trt.get_plugin_registry()paths in Adding Custom Layers Using the C++ API and Plugin API Description.When migrating from
IPluginV2toIPluginV3, review Known Migration Issues for creator and serialization pitfalls that can affect build stability.
Plugin migration sample code and Explorer entries are documented in Sample Support Guide and Sample Explorer.
Production and Multi-Tenant Deployment#
Beyond engine trust, production deployments should account for:
CUDA error isolation: asynchronous GPU errors can surface in a different execution context than the one that triggered them. Refer to Cross-Context CUDA Error Isolation for the throughput-versus-fault-isolation tradeoff (including CUDA MPS guidance in Optimizing TensorRT Performance).
Memory bounds: refer to Bounding TensorRT Memory in Production when colocating TensorRT with other GPU workloads.
Runtime package choice: Runtime Options compares Full, Lean, and Dispatch footprints for compatibility, size, and performance.