MrLuke2

Posted on Mar 30 • Originally published at hodgeluke.hashnode.dev

Your AI Coding Agent Has Root Access to Your Machine. Does Anything Else?

#security #ai #devops #cloudflare

TL;DR

Two critical vulnerabilities — CVE-2026-22812 (CVSS 8.8) and CVE-2026-22813 (CVSS 9.6) — affect the most widely deployed open-source AI coding agent platforms. 220,000+ instances are exposed on the public internet with no authentication. 15,200 are confirmed vulnerable to unauthenticated remote code execution. But the exposure isn't limited to cloud servers — the same agent running on your Mac Mini under your desk has the same root-level access to your files, your credentials, and your network. This article provides the technical analysis, the exposure data, remediation for both VPS and local hardware deployments, and a 5-layer defense architecture that works regardless of where your agent runs.

The machine under your desk

Apple cannot keep the Mac Mini in stock. The M4 and M4 Pro configurations are backordered across most retailers, and the reason is not what Apple planned for. Developers are buying them to run AI coding agents locally — specifically OpenClaw, which needs Apple Silicon's unified memory architecture for local LLM inference.

The logic makes sense on paper. A $600 Mac Mini with 16GB of unified memory runs a 7B parameter model fast enough for real-time coding assistance. A $1,400 M4 Pro with 48GB runs 34B models comfortably. No cloud costs. No API rate limits. No data leaving your network. Private, fast, and owned.

There is one problem. The agent running on that Mac Mini has the same privileges as the user who launched it. On most developer machines, that means:

Full read/write access to ~/ — every project, every .env file, every SSH key
Access to the macOS Keychain if unlocked
Ability to install packages, modify system files, and execute arbitrary shell commands
Network access to every service on the local network — NAS drives, printers, other machines
No sandboxing, no firewall rules, no permission boundaries

A Meta security researcher had to physically unplug her Mac Mini to stop an AI coding agent from deleting her email inbox. The agent was running with full system permissions and connected to a compromised skill package. It began executing destructive commands that could not be stopped through the UI because the WebSocket connection was being used by the attacker's injected scripts.

That incident happened on a local machine with no internet exposure. The attack vector was not a network exploit — it was a malicious package in the agent's skill chain.

For the 220,000+ instances running on VPS infrastructure with no authentication and no firewall, the same attack can be executed remotely by anyone on the internet.

The industry spent two months talking about the 220,000 number. What it missed is that the number only counts servers. It does not count the desks.

Two CVEs, one architectural failure

CVE-2026-22812: Unauthenticated Remote Code Execution

CVE ID: CVE-2026-22812
CVSS Score: 8.8 (High)
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Affected Software: OpenCode HTTP server (serve mode), OpenClaw instances
Discovery: Reported via NVD/NIST, confirmed by SecurityScorecard STRIKE team

When an AI coding agent runs in serve mode — exposing an HTTP and WebSocket interface for browser-based interaction — the server binds to 0.0.0.0 by default. In versions prior to 1.1.10, this server has no authentication mechanism whatsoever. Even in 1.1.10+, where the server is disabled by default, enabling it provides only optional Basic Auth that most deployments skip.

Any process on the network — or anyone on the internet if the server is publicly reachable — can:

Execute arbitrary shell commands with the user's full privileges
Read and write any file accessible to the running process
Install packages, modify system configurations, exfiltrate data
Pivot to other services running on the same host or network

The agent is not a code assistant. It is a full remote shell with an AI interface.

On a VPS: If port 4096 is open, the entire internet has root access.
On a Mac Mini: If the agent binds to 0.0.0.0 instead of 127.0.0.1, every device on the local network has root access. On a coffee shop WiFi, a coworking space, a hotel — that is everyone in the room.

CVSS vector breakdown

Component	Value	Meaning
Attack Vector	Network	Exploitable remotely
Attack Complexity	Low	No special conditions required
Privileges Required	None	No authentication needed
User Interaction	None	No victim action required
Scope	Unchanged	Stays within the vulnerable component
Confidentiality	High	Full read access
Integrity	High	Full write access
Availability	High	Full denial of service possible

This is a trivially exploitable vulnerability. If the port is reachable, the system is compromised.

