If you've ever spun up a Linux VPS and deployed OpenClaw following a tutorial, you probably got something working in under an hour. And if you're like most developers, that's where the thought stopped because the guide ended there. But what the tutorials skip is exactly what burns people: how to think about what's actually exposed when an AI gateway sits between your messaging channels (Telegram, Discord, Slack) and providers like OpenAI or Anthropic. This DEV.to post from developer dean0x is that missing piece โ€” a security mental model built from real hardening work on a live VPS deployment.

What You're Actually Securing

The first move is understanding the asset inventory. An AI gateway holds three categories of secrets: LLM provider credentials (API keys, OAuth tokens), channel bot tokens for each messaging platform, and its own dashboard auth token. Everything else โ€” agent configs, session history, workspace state โ€” is data that needs backup and isolation, not cryptographic protection at rest. Conflating the two leads to either encrypting session logs unnecessarily or leaving API keys in plaintext JSON files on disk. That distinction alone shapes your entire security posture.

The Four Security Levels (Pick One)

The article frames deployment security as four tiers you implement incrementally based on team size and risk tolerance. Level 1 is personal use: host hardening, firewall rules, gateway bound to loopback only. If you're the sole user accessing the dashboard over SSH port forwarding, this is sufficient and shippable today. Level 2 adds Cloudflare Tunnel plus Access for identity-aware edge protection โ€” ideal for small teams of two to five people who trust each other but can't share a token via Slack DM forever. Level 3 introduces a secrets manager so credentials never touch disk in plaintext, addressing compliance concerns around SOC 2 or ISO 27001. Level 4 is enterprise: SSO integration, trusted-proxy auth with the tunnel daemon containerized in its own network namespace for non-loopback source IPs, device posture checks via WARP, and SSH certificates issued post-SSO instead of authorized_keys sprawl. The key insight is that each level ships independently โ€” you don't owe the next tier until your situation changes.

What Actually Gets Exploited

The risk surface on a public VPS breaks down in order of likelihood: automated port scanners hitting open web ports within minutes (fix: outbound tunnel, no inbound ports to probe), dashboard access without identity verification (fix: Cloudflare Access or Tailscale ACLs at the edge), leaked shared tokens from past employees who were never offboarded properly (fix: layered auth so a stolen token alone doesn't get you in), prompt injection through chat channels where a malicious message tricks an unrestricted agent into modifying gateway config or reading files outside its workspace (fix: deny control-plane tools, restrict file access to workspace directory, isolate sessions between users), and plaintext secrets on disk readable by any compromised user account or leaked backup. The article makes the point that for most small teams, nation-state attackers aren't the threat โ€” it's access that should have been revoked three jobs ago.

The Tunnel Decision: Cloudflare vs Tailscale

Two options dominate the tunneling conversation. Cloudflare Tunnel plus Access provides a public hostname protected by identity verification, DDoS absorption at the edge, and CDN performance for free in most cases. The tradeoff is traffic flows through Cloudflare and you need to move DNS there (or at least the relevant subdomain). If you're already running on Cloudflare infrastructure, this is the natural path. Tailscale creates device-to-device access over WireGuard with no public hostname required โ€” devices on your tailnet reach each other directly. The tradeoff: every user needs Tailscale installed and there's no identity-aware edge protecting a public URL. Great for "only our managed devices can reach this, period." Rolling your own with nginx and Let's Encrypt is viable at Level 1 but reintroduces certificate management, open port exposure, and DDoS responsibility that tunnels abstract away.

Two Traps That Waste Hours

The post documents two specific gotchas that tripped up the author. First: many cloud VMs have a working public IPv4 address but no functional IPv6 path, yet Node.js defaults to using whatever DNS resolves first โ€” often an unreachable IPv6 address. The symptom is misleading: "DNS lookup failed" for the LLM provider endpoint when it isn't actually a DNS failure at all. The fix is forcing Node to prefer IPv4 with a single environment variable. Second: subscription-backed providers (ChatGPT Plus/Pro accounts rather than API keys) route some paths through bot-mitigation layers that return HTML block pages instead of JSON API responses, which the gateway then reports as connection errors masking the real problem. The solution is bypassing the gateway entirely and testing upstream endpoints directly with curl to see what actually returns.

Key Takeaways

  • Start at Level 1 (personal) and graduate only when your situation demands it โ€” don't let a checklist bully you into premature complexity
  • No single security layer should be your only defense โ€” layered auth means an attacker must break multiple independent systems to reach the gateway
  • The shared bearer token is fine at Levels 2-3 as long as Cloudflare Access or Tailscale handles identity at the edge first
  • Trusted-proxy per-user auth requires containerizing the tunnel daemon in its own network namespace so requests don't appear from loopback (127.0.0.1) โ€” this is Level 4 architecture, not day-one complexity
  • Quarterly access reviews and an offboarding runbook are the highest-leverage operational habits at small team scale

The Bottom Line

Most self-hosting security guides hand you a checklist of commands without explaining why each layer matters or when to stop adding more. This post flips that โ€” it gives you the decision framework first, then points to a reusable setup prompt for Claude Code, Cursor, or Codex that implements all four levels interactively on any fresh Linux VPS. The takeaway: security is a stack, not a switch. Layer it deliberately and ship at Level 1 today rather than stalling forever trying to architect enterprise-grade auth for a two-person team.