The homepage is about the person. This page is about the mechanism.
Guardian has two layers. The first decides whether a remote connection is allowed to exist at all. The second watches what happens inside the ones that are.
Antivirus asks whether a file is dangerous. Guardian asks whether anyone actually approved this.
Scammers get people to install real remote-support tools. The file isn't malware, so a virus scan stays quiet. The problem is the person on the other end, and whether anybody agreed to let them in.
| Traditional protection | Guardian |
|---|---|
| “Is this file malicious?” | “Did anyone approve this connection?” |
| Malware, ransomware, viruses | Unapproved remote access, and what happens after it's approved |
| Decides on its own, silently | A named person decides, on purpose |
| Keep it installed | Use alongside Guardian |
The threat model
In a remote-support scam the attacker ends up holding two things at the same time: control of the machine, and the attention of the person using it. Almost every consumer security control assumes at most one of those. A prompt on the screen fails because they have the screen. A warning the user must heed fails because they have the user.
So the only durable control is one whose approval step sits outside both. That is the single idea the rest of this page is built on.
Layer one: nothing connects without an approval
Guardian's default answer to a new remote connection is no. A session is held, not established, until an approval arrives. The approval comes from whoever holds the Guardian account the PC is linked to, which gives two cases:
- Someone else holds the account. Guardian emails the account holder a request carrying the address, the remote tool, and the time, and shows the same request in the dashboard. They allow that one connection, whitelist the address, or refuse. The attacker holds the victim's machine and the victim's attention; neither gives any route to a different person. This case is outside the attacker's reach by construction, and it is what Guardian is built for.
- You hold the account for your own PC. The same request reaches you by email and in the dashboard, and you answer it there. This case has one limit that no design removes: the approver is the person the caller is speaking to.
Both fail closed. An unanswered request ends the same way as a refused one: the session is dropped before control changes hands.
Why approving for yourself is the weaker case
Two properties bound it, and both are worth stating rather than letting the choice of who holds the account quietly decide whether the product's central claim is true.
Email is delivered to an account, not to a device. If the approving mailbox is signed in on the protected PC — a webmail tab, a desktop client, a saved session — then an attacker with control of that PC can read the approval request and action it directly, with no social engineering at all. The dashboard has the same property if the browser there holds a live session. Self-approval is therefore sound in proportion to how separated the mailbox is from the protected machine: a second person's is separated by construction, the owner's by habit.
The approver is the person on the call. Where the protected PC belongs to the person being telephoned, self-approval routes the decision to the one participant the attacker is actively working on. Answering on a second device raises the cost — the request renders on a surface the attacker cannot steer, showing the address and the tool — but it does not make the owner a different person.
A second person is a lock, because there is no conversation in which they take part.
Why approval lives in the account
If approval could be given from the PC itself, it would be worth nothing the moment somebody was controlling that PC. So approvals go to the account holder, and the whitelist and the Blocked IPs list are account state on this site, not local state on the machine.
Repeated failures are terminal
Guardian counts dropped connections per address. Five failures move that address to Blocked IPs, where it is refused without generating another prompt or another email. The list is visible and editable in the dashboard, so an address blocked by accident can be released.
Layer two: an approved session is still a watched session
Approval is a door, not a blank cheque. Inside an allowed session, Guardian still looks at what happens: whether installers are transferred, whether privileges escalate, whether the activity stops resembling the support that was agreed to. Those events count together, and Guardian can end a session that turns.
This is where behaviour matters rather than brand names. A scammer can move from one well-known remote tool to an obscure one; a list of product names would miss that. What does not change is the shape of the activity.
What a person actually sees
Approval requests and incidents are written as sentences, not alert codes: who asked to connect, from where, what was decided, and what followed. Guardian Story carries that plain version, with the technical view of the same event one step underneath.