DEV Community

time-scout
time-scout

Posted on

How I Secured an Autonomous AI Agent on Oracle’s Free Tier (Without MicroVMs)

#openclaw #security #ai #agents

Oracle Cloud’s "Always Free" tier is an absolute goldmine for self-hosters. Getting an Ampere A1 ARM64 instance with 4 Cores and 24GB of RAM for exactly $0/month is perfect for running LLMs and AI agents.

Recently, I decided to self-host OpenClaw, an autonomous AI agent. But there was a massive catch.

Autonomous AI agents are inherently dangerous. They execute LLM-generated code, interact with APIs, and hold your highly sensitive keys (OpenAI, Anthropic, Telegram). If an LLM gets tricked via a prompt injection, it could execute a malicious payload.

The industry standard for isolating risky workloads is using MicroVMs (like Firecracker KVM).
The problem? Oracle’s Ampere A1 instances do not support nested virtualization or KVM.

If you just spin up a standard Docker container for your AI agent on Oracle Cloud, you are basically begging for a container escape or a Server-Side Request Forgery (SSRF) attack.

Here is how I built a "Defense-in-Depth" architecture using Terraform and Ansible to lock down the AI agent without needing MicroVMs—and the hidden Oracle networking quirk that almost ruined it.

🛑 The SSRF Trap: Oracle’s Hidden InstanceServices Chain

My biggest fear wasn't just a container escape; it was SSRF. If an attacker tricks the AI agent into curling http://169.254.169.254 (the Cloud Instance Metadata Service - IMDSv2), they can steal the cloud IAM tokens and take over the entire Oracle account.

To prevent this, I wrote an Ansible task to add a persistent iptables rule that drops all traffic from the container's user to the metadata IP:

iptables -A OUTPUT -m owner --uid-owner 232071 -d 169.254.169.254 -j DROP
Enter fullscreen mode Exit fullscreen mode

(Note: 232071 is the SubUID mapped to the Rootless Docker container).

I thought I was safe. I ran a security audit on the live server, pinged the metadata IP from inside the container, and... it returned the cloud credentials. The DROP rule completely failed.

Why?
It turns out Oracle's default Ubuntu images come with a pre-configured, hidden iptables chain called InstanceServices. This chain explicitly ALLOWS traffic to the metadata API, and it sits at the very top of the routing logic. Because I used -A (Append), my DROP rule was placed after Oracle’s ALLOW rule. The traffic never even reached my block.

The Fix:
I had to update the declarative configuration to use -I (Insert) instead of Append. This forces the DROP rule to the absolute top of the OUTPUT chain, successfully overriding Oracle’s default behavior and plugging the SSRF hole.

iptables -I OUTPUT 1 -m owner --uid-owner 232071 -d 169.254.169.254 -j DROP
Enter fullscreen mode Exit fullscreen mode

🛡️ The Defense-in-Depth Architecture

Since KVM wasn't an option, I had to build a multi-layered security onion. I packaged the entire setup into a Zero-Touch IaC template using Terraform (for the cloud hardware) and Ansible (for OS hardening and container deployment).

Here are the 3 pillars of this setup:

1. Extreme Container Isolation (Rootless Docker)

Running the Docker daemon as root was out of the question.

  • Rootless Mode: The entire Docker daemon runs in user space. Even if a payload achieves root inside the container, it only has unprivileged user access (UID 1000) on the host.
  • Immutable FS & No-Exec RAM: The agent's root filesystem is mounted as read_only: true. Temporary directories (/tmp) are mounted in RAM but strictly flagged with noexec and nosuid. Even if malware is downloaded, it cannot be executed.
  • Privilege Dropping: All Linux capabilities are dropped (cap_drop: ALL).

2. Zero-Trust Networking (Tailscale)

I wanted the agent to be completely invisible to the public internet.

  • Default Deny: The Oracle VCN (Virtual Cloud Network) blocks all inbound traffic except SSH (which is guarded by Fail2Ban).
  • WireGuard Mesh: The OpenClaw API port is bound strictly to 127.0.0.1. The only way to securely access the agent's web UI or API is through a Tailscale private mesh network provisioned automatically via Ansible.

3. Messenger Whitelisting

The agent receives commands via Telegram using Long Polling (no open inbound ports). Authorization is highly deterministic: any message from a Telegram ID not explicitly whitelisted in the environment variables is silently dropped before the LLM even sees it.

🚀 Open Source Release

I’ve open-sourced the complete, sterile Terraform + Ansible templates. You can deploy this entire hardened architecture on your own Oracle Free Tier instance in about 5 minutes with just two commands (terraform apply and ansible-playbook).

🔗 GitHub Repository: time-scout/openclaw-oracle-secure-quickdeploy

I Need Your Help! (Challenge)

While I consider this a highly secure balance for running AI agents without MicroVMs, I know there is always room for improvement.

If you are a DevOps or Security engineer, I challenge you to review the Rootless Docker + iptables setup. I’ve opened a few good first issue tickets in the repo (including adding AWS Free Tier support and writing automated tests for the SSRF rules).

Let me know what you think in the comments or drop a star on the repo if you found the Oracle InstanceServices quirk interesting!

Top comments (0)