I Deployed OpenClaw on AWS and Here's What I Found as a Cloud Security Engineer

Part 1 of a series: Secure setup, real findings, and attack surface analysis of an autonomous AI agent on AWS Lightsail.

AWS just announced the general availability of OpenClaw on Amazon Lightsail — an open-source, self-hosted autonomous AI agent that connects to WhatsApp, Telegram, Discord, and executes tasks independently: running code, managing files, browsing the web.

The community is fired up testing it. So did I — but with a Cloud Security Engineer hat on.

This post isn't about how to use OpenClaw as an assistant. It's about what I found while setting it up from a security perspective, what decisions I made, and why.

What exactly is OpenClaw?

Before talking security, let's align on concepts.

An LLM (like Claude or GPT) receives a prompt and returns text. That's it.

An autonomous agent is different: it has access to tools (terminal, browser, APIs), decides the order in which to use them, interprets the results, and acts — without you directing each step. The LLM is the "brain," but the agent is the full system that operates in the real world.

OpenClaw is exactly that: an agent running on your server, using an LLM (in this case via Amazon Bedrock) as its reasoning engine, capable of executing tasks autonomously through messaging channels.

That autonomy is what makes it powerful. And also what makes it interesting from a security standpoint.

The Lightsail Setup

AWS packaged OpenClaw as a Lightsail blueprint — meaning you can have an instance running in minutes with no manual configuration.

What I saw in the wizard (and what caught my attention)

The SSH keypair:

Lightsail gives you two options: let AWS generate the keypair, or upload your own.

The security recommendation is clear: generate your own locally.

ssh-keygen -t ed25519 -C "openclaw-sandbox"

Why? When AWS generates the keypair, the private key is created on their servers and travels to you for download. That transmission moment is an avoidable risk. If you generate it yourself, the private key never leaves your machine.

The analogy: the public key is the padlock you put on the server. The private key is the key only you hold. Anyone can see the padlock, but no one else can open it.

💡 Remember: always run chmod 400 on your private key. If it has 644 permissions, other system users can read it — and the SSH client itself will warn you.

The firewall (Security Group):

By default, Lightsail opened ports 80, 443, and 22 to 0.0.0.0/0 — any IP in the world.

For a personal sandbox that's unnecessary. I changed all three rules to restrict them to my IP only:

curl ifconfig.me  # get your public IP

Less exposed attack surface = less blast radius if something goes wrong.

First Finding: Outdated OS

When I connected via SSH, the welcome message was straightforward:

44 updates can be applied immediately.
31 of these updates are standard security updates.

The AWS blueprint shipped with 31 unpatched security updates. Including a kernel patch and intel-microcode update.

Why does the kernel matter? Because it's the core of the OS — it controls memory, processes, and permissions. Known kernel vulnerabilities like Dirty Pipe or Spectre/Meltdown allow privilege escalation or reading memory from other processes.

On a server running Docker containers (like OpenClaw), an unpatched kernel can be exploited for a container escape — breaking out of the isolated container and taking full control of the host.

The fix is simple:

sudo apt update && sudo apt upgrade -y
sudo reboot

🔍 Finding #1: OpenClaw blueprint on Lightsail deployed with outdated kernel and system libraries. Any client using it in production without applying patches is exposed to known CVEs.

The Most Interesting Part: OpenClaw Security Settings

After setup, OpenClaw presents 5 security configurations. This is where things get interesting.

1. File & folder protection     → Status: ✓ Protected
2. Browser remote control       → Status: ✓ Disabled
3. Exec host policy             → Status: ~ Not set (defaults to sandbox)
4. Shell command approval       → Status: ~ Unrestricted
5. Access token                 → Status: ~ Never rotated

Setting 3: Exec host policy

This controls where the agent executes shell commands.

• sandbox (default): commands run inside an isolated Docker container.
• gateway: commands run directly on the server OS.

The blast radius difference is enormous. With gateway, if the agent is compromised, the attacker has direct access to the filesystem, environment variables, the IAM role — everything.

Setting 4: Shell command approval

This controls whether the agent asks for permission before executing a command.

• deny: blocks all shell commands.
• allow: executes them freely without asking.

The attack chain you can't ignore

