Run OpenClaw on a VPS Without Exposing Your API Keys

A chain vulnerability recently exposed roughly 245,000 public AI agent servers running OpenClaw. The lesson is blunt: you should not hand an autonomous agent your real API keys. If the execution environment is compromised, it's game over. This walkthrough shows the alternative, a two-box setup on DigitalOcean where OpenClaw runs autonomously while Agent Vault brokers every credential at the network boundary, so the agent box never holds a single real token.

In a default OpenClaw installation, every credential you save lands on disk in plain text. A real Slack app token, a real Slack bot token, your Anthropic API key, all of it sitting side by side with the agent on the same machine. That is the standard deployment shape for an autonomous agent, and it is exactly what makes it dangerous.

If someone prompt-injects your agent, this becomes a very bad day. The attacker gets a foothold on the execution environment and walks out with every plain-text key on the box. That is credential exfiltration, and it is the failure mode we are designing this whole architecture to make impossible.

The fix is two cheap VPS instances on a DigitalOcean private network. The first box runs OpenClaw, our AI agent. The second runs Agent Vault, our credential broker. The agent box holds only placeholders, harmless strings like `__GITHUB_TOKEN__` or `__ANTHROPIC_API_KEY__` that look like tokens but are not. They are safe to leave in a config file on disk.

The broker box holds the real credentials, encrypted at rest with a master password and decrypted into memory only when a request flows through that needs them. When OpenClaw makes an outbound HTTPS call, an `HTTPS_PROXY` variable routes it through Agent Vault first. The broker scans the request, finds the placeholder, swaps in the real token, and forwards it upstream. The upstream service sees a normal authenticated request and responds as usual. The agent gets the response data without ever having seen the credential. That swap is the entire trick. This pattern is called credential brokering.

Why not just two Docker containers on the same host? Because kernel-level vulnerabilities are real and AI agents are creative. A colleague put it well: a determined agent will eat through your containers. Keeping the agent and the broker on two separate machines means a compromise of the agent box cannot reach the secrets on the broker box.

The topology reinforces this. The OpenClaw box gets an egress firewall: the only way out is through the broker on its private subnet, with no direct route to the public internet. A compromised agent has nowhere to send anything except back through the broker, and the broker only injects credentials for upstreams it knows about. Both boxes get ingress lockdown too, with SSH from your laptop as the only public-facing port. Everything else lives on the private subnet.

Before provisioning anything, gather your upstream API tokens in one place. You will paste them into Agent Vault later. Start with three:

You do not need the Slack bot and app tokens yet. Those get created later, once OpenClaw's setup wizard generates a Slack app manifest for you.

First, generate an SSH key with an empty passphrase, which you will use to reach both droplets. Then create a VPC network in DigitalOcean to act as your private network, picking a data center region.

Inside that VPC, create two droplets in the same region. The smaller size is fine for around eight dollars a month; a larger size is faster. Paste in the public half of your SSH key, and name the boxes clearly, one `openclaw-box` and one `av-broker`. Once both are running, confirm they sit on the same subnet by checking their private IPs. You will substitute those private IPs into the commands throughout the rest of the setup.

Before installing anything, lock the boxes down with a firewall. Create inbound rules carefully:

Outbound rules can stay at their defaults. Apply this firewall to both droplets. The result: the broker is reachable only from the agent box over the private network, and both boxes accept SSH only from you.

SSH into the broker box and install Agent Vault, a single Go binary that is open source and part of the Infisical project. Run it inside a `tmux` session so it keeps running after you disconnect.

Start the server bound to the broker's private IP, which means Agent Vault is reachable only from inside the VPC and does not exist from the public internet at all. Turn on debug log level so you can watch per-request proxy events. On first run it asks for a master password (set a strong one for any production instance) and an admin account for the UI. The master password encrypts and decrypts the entire credential database. Once it is up, Agent Vault's transparent proxy listens on the private IP at port `14322`, and the admin UI listens on `14321`.

To reach the UI safely from your laptop, open an SSH tunnel that forwards your local `14321` to the broker's private IP on `14321`. The terminal will look like it hangs, which means the tunnel is working. Now `localhost:14321` in your browser talks to the Agent Vault instance through the tunnel, and you log in with your admin credentials.

Agent Vault has a few concepts worth understanding before you wire it up:

