Skip to main content
All posts

Web-first vs the desktop-agent question for SMB security

July 14, 2026 · 7 min read

Ask a small-business owner to install a security agent on every laptop and you'll usually get the same reaction: a slow, wary "do I have to?" It's a fair instinct. Agents — the background software that security tools put on your devices — have a reputation for slowing machines down, breaking after updates, and quietly accumulating permissions nobody remembers granting. So the modern default has shifted: web-first, agentless wherever possible, and a desktop agent only where it genuinely earns its place.

Here's how to think about that trade-off without needing to be a security engineer.

What "web-first" actually buys you

A web-first security tool does its work through connections to the services you already use — your email provider, your file storage, your identity system — over their official APIs. Nothing gets installed on anyone's laptop. That has real advantages beyond convenience. There's no software to break, no per-device rollout, no fleet of agents to keep updated, and a much smaller footprint for an attacker to abuse. You can be covered on day one, including on devices you don't own — the contractor's laptop, the owner's personal phone — because the protection lives in the cloud services, not the hardware.

For a large share of what small businesses actually need — spotting a risky mailbox forwarding rule, catching a file shared publicly by mistake, flagging an account with no multi-factor authentication, noticing an impossible-travel login — web-first isn't a compromise. It's the right tool, and it's less fragile than the alternative.

Where a web-first view genuinely can't reach

But some questions can only be answered from the device itself. Is this specific laptop's disk actually encrypted? Is its firewall on? Is it running a screen lock and an up-to-date operating system? Is there sensitive customer data sitting in a folder on someone's desktop? APIs to cloud services can't see any of that. This is the honest limit of agentless security: device posture and local files live on the endpoint, and only something running on the endpoint can check them.

If your compliance requirements, your cyber-insurance questionnaire, or your own risk tolerance demand proof of disk encryption and endpoint hygiene, you need presence on the machine. That's the real question behind "web-first vs desktop agent" — not which is better in the abstract, but whether your specific obligations require seeing the device.

What a desktop agent should look like if you do need one

An agent isn't automatically a liability — a badly designed one is. If you're going to put software on your team's machines, hold it to a short, non-negotiable list:

  • Optional and signed. Nobody is forced to install it, and the binary is cryptographically signed so you can verify it's genuine and untampered.
  • Auto-updating. Security software that goes stale is its own vulnerability; patches should arrive without a manual rollout.
  • Read-only by default. Its normal job is to look and report — check posture, list what's there — not to change your machine. Anything that writes or modifies should be a separate, explicitly gated capability, off unless you turn it on.
  • Session-bound with a kill switch. Its access should be scoped and revocable. You should be able to see what it's doing and shut it off instantly, from one place, without touching each laptop.

An agent built like that is a scoped, revocable set of eyes for the specific checks the cloud can't do. An agent that installs broadly, runs with standing write access, and can't easily be turned off is the thing people are right to fear.

The practical answer for most SMBs

For most small businesses the sensible architecture is layered: cover everything you can from the web first, because it's faster, safer, and reaches devices you don't control — then add device-level checking only where a real requirement demands it, and only through an agent that is optional, signed, read-only by default, and killable. You end up with broad coverage immediately and deep coverage exactly where it's justified, without turning every laptop into a standing risk.

That's the posture CyberVault is built around: agentless and web-first by default, with a single optional, signed, auto-updating desktop agent — read-only unless you deliberately grant more, session-bound, and centrally revocable — for the device-posture and local-file cases that genuinely need eyes on the machine. Web-first where it works, on-device only where it must be, and nothing left standing open that doesn't need to be.