The monitoring agent that cannot be told what to do

#security #webdev #architecture #devops

Here is a design decision we made early, wrote into the architecture as an invariant, and have refused to revisit since: our agent accepts no commands. Not "we don't currently use that feature" — the hub has no way to tell an installed agent to do anything at all. No remote execution, no self-update, no "collect this for us right now". It sends data outward, and that is the entire surface.

This is not a limitation we are working around. It is the product. And it costs us features that customers ask for, which is exactly why it is worth explaining.

The uncomfortable arithmetic of remote control

Any tool that can update a plugin across fifty client sites is, by construction, a tool that can execute code on fifty client sites. Any dashboard that can restart a service on your server holds, somewhere, a credential that lets it in. This is not a flaw in those products — it is what they are for. You cannot automate a repair without the power to perform it.

But that power has an owner, and the owner has a login, and the login has a support team, and somewhere in that chain there is a version of the software with a bug in it. When the tool is compromised, the blast radius is not the tool. It is every machine the tool could reach.

The industry has already run this experiment at scale. In July 2021, attackers exploited a vulnerability in a widely used remote monitoring and management platform. They did not break into a single company — they broke into the thing that had access to the companies. Roughly sixty managed service providers were hit, and through them, an estimated 800 to 1,500 downstream businesses were encrypted in a single weekend, with a $70 million ransom demand attached.

Read that shape again, because it is the whole argument: the victims did nothing wrong. They had bought a well-known product from a serious vendor and installed it exactly as instructed. Their compromise arrived through the door they had deliberately, sensibly, contractually left open — the one that let their provider help them.

A tool with remote control over a thousand servers is not a convenience with a security caveat. It is a single door to a thousand servers, and everything else about it is a detail.

What we decided instead

We asked a narrower question than most monitoring vendors do. Not "what could we do for the customer if we had access?" — the answer to that is always "more" — but "what is the least access that still lets us tell the truth about whether their sites work?"

The answer turned out to be: none at all, in the inbound direction.

The host agent is one-way. It opens an outbound connection, streams metrics, and hangs up. There is no command channel. The message types for remote instructions exist in our protocol as dead code from an early draft — frozen, never sent, ignored by the agent — and we left them in only because removing them would break protocol compatibility for no gain.
The WordPress plugin has no inbound endpoints. It registers no REST routes and no AJAX handlers. It gathers diagnostics — core version, plugin state, whether the order pipeline is alive, whether mail is actually leaving — and posts them out. There is no URL on your site that our servers can call.
Updating the agent is your action, not ours. No self-update, no silent replacement. If a new version ships, we can tell you your agent is old — a log line, a badge in the dashboard — and that is where our involvement ends. You reinstall it, verifying the checksum, on your schedule.

The security property that falls out of this is simple enough to state in one sentence, which is the point: if our servers are compromised tomorrow, an attacker still cannot reach your machine through us. There is no path. Not a locked one, not a well-audited one — no path.

What this costs — and we will not pretend otherwise

A monitor that cannot act is a monitor that cannot save you at 3 a.m. We do not do any of this, and we will not:

These are genuinely useful. If you need them, use a maintenance platform that provides them — and be clear-eyed that you are trading a real amount of exposure for a real amount of convenience. That trade is legitimate. It is simply not the trade we make on your behalf without telling you.

What we do instead is the half that does not require the door: watch the site from outside from several regions at once, watch the business paths from inside the CMS — does the checkout still accept an order, does the contact form still deliver mail to the inbox, is the certificate about to expire, is the domain quietly running out — and tell you the moment any of it stops being true. The failures that matter most are silent ones, and none of them require us to hold a key to your server.

The part that is really about trust

Agencies are the ones who feel this most sharply, because they are not making the decision for themselves. When you install a tool on a client's server, you have quietly extended that client's trust to a third party they have never heard of and cannot audit. If it goes wrong, "the vendor had a vulnerability" is not a sentence that survives contact with the client.

So the honest version of our pitch is not that we are more secure than the alternatives. It is that we removed the category of risk instead of managing it. There is nothing to audit in our access model, because there is no access. That is a smaller promise than "we will keep your servers safe" — and it is one we can actually keep, on our worst day.

Questions people actually ask

Can Pingvera fix a problem it finds?

No, and it never will. We tell you; you fix it. That is the whole contract, and it is what makes the security property above possible.

Isn't a plugin inside WordPress the same kind of access?

Only if it listens. Ours does not: no REST routes, no AJAX endpoints, no inbound path from us to your site. It collects and posts outward. A compromise of our side cannot become a compromise of yours.

What if I want the automation?

Then take it — from a maintenance platform built for it — and let an independent monitor verify the result afterwards. One tool changes the system; the other checks that the change did not quietly break the checkout. Those are two different jobs, and there is a good argument for not handing both to the same vendor.

Originally published at pingvera.com.