Add your credentials first (Anthropic, GitHub, Notion, with Slack to follow). Then create four services:

One gotcha: placeholders must match exactly. Whatever string you use in Agent Vault, such as `__SLACK_APP_TOKEN__`, has to be the identical string in your OpenClaw configuration.

With the vault configured, create an agent. In the UI, add an agent called `openclaw-agent` and grant it access to the `prod` vault as a proxy. This produces an agent token that lets only that agent proxy requests through the vault, applying the substitution rules you set up. The token scopes access to `prod` and nothing else. Keep these values handy; you will need them when wiring the OpenClaw box.

SSH into the OpenClaw box. First install the Agent Vault CLI here too: you will not run a server on this box, but the CLI wraps OpenClaw's commands with the Agent Vault proxy variables. Then run the OpenClaw installer, which launches a setup wizard.

This is the critical part: every time the wizard asks for a token, give it a placeholder, not a real key. Use `__ANTHROPIC_API_KEY__` for the model provider, choose Anthropic with an API key, and pick a model (a smaller model like Haiku or Sonnet keeps costs down). For the messaging platform, choose Slack in socket mode. The wizard generates a large JSON blob, a Slack app manifest, that you should keep, because it makes the Slack setup trivial.

Create the Slack app from that manifest at api.slack.com/apps: choose "from a manifest," select your workspace, paste the JSON, and create. Install the app to your workspace, then grab the bot token from OAuth and Permissions and generate an app-level token under Basic Information with the `connections:write` scope. Paste both real tokens into Agent Vault's credential store. Back in the OpenClaw wizard, enter the placeholder strings for the Slack bot and app tokens. Leave channel access open for the demo, and skip hatching the agent for now, since the gateway runs as a systemd service that needs to be wrapped first.

As a sanity check, look at OpenClaw's config folder. The keys that were plain text in a default install are now all dummy placeholders.

Two final pieces connect OpenClaw to the broker. First, an environment file holding the placeholder values, the `prod` vault name, the agent token from the UI, and the private IP of the broker box. Lock it down with `chmod 600` so only root can read it.

Before going live, test the substitution by hand. Export the Agent Vault variables in your shell and wrap a `curl` to `api.github.com` (with a dummy token) in the Agent Vault CLI. A successful response from GitHub confirms the broker is swapping in the real credential correctly.

Second, a systemd drop-in for the OpenClaw gateway. It pulls in the env file, clears the default start command, and replaces it with one that wraps the gateway in `agentvault run`. Enable `loginctl enable-linger` for root so the service survives a logout, then reload and restart the gateway. Once it comes up, Agent Vault is connected and every outbound call OpenClaw makes is brokered.

Invite OpenClaw to a Slack channel and give it a real task: create two GitHub issues in a repo, create a Notion page in an engineering database summarizing them, and reply with all three URLs. As OpenClaw works, it reacts in Slack, eyes while it investigates, an hourglass while it works, a green check when it finishes.

On the broker side, the debug log shows every outbound call: Slack bot token, Slack app token, Anthropic API key, GitHub token, each one injected at the broker's side of the wire. The agent never sees a real token. When OpenClaw reports back with links to the live GitHub issues and the Notion page, you can open them and confirm real tickets in a real database, created through real integrations, by an agent that held nothing but placeholders.

Suppose the OpenClaw box is compromised and an attacker grabs the agent token. In the Agent Vault UI, revoke that agent with one click; its status flips to revoked immediately. Ping OpenClaw in Slack and it goes silent, because Agent Vault is no longer brokering credentials for it. The real keys were never on the box to begin with, and now the brokering path is cut too. To recover, mint a new token, drop it into the env file, and restart the gateway.

This was built for OpenClaw because a recent attack made the problem concrete, but Agent Vault is agnostic. If your agent speaks HTTPS, and they all do, the broker can front it: Claude Code, Cursor, Codex, your own internal agents, all the same pattern. Placeholders on the agent, real credentials in the broker. It scales sideways too, to fleets of ephemeral agents that each get their own revocable identity and see only the vault they were granted.

Credential brokering is the paradigm; OpenClaw is just the agent we picked for this video. Both OpenClaw and Agent Vault are open source. The keys OpenClaw needs to run were never on its machine, and they never should be. Learn more about the approach in the Infisical docs.