Windsurf, Cursor, and cloud development environments let you drive a development machine through a browser. That requires holding an outbound connection open to a server the tool did not start, accepting instructions over that connection, running them with your privileges, and coming back after a reboot.
Those are also the requirements for a remote access trojan. Remote development products and RATs request the same capabilities, so a scanner classifying on capability alone is reading a description that fits both. Remote coding agents, fleet management clients, CI runners on developer hardware, and browser-driven agent consoles all ask for the permissions a backdoor asks for.
The capability list is identical
| Capability | Why a RAT needs it | Why a remote agent needs it |
|---|---|---|
| Persistent outbound connection | Reach a host behind NAT without opening a port | Reach a host behind NAT without opening a port |
| Server-initiated instructions | Operator control of the host | The console tells the agent what to do |
| Boot persistence | Survive restarts and stay in place | The machine should be available after a restart |
| Background execution, no window | Avoid the user noticing | A background service has no terminal to attach to |
| Installing a second runtime | Stage a payload host | Install the tool the product drives |
| Host telemetry on connect | Inventory the compromised estate | Diagnostics and support |
Provenance, consent, and endpoint control
Provenance. Does the publishing account map to an accountable entity with something to lose? Accounts created last week can be abandoned at no cost, which is not true of a company with a payment integration and customers.
Consent. Did the user knowingly start this, and did they understand what they were agreeing to? The user typing a flag is different from an install hook that ran while they read the README, and only one of them is consent.
Endpoint control. Who operates the server the agent obeys, and will the same party still operate it in a year?
Reversibility. Can the user revoke the token and remove the persistence without reinstalling the operating system?
Who authenticates whom
Most agent-and-relay designs authenticate in one direction. The agent opens a socket, sends a token, and the server validates it. The agent learns nothing in return. It has handed a secret to whatever answered the address.
In automatic remediation, the client reports an error, a model on the server diagnoses it, and the reply carries a command for the client to run. When the reply also carries the flag authorizing the client to run it, the sender is granting its own permission. The client cannot refuse, because it never established who is speaking, and the user is not in the loop.
The first factor is whether execution requires a prior request. If the remediation channel only accepts replies matching an outstanding error report, the server can only act on failures the client actually had. If the handler acts on any message of the right type, it accepts instructions at any moment, even when the client is running perfectly.
The second is whether the endpoint is a name the vendor owns. Hostnames on shared platform domains are assigned rather than owned. If a project is deleted, an account lapses, or billing fails, the name returns to a pool. Whoever claims it next inherits every client still trying to reconnect, and they keep trying.
False positives and false negatives
Scanners that classify by capability flag legitimate tools and miss hostile ones.
False negatives let backdoors pass as products. Register a domain and publish documentation, and the same capability list now reads as a legitimate remote development tool. Provenance signals are cheap to manufacture, so the ones that count are the ones that cost something to keep: a payment processor relationship that can be revoked, or a support history someone can check.
Flagging a real product as malware takes it off the registry. Small teams have no fast channel to contest a published finding, and the cost falls hardest on developers far from the vendors doing the flagging, who have no one to email.
What to check before you connect a machine
The questions below apply to any tool that asks to hold an open connection and act on what arrives.
- Does the endpoint sit on a domain the vendor owns? A hostname on a shared platform domain can change hands quietly, while a registered domain with a paying owner leaves a record when it moves.
- Does the server authenticate itself to your client, or only the reverse? Look for a signature on server messages, or a pinned key the client checks beyond ordinary transport validation.
- Can the server cause your client to execute something without prompting you? Search the client for the process-spawning calls and read what reaches them. You are looking for a command string that arrived over the network.
- Where does the token live after installation? Persistence artifacts are readable. A token in a scheduled task, a launch agent, a unit file, or a process argument list is available to every local process running as you.
- What does uninstalling actually remove? Test it. Removal paths get written once and are rarely exercised, so they break quietly and leave the connection in place.
Where Aephix fits
The question this class of tool turns on is who operates the other end of the connection. Aephix Vantage lets you check a server or package for free before you connect, and Weekly Sleuth reports confirmed artifacts linked to the operation behind them, so you know what else the same operator has shipped. Legitimate tools ask for the same permissions, so the permission list alone cannot separate them.