Doing any interactive external observation would put a lie to the claim that "all data & traces will get wiped" — since there would then be "traces" (in the sense of "trace evidence" — https://en.wikipedia.org/wiki/Locard%27s_exchange_principle) left on the sysadmin-observer's workstation, that would have to be wiped in turn. (And which are unlikely to be, because the sysadmin is likely also the developer, and a DevOps workstation is usually persistent.)
For that claim to actually be true, the system has to be hermetically sealed against outside observation by any other than the user themselves. (Compare/contrast: the claims of a few VPN service providers, that their service is implemented effectively statelessly, in diskless + memory-constrained ASICs on network switches, such that there's no ability even in theory for the machine itself to keep metrics on which user accounts are responsible for which kinds of upstream traffic flows; such that a state actor who wanted to know that would be stuck either replacing the hardware [and so extracting the credential store out of the TPM of the original hardware] or MITMing both sides of the VPN box and doing traffic analysis to match flows.)
IMHO, it's probably very unlikely that the claim is true — but it's interesting and fun to try to threat-model a service that does try to make that guarantee.
Also, separately:
> In theory its relatively straightforward to develop a "1 human per process" heuristic for a service like this
You're forgetting that these accounts aren't strictly intended for use by humans, but rather scripting the system is an accepted (and encouraged!) use-case. Which means that you can't differentiate one user "botting" N accounts, running the same script (presumably bannable); from N users each "botting" their own single account by using the same popular open-source script (perfectly legitimate and protected!)
This, by the way, is the reason that most VPS providers outright ban the deployment of certain types of software, e.g. IRC bouncer bots: it's impossible to tell whether N deployments of such a bot are N users intentionally deploying the same open-source bot, or one user (with N stolen user credentials) deploying a botnet that uses IRC for command-and-control. So they just make the assumption that such deployments are always malicious, and refuse the business of anyone who has a non-malicious use-case for such deployments.
For that claim to actually be true, the system has to be hermetically sealed against outside observation by any other than the user themselves. (Compare/contrast: the claims of a few VPN service providers, that their service is implemented effectively statelessly, in diskless + memory-constrained ASICs on network switches, such that there's no ability even in theory for the machine itself to keep metrics on which user accounts are responsible for which kinds of upstream traffic flows; such that a state actor who wanted to know that would be stuck either replacing the hardware [and so extracting the credential store out of the TPM of the original hardware] or MITMing both sides of the VPN box and doing traffic analysis to match flows.)
IMHO, it's probably very unlikely that the claim is true — but it's interesting and fun to try to threat-model a service that does try to make that guarantee.
Also, separately:
> In theory its relatively straightforward to develop a "1 human per process" heuristic for a service like this
You're forgetting that these accounts aren't strictly intended for use by humans, but rather scripting the system is an accepted (and encouraged!) use-case. Which means that you can't differentiate one user "botting" N accounts, running the same script (presumably bannable); from N users each "botting" their own single account by using the same popular open-source script (perfectly legitimate and protected!)
This, by the way, is the reason that most VPS providers outright ban the deployment of certain types of software, e.g. IRC bouncer bots: it's impossible to tell whether N deployments of such a bot are N users intentionally deploying the same open-source bot, or one user (with N stolen user credentials) deploying a botnet that uses IRC for command-and-control. So they just make the assumption that such deployments are always malicious, and refuse the business of anyone who has a non-malicious use-case for such deployments.