What a signed-job model actually buys you over a plaintext RMM script queue

Picture the standard RMM job pipeline: a technician queues a script in the console, it lands in a job table, and an agent on the endpoint polls that table and executes whatever it finds. The authorization model for that job is, in practice, "it came from the right database row." If an attacker can write to that row — through a compromised console account, a vulnerable API, or a supply-chain foothold in the management plane itself — the agent has no independent way to tell the difference between a legitimate job and a malicious one. It executes both identically.

That is the exact failure mode a signed-job model is designed to close. Every job Nexus sends to an endpoint — a script, a patch instruction, a remote-control request — is signed with an Ed25519 key on the platform side before it leaves the platform. The agent verifies that signature locally, using a key it already holds, before it will run anything. A compromised database row is not a valid job. Neither is a job replayed from an old, legitimate one, or a job crafted by someone who breached the console but does not hold the signing key.

Why this is a supply-chain argument, not just an auth argument

• A plaintext job queue collapses "who can write to this table" and "who can execute code on every managed endpoint" into the same trust boundary — compromise one, and you have compromised the other.
• A signed-job model separates them: writing to the queue and holding the signing key are different privileges, which means a breach of the application layer (a SQL injection, a leaked admin session, a vulnerable dependency) does not automatically translate into remote code execution across the fleet.
• It also protects against a quieter threat than an outside attacker: an insider or a compromised CI/CD pipeline that can reach the job table but was never supposed to be able to push code to production endpoints.
• Signature verification happens on the endpoint, not the server that issued the job — so even if an attacker fully controls the network path between platform and agent, they cannot forge a job the agent will accept.

A plaintext script queue asks the agent to trust where a job came from. A signed job asks the agent to verify what it is — and the agent can do that math itself, offline, without trusting the network in between.

None of this replaces the other layers — a default-deny capability registry that gates which job classes are even enabled, an outbound-only agent that never exposes a listening port for someone to hand it a job directly, RBAC on who can queue a job in the first place. Signing is one layer in a stack, not a silver bullet. But it is the layer that answers the specific question "how do I know this code came from my platform and not from whoever just broke into it," and a plaintext queue cannot answer that question at all.

This is also why we think "signed" deserves to be a specific technical claim, not a marketing adjective. If a vendor tells you their platform is secure, ask them the boring, precise version of the question: is the job cryptographically signed, and does the agent verify that signature before executing, independent of the transport it arrived on? For Nexus, the honest current answer is patch deployment with ring rollout running that path end-to-end in our own practice today, with remote scripting and remote control riding the same signed-job pipeline behind the capability registry described on the platform page.