CVE-2026-22813: XSS-to-RCE via LLM Output

CVE ID: CVE-2026-22813
CVSS Score: 9.6 (Critical)
Affected Software: OpenClaw web UI

The web interface that renders AI agent output does not sanitize the markdown and HTML returned by the language model. An attacker who can influence the LLM's output — through prompt injection, malicious context documents, or compromised training data — can inject arbitrary JavaScript that executes in the user's browser session.

Because the browser session has an active WebSocket connection to the agent backend, this JavaScript can send commands to the agent as if the user typed them, exfiltrate the contents of the current session, execute shell commands through the agent's execution interface, and persist across sessions if the injected script writes to the agent's context files.

This is the vulnerability that matters most for Mac Mini owners. CVE-2026-22812 requires network access to the agent's port. CVE-2026-22813 does not. It requires only that the agent processes a file, package, or repository that contains adversarial content. Given that AI coding agents routinely clone repositories, install npm/pip/cargo packages, read documentation files, and process code review comments — the attack surface is every piece of content the agent interacts with.

The Mac Mini on your desk. Running a local model. No cloud connection. Still vulnerable to CVE-2026-22813 through a poisoned package.json or a malicious code review comment.

The exposure data

Between January and March 2026, multiple independent security research groups conducted internet-wide scans targeting AI coding agent infrastructure:

Finding	Count	Source
OpenClaw instances exposed on public internet	220,000+	Censys, Bitsight, Penligent
Instances confirmed vulnerable to RCE (CVE-2026-22812)	15,200	Penligent
Instances correlated with prior breach activity	53,300	SecurityScorecard STRIKE team
Malicious packages in ClawHub skill marketplace	1,184	CyberDesserts
Leaked API tokens (Supabase breach)	1,500,000	Infosecurity Magazine
Leaked email addresses (same breach)	35,000	Infosecurity Magazine

These numbers are the ones that made the news. They count VPS deployments — Hetzner, DigitalOcean, Linode, Contabo — where a developer provisioned a server, installed the agent, started serve mode, and did not configure a firewall.

What they do not count: Mac Minis on home networks. Development laptops in coworking spaces. Workstations in offices with flat network topologies. These machines are not indexed by Censys. They are not visible to Shodan. But if the agent's HTTP server binds to anything other than 127.0.0.1, every device on the same network segment has the same unauthenticated access that the internet has to those 220,000 VPS instances.

The 220,000 number is a floor. The actual exposure includes every unsandboxed AI coding agent running on every machine where the developer has not explicitly configured network isolation. The Mac Mini shortage suggests that number is growing, not shrinking.

The supply chain problem

The 1,184 malicious packages discovered in the ClawHub skill marketplace represent a systemic supply chain compromise. These packages masqueraded as legitimate MCP skills but contained credential harvesters, reverse shells, cryptominers, and data exfiltration routines.

This is the attack path that bypasses all network-level defenses. A tunnel does not help if the agent itself installs a malicious package that reads ~/.ssh/id_rsa and uploads it to an attacker's server. A firewall does not help if the package phones home through an outbound HTTPS connection that looks identical to a legitimate API call.

Defense requires both network isolation (Layers 1–3) and permission scoping (Layer 5). Neither alone is sufficient.

Why this happened

The root cause is not a coding error. It is an architectural assumption.

AI coding agents were designed as local development tools. They assume a trusted network — your laptop, your home WiFi. The HTTP server is a convenience feature: start the agent, open a browser tab, start coding.

That assumption fails in two directions simultaneously:

Direction 1: Servers. Developers run agents on VPS infrastructure because they need persistent execution, shared team access, and GPU availability. The agent's HTTP server, designed for localhost, is now reachable from the public internet. This produced the 220,000 exposed instances.

Direction 2: Local hardware at scale. The Mac Mini shortage proves that developers are deploying AI agents on physical hardware in volumes that matter. These machines sit on home networks, office networks, and coffee shop WiFi. They are not behind firewalls. They are not running in sandboxes. The agent has the same access to the filesystem, the network, and the macOS Keychain that the developer does. The difference from the VPS scenario is visibility — no one is scanning home networks, so the exposure goes unreported.

