Security advice for consumer machines is close to universal: run a reputable resident scanner, keep it updated, let it watch everything.
On a machine that also runs competitive games, that advice collides with something. The collision is worth understanding, because the people most exposed to it — players whose accounts carry real value — are the people most likely to be told to ignore it.
They ask for the same capabilities
Consider what a resident antivirus actually requires in order to work in real time.
It needs a kernel-mode driver, because catching something before it executes means intercepting the moment of execution, and that happens below user space. It needs to inspect the memory of running processes, because a payload that only ever exists decrypted in RAM never touches the disk to be scanned. It needs to hook filesystem operations, because "scan on access" means being in the path of every access. And it needs to attach to or inject into other processes to watch what they do.
Now consider what a modern kernel-level anti-cheat is looking for.
A kernel-mode driver it does not recognise. Processes reading the memory of the game. Hooks in the path of operations the game performs. Code injected into the game process.
These are not similar lists. They are the same list. The capabilities that make a security scanner effective are, described neutrally, the capabilities that make a cheat effective — and an anti-cheat cannot infer intent from behaviour. It sees an unknown driver with memory-read access to a protected process. Whether that driver belongs to a security vendor or a cheat developer is not a question the access pattern can answer.
Anti-cheat vendors manage this with allowlists of known-good software, and the major security vendors are generally on them. But an allowlist is a curated set, and the interesting consequences live at its edges: a scanner that was never listed, a version newer than the entry, a driver signed differently after an update, a smaller vendor nobody got around to adding. The user experiences that edge as a kick, a match ban, or an account action accompanied by a message that explains nothing.
Why this shapes what security tooling should do
The naive response is to build the resident scanner anyway and work on getting allowlisted. We decided against it, and the reasoning is worth stating publicly because it constrains what we will ever ship.
A tool that protects competitive players must not become the reason those players get banned. That risk cannot be driven to zero by behaving well, because the decision is not ours — it belongs to whichever anti-cheat is running, under rules it does not publish and can change without notice. Accepting that risk on a user's behalf, in exchange for a feature, is not a trade we are willing to make for them.
So Guardian's device-security assessment runs after the fact and on demand, over what a scan already collected. It has no kernel driver, no real-time interception and no behavioural sandbox. It is explicitly a second opinion rather than a resident scanner, and we describe it that way everywhere rather than letting the wording drift toward implying more.
That is a real capability trade, not a clever workaround. A second opinion cannot stop something at the moment it executes. What it can do is run on a machine where a resident scanner is a liability, and tell you what is there.
The honesty problem with ransomware
One more constraint belongs in the same conversation, because it comes from the same instinct to overstate.
Where ransomware is concerned the responsible actions are to detect and to alert. Detection is achievable. So is telling someone clearly and early that something is wrong.
What no scanner can do is undo it. Encrypted data cannot be decrypted without the key, and a tool offering "removal" invites a user to hear something it did not say. To a person whose photographs have just become unreadable, "remove the threat" sounds like "get my photographs back." Removing the malware leaves every encrypted file exactly as encrypted as it was.
A tool that blurs that line trades a person's understanding of their own situation for a more reassuring product page. The alert should be unambiguous about what has already happened, because every decision that follows — disconnect, restore from backup, involve someone, do not pay yet — depends on understanding that the damage is done and the question now is containment.
What to take from this
If you run competitive games on the machine you also work on, the security posture that is correct for a general consumer machine is not automatically correct for yours. That is an uncomfortable thing to be told, and it is better than finding out through an account action.
Check whether your security software is recognised by the anti-cheat you play under. Prefer on-demand scanning to resident interception on that machine. And treat any tool promising real-time protection and competitive safety as owing you a clear explanation of how it manages both, because those two requirements genuinely pull in opposite directions.