Here's the most dangerous scenario, and it's completely possible if you don't configure things properly:

exec host policy: gateway  +  shell command approval: allow

Result: the agent can execute any command directly on the server, without isolation and without asking for permission.

Add a prompt injection attack on top of this — where someone inserts malicious instructions into content the agent consumes (an email, a file, a web page) — and the attacker can take control of the server without you noticing.

This chaining of weak configurations is called attack chaining, and it's exactly the type of analysis that needs to happen before putting an agent into production.

🔍 Finding #2: The combination of exec host policy: gateway + shell command approval: allow eliminates all agent isolation layers. In production, this represents a critical risk.

Setting 5: Gateway Token visible in the dashboard

The Gateway Token is the agent's "password" — whoever has it controls OpenClaw completely.

The problem: it's displayed in plaintext in the dashboard.

Any screenshot of the dashboard, any screen recording, anyone looking over your shoulder — compromises access to the agent.

AWS recommends rotating it frequently and not hardcoding it in configuration files. But the fact that it's visible by default in the UI is a design consideration worth noting.

🔍 Finding #3: The Gateway Token is displayed in plaintext in the dashboard. Combined with an internet-exposed dashboard, this represents direct credential exposure.

IPv6 Enabled by Default

A detail that flies under the radar: the blueprint comes with dual-stack (IPv4 + IPv6) enabled by default.

The security problem: many firewall rules are written with IPv4 in mind. IPv6 traffic can go unnoticed if you're not reviewing both protocol families in your controls.

If you're not using IPv6, disable it. Unnecessary attack surface.

What's Installed in This Blueprint?

Among the services restarted after apt upgrade, an interesting one appeared:

systemctl restart apache2.service

The OpenClaw dashboard runs on Apache2. That means Apache is another attack surface to consider — with its own CVEs and configurations to review.

An attacker familiar with Apache vulnerabilities could attempt to bypass gateway authentication without ever needing the token.

Findings Summary

#	Finding	Severity
1	Blueprint deployed with outdated kernel and system libraries (31 pending security updates)	High
2	gateway + allow combination eliminates isolation and command approval	Critical
3	Gateway Token displayed in plaintext in the dashboard	High
4	IPv6 enabled by default with no option to disable it in the wizard	Medium
5	Apache2 as web server with no documented hardening	Medium

Secure Configuration Recommendations

If you're deploying OpenClaw in a real environment:

1. Generate your keypair locally — never let the provider generate it for you.
2. Restrict the firewall to known IPs from the very beginning.
3. Apply patches immediately after deploy — don't trust that the blueprint is up to date.
4. Keep exec host policy on sandbox — Docker isolation is your first line of defense.
5. Set shell command approval to deny or require explicit approval — human in the loop for irreversible actions.
6. Rotate the Gateway Token regularly and never expose it in screenshots.
7. Disable IPv6 if you're not using it.
8. Don't expose the dashboard to the internet — if you need remote access, use a VPN or secure tunnel.

Why This Matters

Autonomous AI agents are arriving in production at companies across LATAM. OpenClaw is just the first of many.

Most teams deploying them aren't thinking about attack surface, blast radius from a misconfiguration, or how a prompt injection can chain with a misconfiguration to fully compromise a server.

That gap is exactly where Cloud Security Engineers need to be.

What's Next

In Part 2 I'll explore the surfaces we didn't touch today: Channels (WhatsApp/Telegram integrations), Agents, Cron Jobs, and how each one expands the system's attack surface.

I'll also run a full threat model using the OWASP Top 10 for Agentic Applications 2026 and the AWS Agentic AI Security Scoping Matrix.

This article is part of the Road to CloudSec LATAM series. Original version in Spanish on Hashnode.

Have questions or found something different in your deployment? Drop a comment — I'm building the complete threat model for Part 2.

About the Author

Gerardo Castro is an AWS Security Hero and Cloud Security Engineer focused on LATAM. He believes the best way to learn cloud security is by building real things — not memorizing frameworks. He writes about what he builds, what he finds, and what he learns along the way.

🔗 GitHub: https://github.com/gerardokaztro
🔗 LinkedIn: https://linkedin.com/in/gerardokaztro