Both directions share the same gap: the tooling provided zero infrastructure guidance. No documentation for firewall configuration. No reverse proxy templates. No authentication integration. No sandboxing guide for macOS. No permission scoping.

Developers were told "start the server and open a browser." They did.

Reproduction methodology

The following describes the verification methodology used by researchers. This information is provided for defensive purposes — to help teams verify whether their own instances are vulnerable.

For VPS deployments

Step 1: Use Censys, Shodan, or any internet-facing port scanner to identify hosts running the agent's HTTP server. The default port is 4096. The server responds with a distinctive HTTP response that includes WebSocket upgrade headers and the agent's UI HTML.

GET / HTTP/1.1
Host: <target-ip>:4096

A vulnerable instance returns a 200 response with the full agent interface. There is no login page. There is no authentication challenge.

Step 2: Connect to the WebSocket endpoint. The agent accepts commands in its standard message format. Any command that the agent can execute — file operations, shell commands, package installations — is available to the attacker.

Step 3: Send a benign verification command (e.g., whoami, hostname, uname -a). If the agent returns system information, the instance is confirmed vulnerable.

Important: Do not execute destructive commands. Do not access, copy, or modify any data. Verification should confirm the vulnerability exists and stop. Report findings to the instance owner if identifiable.

For local hardware (Mac Mini, workstations)

Step 1: On the machine running the agent, check what address the server is bound to:

# macOS
lsof -i :4096

# Linux
ss -tlnp | grep 4096

If the output shows *:4096 or 0.0.0.0:4096, the agent is listening on all network interfaces — not just localhost. Any device on the same network can connect.

Step 2: From another device on the same network (phone, laptop, tablet), open a browser and navigate to http://<mac-mini-ip>:4096. If the agent's interface loads, the machine is exposed to the local network.

Step 3: Check what the agent process has access to:

# What user is running the agent?
whoami

# What files are readable?
ls ~/

# Is the macOS Keychain accessible?
security list-keychains

# Are SSH keys present?
ls ~/.ssh/

# Are environment variables set with API keys?
env | grep -i key

In the majority of local installations, the agent runs as the primary user account — which means full access to the home directory, all development projects, all SSH keys, and all environment variables containing API credentials.

Remediation: 5-layer defense-in-depth

The following architecture addresses both CVEs at the infrastructure level. The first three layers apply to VPS deployments. All five layers apply to any deployment, including local hardware.

Layer 1: Network isolation — eliminate the public attack surface

For VPS deployments:

Use an outbound-only encrypted tunnel instead of opening inbound ports. Cloudflare Tunnel (cloudflared) establishes a connection from your server to Cloudflare's network using outbound-only QUIC connections on port 7844. No inbound ports are opened. The server's IP address is never exposed. All traffic routes through Cloudflare's 330+ city anycast network.

# Install cloudflared
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg \
  | gpg --dearmor -o /usr/share/keyrings/cloudflare.gpg
echo "deb [signed-by=/usr/share/keyrings/cloudflare.gpg] \
  https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" \
  | tee /etc/apt/sources.list.d/cloudflared.list
apt update && apt install cloudflared

# Create tunnel (requires Cloudflare API token)
cloudflared tunnel create my-agent-tunnel

# Configure: route agent.yourdomain.com → localhost:4096
# Catch-all: return 404 for all other hostnames

Configuration note: Set the tunnel's catch-all to http_status:404. This ensures that any request arriving at Cloudflare that does not match your specific hostname is rejected before it reaches your server.

For Mac Mini / local hardware:

Force the agent to bind to 127.0.0.1 only — never 0.0.0.0. This restricts the HTTP server to connections originating from the same machine.

# If the agent supports a bind address flag:
opencode serve --host 127.0.0.1

# Verify it's not listening on all interfaces:
lsof -i :4096
# Should show: 127.0.0.1:4096, NOT *:4096

If you need to access the agent from another device (e.g., your laptop connecting to a Mac Mini on your desk), use SSH port forwarding instead of exposing the port:

# From your laptop, forward local port 4096 to the Mac Mini's localhost:4096
ssh -L 4096:127.0.0.1:4096 user@mac-mini-ip

