Your RMM is the keys to every client. We built it like one.
An RMM can run code as SYSTEM on every machine you manage, which makes it the most valuable target in your stack. Warp is designed around one rule: an endpoint only runs what it can cryptographically verify.
Defence in depth, explained without the hand-waving.
Nothing listens on the internet
- Agents connect out over a single encrypted WebSocket and ping every 30 seconds.
- The server sits behind an outbound tunnel: the app and web server bind to loopback and the firewall allows no inbound web traffic.
- Agent and console live on separate hostnames; each one's paths are refused on the other.
Signed, scoped and short-lived
- Every job is signed with ECDSA P-256 over the job id, interpreter, SHA-256 of the body and an expiry.
- Agents verify against a public key pinned at install, and the key format is HSM-portable.
- Interpreter and job type are bound together, so a script signature cannot be reused for anything else.
Four eyes, enforced by maths
- Scripts flagged for approval are created unsigned.
- Only a different admin's approval produces the signature.
- Runs against more than 50 devices need an admin.
A job runs once, ever
- Signed expiry on every job.
- A persistent ledger of executed jobs on each agent.
- Redelivery is idempotent, and a refusal strictly means verification failed.
Isolation in the database, not the code
- Postgres row-level security on every partner-scoped table.
- Scope is set per transaction and fails closed: no scope, no rows.
- Every console request runs in exactly one MSP's scope, platform staff included.
Strong identity, least privilege
- Microsoft 365 sign-in with PKCE, tokens verified against Microsoft's keys.
- MFA required and read from the access token itself.
- Server-side sessions, 60 minutes idle and 12 hours max. Per-area permissions, and nobody can grant above their own level.
Keys you can write but not read
- Integration API keys are sealed at rest.
- Once saved, a key is never shown again, only tested, replaced or removed.
- Each integration validates hosts against an allow-list before calling out.
Everything leaves a trail
- Append-only audit log for sign-ins, approvals, runs, terminal sessions and downloads.
- Terminal transcripts saved with the session.
- Collected files are hashed with SHA-256 on arrival.
Updates you can trust
- Agent releases are signed at upload and re-verified before rollout.
- Rings: pilot, broad, everyone. At most 10 updates in flight.
- Every new build self-tests and automatically rolls back if it does not confirm.
What the agent checks before it runs a single line.
Altered in transit? Refused. Signed for a different interpreter? Refused. Expired? Refused. Seen before? Refused. Only then does it run.
job 4c1e… script.run interpreter=powershell signing input job_id ‖ interp ‖ sha256(body) ‖ expires_at ✓ body hash matches ✓ ECDSA P-256 signature valid for pinned key ✓ interpreter bound to job type ✓ not expired (expires in 14 m) ✓ not in executed-jobs ledger → executing job 9a07… tampered body ✗ refused: verification failed
Every release runs the gauntlet.
290+ end-to-end checks
Run against the live service on every deploy: every role, a second MSP to prove isolation, CSRF, approvals, and the agent protocol played out in full.
Attacks in the test suite
Wrong keys, replayed nonces, tampered bodies and expiries are all sent deliberately, and must all be refused.
Independent verifier
Job signatures are re-checked by a separate verifier using the agent's own procedure, so the signer can't grade its own homework.
Want the full threat model?
We are happy to walk your security team through the architecture, the controls and the risks we chose to accept.