An engineer opens a remote desktop to fix a Windows host. The app on screen is showing a customer's full record: a name, an account, a social security number in plain text. The engineer did nothing wrong. The data should not be on that screen at all, and now a second person has seen it.
hoop.dev now blanks that data out of the live screen, in real time, before the operator sees it. The guard watches an RDP session as it streams, finds PII on the screen, and covers it while the session keeps running.
How do you keep an operator from seeing PII on a remote desktop?
You act on the screen before they do, and cover what should not be there.
A remote desktop session is pixels, not text. Someone connects to a Windows host over RDP, and whatever lives on that host reaches their screen: a customer record, a database export, a ticket with a card number in it. Recording the session for later does not stop the exposure, because the operator already saw it. The only place to intervene is the frame itself, before it lands.
The RDP PII guard sits in that gap. As the host sends screen updates, the guard reads the changed regions, checks them for sensitive data, and blanks the parts that should not be visible while the session keeps running.
How does real-time RDP redaction work?
The guard runs in the hoop.dev agent, on the traffic stream between the Windows host and the operator.
It composites the RDP bitmap updates into a shadow copy of the screen, runs OCR over the regions that changed, and passes the text to Presidio, the detection engine hoop.dev already uses for data masking. On a match, it blanks that area of the frame. The operator sees the desktop with the sensitive values hidden, live, rather than a warning after the fact.
A working definition: the RDP PII guard is a real-time filter on a remote-desktop stream that reads each screen update, detects sensitive data, and removes it from the frame before it reaches the person.
Does the sensitive data leave my network?
No. Detection runs inside your network, and hoop.dev only ever sees redacted frames.
The guard runs in the agent you host, where the decrypted stream already exists. OCR and detection happen there. The gateway receives frames that are already cleared or redacted, so raw PII never crosses to hoop.dev's side. And if the agent cannot start the guard, the session is refused rather than run unprotected. The safe state is closed.
This matters for a plain reason: a tool built to keep sensitive data off a screen should not be what copies it somewhere new.
Redact or kill the session?
The guard can do either, and we default to redact.
Redact blanks the pixels that hold the sensitive data and lets the session continue, so the operator keeps working while the data stays hidden. Kill ends the session on detection, which clears the whole screen and stops the work. Kill fits the strictest environments, where any exposure should halt everything. For most teams, redact is the better default: protect the data without turning the desktop off. Both are one setting.
What the RDP PII guard does not do
It reads the screen with OCR, so it is bound by what OCR can read. Unusual fonts, small text, or a value redrawn oddly across updates can slip through. It detects the categories Presidio recognizes, so a custom identifier needs its own rule. And it covers RDP today, the Windows remote-desktop path, not every protocol hoop.dev governs.
It also is not free on the stream. Reading and checking frames costs time, and we are still tuning the latency on the hot path. This is strong, improving detection, not a promise that a screen is guaranteed clean, and we would rather say so plainly.
The point
A recording tells you what an operator saw, after they saw it. A guard decides what reaches the screen at all. We would rather build the layer that acts a second early than the log that explains what went wrong a day late.
Q: How do you keep an operator from seeing PII on a remote desktop?
A: You act on the screen before they do and cover what should not be there.
Q: How does real-time RDP redaction work?
A: The guard runs in the hoop.dev agent on the stream between the Windows host and the operator, reads each screen update with OCR, detects sensitive data with Presidio, and blanks it in the frame.
Q: Does the sensitive data leave my network?
A: No. Detection runs inside your network, and hoop.dev only ever sees redacted frames.
Q: Can hoop.dev end the session instead of redacting?
A: Yes. The guard can redact or kill the session on detection, and it defaults to redact.