# Then open http://localhost:4096 in your laptop's browser
# Traffic is encrypted through the SSH tunnel — never exposed on the network

For persistent remote access, Cloudflare Tunnel works on macOS as well:

# Install on macOS
brew install cloudflare/cloudflare/cloudflared

# Same tunnel configuration as Linux — agent stays on localhost,
# Cloudflare handles authenticated remote access

What this prevents: On VPS — direct IP scanning, port-based attacks, DDoS. On local hardware — exposure to every device on the same WiFi or LAN. The agent becomes reachable only through authenticated channels.

Layer 2: Identity verification — gate every request

Cloudflare Zero Trust Access enforces authentication at the edge. Before a request is proxied to your tunnel (and therefore your server or Mac Mini), the user must authenticate through an identity provider — Google, GitHub, one-time pin via email, or any SAML/OIDC provider.

Access Policy:
  Action: Allow
  Include: Emails ending in @yourdomain.com
  Session duration: 24 hours
  Cookie: SameSite=None, HttpOnly, Binding=Enabled

Critical configuration for WebSocket agents: The SameSite=None and Binding Cookie settings are required for AI coding agents that use WebSocket connections. Without them, the browser's WebSocket upgrade request will fail the cookie check and the session will drop mid-conversation. This is a common misconfiguration that causes intermittent disconnections.

What this prevents: Unauthorized access from anyone who does not possess valid identity credentials. Even if an attacker discovers the agent's URL, they see a Cloudflare login page — not the agent interface.

Layer 3: Application authentication — defense in depth

Enable authentication on the agent's HTTP server itself as a secondary gate.

# Generate a high-entropy password
AGENT_PASSWORD=$(openssl rand -base64 24)

# Set as environment variable for the agent process
# Linux (systemd):
echo "OPENCODE_SERVER_PASSWORD=$AGENT_PASSWORD" >> /etc/systemd/system/opencode.service.d/override.conf
systemctl daemon-reload && systemctl restart opencode

# macOS (launchd or manual):
export OPENCODE_SERVER_PASSWORD=$AGENT_PASSWORD
opencode serve

Important caveat: When Zero Trust Access is active, enabling Basic Auth on the agent server can create an authentication loop (Access redirects on 401, server returns 401 before Access processes). The correct implementation is conditional: set the server password only when Zero Trust is not configured. When Zero Trust is active, it is the authentication layer.

Layer 4: Host hardening — reduce the blast radius

For VPS (Ubuntu/Debian):

# Firewall: deny all inbound, allow SSH only
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw --force enable
# Port 4096 is NOT opened — all agent traffic goes through the tunnel

# Brute force protection
apt install -y fail2ban
systemctl enable fail2ban

# Kernel hardening
cat >> /etc/sysctl.d/99-hardening.conf << 'EOF'
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_redirects = 0
kernel.randomize_va_space = 2
net.ipv4.conf.all.log_martians = 1
EOF
sysctl --system

# Automatic security updates
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

Control	What it does
UFW (default deny)	Blocks all inbound traffic except SSH
fail2ban	Bans IPs after repeated failed SSH attempts
SYN cookies	Prevents SYN flood denial of service
Reverse path filtering	Prevents IP spoofing
ICMP broadcast ignore	Prevents Smurf amplification attacks
Redirect rejection	Prevents ICMP redirect hijacking
ASLR (full)	Randomizes memory addresses to defeat buffer overflow exploits
Martian logging	Logs packets with impossible source addresses
Unattended upgrades	Automatically applies security patches

For Mac Mini / macOS:

macOS does not need the same kernel hardening (it ships with ASLR, SIP, and Gatekeeper enabled). The priorities are different:

# Enable the macOS firewall
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on

# Block all incoming connections (allow only essential services)
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setblockall on

# Enable stealth mode (don't respond to pings or port scans)
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on

# Verify settings
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

Additional macOS-specific hardening:

# Disable Remote Login (SSH) if you don't need it
sudo systemsetup -setremotelogin off

# Disable Remote Management
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart \
  -deactivate -configure -access -off

# Enable FileVault (full disk encryption) — critical if the machine is physically accessible
sudo fdesetup enable

