Sentinel's UI. Node Permissions, Network and CSP rules are added on a separate file called .sentinel-permissions.json to avoid exposing settings.js. All RED.* pass through sentinel's proxy and can't be monkey-patched by custom nodes or plugins anymore. This means you can now install unaudited packages without fearing exposing your data. Only admins have access to Sentinel.
Threats: all threats that Sentinel detected during startup and runtime.
In what circumstances would my Node-red installations benefit from this additional runtime security?
Who are the attackers you have protected from - my own staff / family , Internet based users of my dashboard, authorised but malicious logged-in editors?
You can install public plugins or nodes that havenât been audited without worrying about data exfiltration. Even if your Node-RED instance isnât exposed to the internet, attacks can still come from inside.
A malicious or compromised node can:
Modify the runtime
Alter other installed packages
Tamper with your flows without you noticing
Itâs even possible to reroute messages through âinvisibleâ wiresâlogic that doesnât appear in the editor or in flows.jsonâso your data could be redirected elsewhere without any visible trace.
Imagine you trusted a node or plugin and have been using it for years, with automatic updates enabled. One day, an update could introduce malicious behavior and start doing exactly the kind of things Sentinel is designed to preventâwithout any obvious indication that something has changed.
The key issue is that anyone can publish packages to npm or the Node-RED library, and they become immediately available to any instance pulling from those registries. That means youâre ultimately trusting code that hasnât necessarily been verified.
Security in Node-RED is still an afterthought in many production environments.
If youâre responsible for deploying Node-RED at scale, itâs worth asking directly: What is your actual security model for third-party nodes today?
Because by default, there isnât one.
Most Node-RED instances in production are effectively running with full trust in every installed packageâno permission boundaries, no runtime enforcement, and no visibility into what those nodes are actually doing under the hood.
Sentinel exists to close that gap:
Make capabilities explicit
Enforce them at runtime
Give operators control before and after installation
The challenge isnât the technologyâitâs awareness.
Until teams clearly understand how easily flows and nodes can be abused for data exfiltration or manipulation, security will continue to be deprioritized.
Sentinel isnât expensive when you look at the problem it solvesâit eliminates an entire class of risk. People tend to associate cybersecurity with companies, but thatâs outdated thinking. Your personal environment is just as exposed, and in many ways, less protected.
At home, youâre not just dealing with dataâyouâre dealing with identity, location, habits, and access to everything you own digitally. If that gets compromised, the impact isnât a âbusiness lossââitâs your personal safety, your privacy, and your control over your own life. Thatâs a much harder thing to recover from.
The real question isnât the priceâitâs the cost of not having that protection in place. Sentinel positions itself as a safeguard layer where most people currently have none.
