A self-hosted agent gateway is a powerful thing to leave on the open internet. Exposed instances get found, and an agent with tools and keys is a bigger prize than a plain web app. This checklist covers the settings that matter most before you go live.
Do not expose it directly to the internet. Bind the gateway to loopback or a private network like Tailscale, require authentication in front of it, store keys as least-privilege secrets outside your code, keep the runtime updated, and limit what the agent can reach so a mistake or compromise has a small blast radius.
Biggest risk
An agent gateway open to the internet
First fix
Bind to loopback or a private network
Key handling
Least-privilege secrets, never in code
Goal
A small blast radius if something slips
Self-hosted gateway hardening checklist
Area
Do this
Why it matters
Network
Bind to loopback; reach it over Tailscale or a VPN.
Keeps the agent off the public internet.
Auth
Require a token or an authenticated proxy.
Stops anyone from driving your agent.
Secrets
Least-privilege keys in a secret store.
Limits the damage if one credential leaks.
Updates
Patch the runtime on a schedule.
Closes known holes before they are used.
Blast radius
Non-root user, spend caps, human review.
Keeps a single mistake small.
Do not bind it to a public interface
The most common mistake is running the gateway on 0.0.0.0 and reaching it by public IP. Security researchers routinely find self-hosted agent gateways exposed with no authentication, which puts an agent holding tools and credentials one scan away from strangers. Bind it to localhost, and reach it over a private network instead.
Bind the gateway to 127.0.0.1, not 0.0.0.0.
Reach it over Tailscale, a VPN, or an SSH tunnel, not a public port.
If it must be public, put it behind a reverse proxy that enforces auth and TLS.
Require authentication in front of the agent
An agent endpoint with no auth is an open door. Put authentication in front of it so only you, or your own systems, can send it instructions.
Require a token or an authenticated proxy for every request.
Do not treat an obscure URL or port as a secret.
Rotate the credential if it is ever shared, logged, or leaked.
Handle keys and secrets carefully
An agent's model keys, tokens, and integration credentials are the real target. Treat them as least-privilege secrets that live outside your code and can be rotated on their own.
Store secrets in the environment or a secret store, never in the repo or the prompt.
Give each integration the narrowest scope it can work with.
Use separate credentials per agent so one leak does not unlock everything.
Keep it updated and limit the blast radius
Agents move fast and so do their dependencies. Patch the runtime, and assume any single agent could misbehave, so nothing it can reach is catastrophic on its own.
Update the runtime and dependencies on a schedule, not just after an incident.
Run the agent as a non-root user with only the file and network access it needs.
Set spend limits and human review on any action that touches money or customers.
Where managed hosting fits
If keeping all of this current is not how you want to spend your time, managed hosting does it by default. Qoren runs OpenClaw and Hermes in isolated environments with authentication, secret storage, updates, and hard spend caps handled for you, so the secure path is the default one.
An agent is not a static site. It holds keys, can use tools, and can take actions. If its gateway is reachable without authentication, anyone who finds it can make it act with your credentials, which is why exposed instances are a documented and recurring problem.
Run OpenClaw or Hermes without managing infrastructure.
Deploy a managed agent environment, configure the runtime, and keep the agent online without Docker, VPS setup, or server maintenance.