# Automatic updates
sudo softwareupdate --schedule on

Control	What it does
macOS Firewall (block all)	Blocks all incoming connections
Stealth mode	Makes the machine invisible to network scans
FileVault	Encrypts the entire disk — protects if the machine is stolen
Remote Login off	Disables SSH access if not needed
Automatic updates	Applies security patches as they ship

Post-deployment: Disable SSH password authentication on both VPS and macOS. Use key-only access:

# Linux
sed -i 's/^PermitRootLogin yes/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
systemctl restart sshd

# macOS (if SSH is enabled)
sudo sed -i '' 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo launchctl stop com.openssh.sshd && sudo launchctl start com.openssh.sshd

Layer 5: Scoped permissions — limit what each agent can do

This layer is the one that defends against CVE-2026-22813 and supply chain attacks — the threats that bypass all network-level protection. It applies equally to VPS deployments and Mac Mini setups.

MCP servers — now governed by the Linux Foundation with backing from Anthropic, OpenAI, Google, Microsoft, AWS, and Cloudflare — provide a standardized interface between AI agents and external tools. The critical security feature of MCP is that each server connection can be independently scoped:

Read-only agents receive MCP connections with write: false — they can analyze code, run audits, and report findings, but cannot modify files
Scoped write agents receive MCP connections limited to specific operations — a deployment agent can interact with Cloudflare Workers but cannot modify DNS records outside its configured zone
No-shell agents receive MCP connections with bash: false — they cannot execute arbitrary commands regardless of what the LLM requests

# Example: read-only security auditor
agent:
  name: security-reviewer
  tools:
    write: false
    edit: false
    bash: false
  mcp:
    - cloudflare-docs    # Can read documentation
    - github             # Can read repositories
    # Cannot: deploy, modify, execute

This is not behavioral guardrailing. The agent cannot prompt its way past these restrictions. The MCP server simply does not expose write operations to agents configured as read-only. The permission boundary is enforced at the infrastructure layer, not the prompt layer.

For Mac Mini owners specifically: This layer is your primary defense against supply chain attacks. A malicious package installed by the agent can execute code with the agent's permissions. If the agent has unrestricted filesystem and shell access, the package has unrestricted filesystem and shell access. Scoped MCP permissions mean that even if the agent is tricked into installing a malicious package, the damage is bounded by the agent's configured permission set — not by the user's full system access.

What you should do today

If you run an agent on a VPS

Check exposure now. Run ss -tlnp | grep 4096 — if the port is listening, check if it's reachable from outside. Search Censys or Shodan for your server's IP.
Block the port. ufw deny 4096 — the single fastest remediation.
Set up a tunnel. Cloudflare Tunnel is free. Remove the port from the internet entirely.
Harden the host. Apply kernel parameters, enable fail2ban, enable automatic updates.
Scope your agents. Restrict MCP permissions. Audit agents should be read-only.

If you run an agent on a Mac Mini or local machine

Check the bind address now. Run lsof -i :4096 — if it shows *:4096, your agent is exposed to your entire network.
Force localhost binding. Restart the agent with --host 127.0.0.1.
Enable the macOS firewall. Block all incoming. Enable stealth mode.
Use SSH tunneling for remote access. Never expose the agent's port on the network directly.
Enable FileVault. If someone can physically access the Mac Mini, they should not be able to read the disk.
Scope the agent's permissions. This is your defense against malicious packages and prompt injection. Read-only agents for auditing, scoped agents for deployment.

This month (both platforms)

Monitor for compromise. Check for unauthorized SSH keys in ~/.ssh/authorized_keys. Check for unexpected cron jobs (VPS) or Launch Agents (macOS). Review outbound network connections for unfamiliar destinations.
Audit installed packages. Review what the agent has installed. Check for packages you did not explicitly request.
Review environment variables. If API keys, database credentials, or tokens are in your shell environment, the agent (and any malicious code it executes) has access to all of them. Use a secrets manager or scoped .env files instead of global exports.

Let your agent fix this for you

You just read 4,000 words of vulnerability analysis and remediation steps. Your AI coding agent — the one this article is about — can execute every one of them.

