Secure RDP

How Secure is Your RDP For Running AI Agents -10 Essential Steps

If you’re spinning up AI agents on a Windows Server and relying on Remote Desktop Protocol to manage everything, you’re sitting on a goldmine and a minefield. Here’s how to make sure it stays the former.

I’ve seen this pattern more times than I can count: someone sets up a powerful Windows VM, enables RDP for easy access, deploys a fleet of AI agents, and then barely thinks about security. The server runs fine for weeks. Then one day ransomware, cryptomining payload, or a complete credential dump.

RDP is one of the most attacked surfaces on the internet. According to Shodan, millions of RDP ports are exposed publicly at any given moment. Add AI agents into the mix which often need persistent sessions, browser access, and elevated permissions and the risk profile jumps considerably.

Let’s fix that. Here are 10 steps I’d walk any team through before running AI agents on an RDP-exposed server.

1. Stop Exposing Port 3389 to the Internet

This is the non-negotiable starting point. The default RDP port (3389) gets hammered by automated scanners constantly. If it’s open to the world, you’re not asking if someone will try to brute-force it, you’re asking when.

Move RDP behind a VPN. Your agents connect to the VPN first, then to the server. No VPN access, no RDP.

Tools like WireGuard, Tailscale, or even a cloud provider’s built-in VPN gateway work well here. Tailscale, in particular, is stupidly easy to set up and works great for teams managing remote agent infrastructure.

If you absolutely can’t use a VPN, at minimum restrict RDP access to specific IP allowlists through your firewall rules.

2. Change the Default RDP Port

Not a silver bullet, but still worth doing. Switching from 3389 to something like 49200 (or any high, non-standard port) eliminates a huge chunk of automated scanning traffic that never bothers probing non-default ports.

Again this is obscurity, not security. Do it, but don’t rely on it alone.

3. Enable Network Level Authentication (NLA)

NLA forces users to authenticate before a full RDP session is established. Without it, the server spins up a partial session just to show the login screen which wastes resources and exposes more attack surface.

With NLA enabled, credentials get verified at the network layer first. This significantly reduces exposure to credential-stuffing attacks and certain remote code execution exploits that target the pre-authorization stage.

Enable it in System Properties → Remote → Allow connections only from computers running Remote Desktop with Network Level Authentication.

4. Use Strong, Unique Credentials and a Password Manager

Your AI agent service accounts should never share passwords with admin accounts. Each agent should have its own dedicated Windows user with the minimum permissions it actually needs to do its job.

Use long, randomly generated passwords (20+ characters). Store them in a secrets manager HashiCorp Vault, AWS Secrets Manager, or even a self-hosted Bitwarden rather than hardcoding them in config files or environment variables on the server.

Bonus: audit your existing accounts regularly. Disabled accounts that nobody remembered to delete are a common foothold attackers love.

5. Enforce Multi-Factor Authentication on RDP

Yes, you can add MFA to RDP, and yes, you absolutely should.

Solutions like Duo Security, Azure AD’s Conditional Access, or open-source options like privacyIDEA integrate with Windows login to require a second factor before granting access. This single step stops the overwhelming majority of credential-stuffing and phishing-based attacks cold.

For AI agents that authenticate programmatically, you’ll want certificate-based authentication rather than MFA (since agents can’t tap an Authenticator app). But for any human admin access, MFA is mandatory.

6. Limit Who Can RDP In Strictly

Windows lets you control RDP access at the group policy level. Use it.

Remove the default “Remote Desktop Users” group if it’s bloated, and rebuild it with only the accounts that genuinely need access. AI agent service accounts should almost never be in the RDP group they should connect via APIs, task schedulers, or orchestration frameworks, not interactive desktop sessions.

Set this under Computer Configuration → Windows Settings → Security Settings → User Rights Assignment → Allow log on through Remote Desktop Services.

7. Set Up Account Lockout Policies

Brute-force attacks rely on being able to make thousands of login attempts without consequence. A simple lockout policy breaks this entirely.

Configure Windows to lock an account after 5–10 failed attempts for 15–30 minutes. Go to Security Policy → Account Lockout Policy and set:

• Account lockout threshold: 5 invalid attempts
• Lockout duration: 15 minutes
• Reset counter after: 15 minutes

For your AI agent accounts, monitor for unexpected lockouts; it can be an early warning that someone’s probing your server.

8. Keep RDP Sessions Isolated from Your Agent Workloads

Here’s something a lot of people overlook: when AI agents run browser automation, code execution, or file manipulation tasks, those actions happen inside the same session environment the agent is operating in. If an agent gets compromised, say, through a malicious website it visits as part of its task an attacker could potentially pivot to your RDP infrastructure.

Isolate agent workloads using separate Windows user accounts with restricted permissions and, where possible, separate VMs or containers. Don’t run your agents as the same user you RDP in as.

Consider using Windows Sandbox or Hyper-V isolated VMs for higher-risk agent tasks like web browsing or executing user-provided code.

9. Enable Comprehensive Logging and Set Up Alerts

You can’t respond to what you can’t see. Enable Windows Event Logging for RDP related events and ship those logs somewhere centralized to Elastic Stack, Splunk, Grafana Loki, or even Azure Monitor if you’re in the Microsoft ecosystem.

The key Event IDs to watch:

• 4625 — Failed logon attempt
• 4624 — Successful logon (especially logon type 10 = RemoteInteractive)
• 4648 — Logon using explicit credentials
• 1149 — RDP authentication successful (in TerminalServices-RemoteConnectionManager log)

Set alerts for: multiple 4625 events in a short window, any 4624 from an unexpected IP, or any logon outside business hours. These are your early warning systems.

10. Patch Aggressively and Use Windows Defender ATP (or Equivalent)

RDP has had some nasty vulnerabilities over the years BlueKeep (CVE-2019–0708) and DejaBlue are the infamous ones. Both were wormable, meaning an unpatched server could be compromised without any user interaction.

Enable Windows Update and don’t delay security patches. In production environments, I know “just patch it” is easier said than done but the risk of running an unpatched RDP server genuinely outweighs the disruption of a maintenance window.

On top of patching, enable Windows Defender (or deploy CrowdStrike, SentinelOne, or similar EDR). AI agents generate unusual processes and network behavior by design. An EDR solution helps you distinguish “agent doing its job” from “agent being weaponized.”

The Bigger Picture

Running AI agents on RDP servers isn’t inherently dangerous but it does raise the stakes. Agents often run with elevated permissions, maintain persistent sessions, and interact with external services. That makes the underlying infrastructure a high-value target.

The steps above aren’t exotic or expensive. Most of them are configuration changes and policies you can implement this week. What they require is intentionality, actually sitting down and treating your RDP server like the critical infrastructure it is.

Start with the VPN and NLA (steps 1 and 3). Those two alone will eliminate the vast majority of automated attacks. Then layer in the rest over the following weeks.

Your agents are working hard. Make sure the environment they’re running in is working just as hard to keep them safe.

Have questions about securing AI agent infrastructure or RDP hardening? Drop them in the comments always happy to dig into specifics.