Copy the block below. Paste it into your agent's chat. Say: "Do this."

The agent will read the manifest, execute each step in order, stop when a condition isn't met, and ask you for credentials only when it needs them. It will not guess. It will not skip.

This is how security advisories should work in 2026. Not "read this and figure it out" — but "read this and execute."

Agent-Executable Remediation: CVE-2026-22812 / CVE-2026-22813

## Agent-Executable Remediation Manifest
## CVE-2026-22812 (CVSS 8.8) + CVE-2026-22813 (CVSS 9.6)
## Source: Hodge Luke Digital Intelligence Agency
## Target: Any VPS or macOS machine running an AI coding agent

### INSTRUCTIONS FOR AGENT
Execute each step sequentially. Do not skip steps.
STOP_IF conditions halt execution — explain why to the user and await instructions.
ASK_USER directives require user input before proceeding — do not guess values.
All commands must be run with appropriate privileges (sudo where indicated).
Report the result of each step before moving to the next.

---

### Step 0: Detect platform
Run: uname -s
IF output contains "Darwin" → SET PLATFORM=macos
IF output contains "Linux" → SET PLATFORM=linux
REPORT: "Detected platform: [PLATFORM]"

---

### Step 1: Check if an agent HTTP server is running
IF PLATFORM=linux:
  Run: ss -tlnp | grep -E ':(4096|3000|8080|8888) '
IF PLATFORM=macos:
  Run: lsof -i -P | grep -E ':(4096|3000|8080|8888) .*(LISTEN)'

STOP_IF: No output (no agent server detected — this machine may not be affected)
REPORT: "Found agent server listening on: [port and address]"

IF output shows 0.0.0.0 or *: → REPORT: "WARNING: Agent is bound to all
interfaces — exposed to the network. Proceeding with remediation."
IF output shows 127.0.0.1 only → REPORT: "Agent is bound to localhost only.
Network exposure is limited. Continuing with hardening steps."

---

### Step 2: Block the port immediately
IF PLATFORM=linux:
  Run: sudo ufw status
  IF ufw is inactive:
    Run: sudo ufw default deny incoming
    Run: sudo ufw default allow outgoing
    Run: sudo ufw allow ssh
    Run: sudo ufw --force enable
  Run: sudo ufw deny [detected port from Step 1]
  Run: sudo ufw reload
  REPORT: "Firewall enabled. Port [port] blocked."

IF PLATFORM=macos:
  Run: sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
  IF firewall is disabled:
    Run: sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on
  Run: sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setblockall on
  Run: sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setstealthmode on
  REPORT: "macOS firewall enabled. All incoming blocked. Stealth mode on."

---

### Step 3: Force localhost binding
IF PLATFORM=linux:
  Check if agent is managed by systemd:
    Run: systemctl list-units --type=service | grep -i -E 'opencode|claw'
  IF found:
    REPORT: "Agent is running as systemd service: [service name]"
    ASK_USER: "Should I modify the service to bind to 127.0.0.1 only? (yes/no)"
    IF yes:
      Run: sudo mkdir -p /etc/systemd/system/[service].d
      Write override.conf with Environment="HOST=127.0.0.1"
      Run: sudo systemctl daemon-reload
      Run: sudo systemctl restart [service]

IF PLATFORM=macos:
  REPORT: "On macOS, restart your agent with: --host 127.0.0.1"
  REPORT: "Example: opencode serve --host 127.0.0.1"
  ASK_USER: "What is the command you use to start your agent? I will provide
  the modified command with localhost binding."

---

### Step 4: Install Cloudflare Tunnel (optional but recommended)
ASK_USER: "Do you want to set up a Cloudflare Tunnel for secure remote
access? This requires a Cloudflare account. (yes/no)"

STOP_IF: User says no (skip to Step 5)

ASK_USER: "Please provide your Cloudflare API token with Zone:DNS:Edit and
Account:Cloudflare Tunnel:Edit permissions."
ASK_USER: "What domain do you want to use for accessing the agent?
(e.g., agent.yourdomain.com)"

IF PLATFORM=linux:
  Run: curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg \
    | sudo gpg --dearmor -o /usr/share/keyrings/cloudflare.gpg
  Run: echo "deb [signed-by=/usr/share/keyrings/cloudflare.gpg] \
    https://pkg.cloudflare.com/cloudflared $(lsb_release -cs) main" \
    | sudo tee /etc/apt/sources.list.d/cloudflared.list
  Run: sudo apt update && sudo apt install -y cloudflared

IF PLATFORM=macos:
  Run: brew install cloudflare/cloudflare/cloudflared

Run: cloudflared tunnel login
Run: cloudflared tunnel create agent-tunnel
Write config.yml:
  tunnel: [tunnel-id]
  credentials-file: /root/.cloudflared/[tunnel-id].json
  ingress:
    - hostname: [user-provided domain]
      service: http://localhost:[detected port]
    - service: http_status:404
Run: cloudflared tunnel route dns agent-tunnel [user-provided domain]
Run: cloudflared tunnel run agent-tunnel

REPORT: "Tunnel created. Agent accessible at https://[domain].
No inbound ports required."

---

### Step 5: Harden the host
IF PLATFORM=linux:
  Run: sudo apt install -y fail2ban
  Run: sudo systemctl enable fail2ban

  Write /etc/sysctl.d/99-agent-hardening.conf:
    net.ipv4.tcp_syncookies = 1
    net.ipv4.conf.all.rp_filter = 1
    net.ipv4.icmp_echo_ignore_broadcasts = 1
    net.ipv4.conf.all.accept_redirects = 0
    kernel.randomize_va_space = 2
    net.ipv4.conf.all.log_martians = 1
  Run: sudo sysctl --system

  Run: sudo apt install -y unattended-upgrades
  Run: sudo dpkg-reconfigure -plow unattended-upgrades

  REPORT: "Host hardened: fail2ban active, kernel parameters set,
  automatic security updates enabled."

IF PLATFORM=macos:
  Run: sudo fdesetup status
  IF FileVault is off:
    REPORT: "FileVault (disk encryption) is disabled."
    ASK_USER: "Enable FileVault? This encrypts your entire disk.
    Requires restart. (yes/no)"
    IF yes: Run: sudo fdesetup enable

  Run: sudo softwareupdate --schedule on
  REPORT: "macOS hardened: firewall active, stealth mode on,
  automatic updates enabled."

---

### Step 6: Disable SSH password authentication
IF PLATFORM=linux:
  Run: grep -E '^PasswordAuthentication' /etc/ssh/sshd_config
  IF set to yes:
    Run: sudo sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' \
      /etc/ssh/sshd_config
    Run: sudo systemctl restart sshd
    REPORT: "SSH password authentication disabled. Key-only access."

IF PLATFORM=macos:
  Run: sudo systemsetup -getremotelogin
  IF Remote Login is on:
    ASK_USER: "SSH is enabled. Do you need remote SSH access to this
    machine? (yes/no)"
    IF no:
      Run: sudo systemsetup -setremotelogin off
      REPORT: "SSH disabled entirely."
    IF yes:
      Run: sudo sed -i '' 's/^#PasswordAuthentication yes/PasswordAuthentication no/' \
        /etc/ssh/sshd_config
      Run: sudo launchctl stop com.openssh.sshd
      Run: sudo launchctl start com.openssh.sshd
      REPORT: "SSH password authentication disabled. Key-only access."

---

### Step 7: Verify remediation
IF PLATFORM=linux:
  Run: ss -tlnp | grep -E ':(4096|3000|8080|8888) '
  Run: sudo ufw status verbose
  Run: systemctl is-active fail2ban

IF PLATFORM=macos:
  Run: lsof -i -P | grep -E ':(4096|3000|8080|8888) .*(LISTEN)'
  Run: sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
  Run: sudo fdesetup status

REPORT: "Remediation complete. Summary:"
REPORT: "- Agent bind address: [current binding]"
REPORT: "- Firewall: [status]"
REPORT: "- SSH hardening: [status]"
REPORT: "- Host hardening: [status]"
REPORT: "- Tunnel: [configured/not configured]"
REPORT: "- Disk encryption: [status, macOS only]"

---

### What this manifest does NOT cover (requires manual review)
- Layer 2 (Zero Trust Access): Requires Cloudflare dashboard configuration
  for identity provider integration. See the full article for policy setup.
- Layer 5 (MCP permission scoping): Requires agent-specific configuration
  based on your tool chain. See the full article for examples.
- Supply chain audit: Review installed packages manually.
  Run: pip list / npm list -g / cargo install --list
- Credential rotation: If your agent was exposed, assume all environment
  variables, SSH keys, and API tokens accessible to the agent process are
  compromised. Rotate them.

This is the first security advisory we've published with an agent-executable remediation manifest. We believe every security disclosure that tells developers what to do should let their tools do it for them. We'll be publishing these with every advisory going forward.

The architecture we built

We built FORGE because we were setting up AI coding agent infrastructure for clients and kept solving the same security problems from scratch — every time. Cloudflare Tunnel configuration. Zero Trust access policies. WebSocket cookie conflicts. Kernel hardening. MCP server scoping. The same 1,000 lines of battle-tested bash with rollback on failure.

FORGE implements all five layers described in this article as a single deployment script. One command. Under 10 minutes. The agent runs on your VPS, behind your tunnel, gated by your identity, hardened to CIS baselines, with MCP servers pre-configured and scoped.

It is not a hosted service. You own the server. You own the code. You own the infrastructure. The $47 Developer Edition buys the architecture, security model, and deployment automation. Your VPS costs about $7/month. There is no recurring fee to us.

We built it because the gap between "start the server" and "run the server securely" should not require 1,000 lines of infrastructure automation that every developer has to figure out from scratch. FORGE closes that gap.

Product: forge.useacceda.com
Full comparison (8 platforms): forge.useacceda.com/compare
Security architecture: SECURITY.md
Purchase: hodgeluke.gumroad.com/l/forge — $47, one-time

Sources

CVE-2026-22812. National Vulnerability Database (NVD/NIST). CVSS 8.8. Unauthenticated remote code execution in OpenCode HTTP server.
CVE-2026-22813. National Vulnerability Database (NVD/NIST). CVSS 9.6. Cross-site scripting to remote code execution via unsanitized LLM output in OpenClaw web UI.
220,000+ exposed instances. Cumulative findings from Censys, Bitsight, Bitdefender, and Penligent internet-wide scans, January–March 2026.
15,200 confirmed RCE-vulnerable instances. Penligent research report, Q1 2026.
53,300 instances correlated with breach activity. SecurityScorecard STRIKE team analysis, Q1 2026.
1,184 malicious ClawHub packages. CyberDesserts supply chain analysis, February 2026.
1.5 million leaked API tokens and 35,000 email addresses. Infosecurity Magazine report on Supabase breach affecting AI agent deployments, March 2026.
AI agent market $7.8–10.9B (2026), projected $52B by 2030. Industry composite estimates (Gartner, McKinsey, CB Insights).
92% of US developers use AI coding tools daily. GitHub developer survey, 2026.
41% of all code is AI-generated. Google internal metrics, reported Q1 2026.
24.7% of AI-generated code contains security flaws. Snyk Code analysis, 2025–2026.
MCP: 97 million monthly SDK downloads, 10,000+ servers. Linux Foundation MCP governance announcement, March 2026.
Nate B. Jones, "5 Skills" framework. AI News & Strategy Daily, published March 16, 2026. Framework for AI agent management: prompting, context management, iteration, evaluation, deployment.
NVIDIA NemoClaw. GTC 2026 announcement, NVIDIA Newsroom. Enterprise security wrapper for OpenClaw.
Apple Mac Mini supply constraints. M4 and M4 Pro configurations backordered across major retailers, Q1 2026. Developer community reports attribute demand to local AI agent hosting on Apple Silicon unified memory architecture.

About the author

Hodge Luke is the founder of Hodge Luke Digital Intelligence Agency and the creator of FORGE — a security-hardened deployment platform for AI coding agents built on Cloudflare's edge network. FORGE implements the 5-layer defense-in-depth model described in this article as a one-command deployment.

Website: forge.useacceda.com
Security disclosures: info@useacceda.com

Hodge Luke | Two Guys and some Bots | forge.useacceda.com

DEV Community