How to Run AI Agents in the Cloud Securely

AI agents aren't just chatbots anymore. They write code, install packages, spin up servers, manage files, and interact with third-party APIs - all without asking for permission first. That autonomy is what makes them powerful. It's also what makes them dangerous if you run them without proper isolation.

If your agent runs on a shared server, a bad prompt or a hallucinated command could wipe out files, leak credentials, or take down your entire infrastructure. This isn't hypothetical - it happens every day to teams that treat agent execution like a regular API call.

This guide walks through the real risks and the right way to run agents in the cloud.

---

Why AI agents need more than a regular server

A traditional web app receives requests, processes them, and returns responses. The surface area is predictable. An AI agent, on the other hand, decides what to do at runtime. You can't predict every command it will run or every file it will touch.

Here's what makes agents different:

• They execute arbitrary code. An agent with a code execution tool can run anything - including rm -rf / or curl to an attacker's server.
• They chain actions together. One bad decision compounds. An agent might install a malicious package, then use it to exfiltrate data.
• They handle untrusted input. If your agent processes user messages, those messages are potential prompt injections that could hijack the agent's behavior.
• They persist state. Unlike a stateless function, agents hold memory, credentials, and conversation history. A compromised agent is a compromised identity.

Running this on your application server - or even in a Docker container on shared infrastructure - is asking for trouble.

---

The problem with Docker containers for agent execution

Docker is great for packaging and deploying applications. It's not designed for security isolation. Here's why:

Shared kernel. Every container on a host shares the same Linux kernel. A kernel exploit in one container can compromise every other container on the machine. For AI agents running arbitrary code, this is a real attack vector.

Escape vulnerabilities. Container breakouts have happened repeatedly - CVE-2019-5736 (runc), CVE-2020-15257 (containerd), and others. These aren't theoretical; they've been exploited in the wild.

Overprivileged by default. Containers often run as root, have access to the Docker socket, or share volumes with the host. A clever agent could mount host directories and read secrets it was never supposed to see.

No memory isolation. Containers share the host's memory space at the hardware level. Side-channel attacks like Spectre and Meltdown can cross container boundaries.

For running a web server, Docker is fine. For running an AI agent that executes arbitrary code from untrusted input, you need something stronger.

---

What secure agent execution actually looks like

Real isolation for AI agents requires multiple layers. Here's the security model you should aim for:

1. Hardware-level isolation

Each agent should run in its own virtual machine - not a container, but a real VM with its own kernel, its own memory space, and its own block device. This way, even if the agent achieves root access inside its environment, it can't affect anything outside.

Firecracker microVMs (the same technology behind AWS Lambda and Fargate) achieve this with sub-200ms boot times. You get VM-level security with container-level speed.

2. Zero-trust networking

Your agent's environment should start with no network access to anything internal. No connections to other agents, no connections to your database, no connections to your application server. You explicitly open only the paths you need.

This is the opposite of how most cloud setups work, where everything on the same VPC can talk to everything else. For agents, the default should be "invisible to everything."

3. Encrypted, ephemeral disks

Every agent's disk should be encrypted at rest with a unique key. When the agent's environment is destroyed, the key is destroyed first - making recovery impossible even with physical access to the storage.

4. Scoped permissions

Instead of giving your agent full access to your cloud account, give it a scoped token that limits exactly what it can do - which services it can call, which environments it can create, and which data it can access.

5. Automatic cleanup

Temporary agent sessions should auto-expire. Set a TTL (time-to-live) so that even if something goes wrong, the environment self-destructs after a set period. No zombie processes, no lingering data.

---

How Oblien handles this

Oblien was designed specifically for this use case. Every workspace is a Firecracker microVM - not a container. Here's what that means in practice:

Each agent gets its own VM. Its own kernel, its own memory, its own encrypted disk. A compromised agent can't affect anything outside its workspace.

Zero-trust networking is the default. A new workspace can't talk to any other workspace - even workspaces on the same account. You explicitly create private links between workspaces that need to communicate.

Workspaces boot in milliseconds. You're not waiting minutes for a VM to spin up. Creating an isolated environment for an agent task is nearly instant.

Disks are encrypted per-workspace with a unique key. Each workspace has its own data encryption key. When you delete a workspace, the key is destroyed - cryptographic erasure.

TTLs and auto-cleanup built in. Create a temporary workspace with a 60-second TTL. It runs the agent's task, returns the result, and self-destructs. No cleanup scripts needed.

Scoped API tokens. Your agent gets a token that controls exactly what it can do. It can create workspaces, but only up to certain resource limits. It can access specific workspaces, but not others.

---

The "agent home + task workspace" pattern

The most secure way to run an AI agent is to separate its brain from its hands:

Agent Home - A permanent workspace where your agent framework runs. It holds long-term memory, manages conversations, and makes decisions. It has an API token to manage other workspaces.

Task Workspaces - Temporary, isolated environments that the agent spins up on demand. Need to run code? Create a workspace, run it there, get the result, destroy the workspace. The task workspace is air-gapped - no internet, no access to other workspaces, no access to your data.

This way, even if the agent makes a catastrophic mistake in a task workspace, the damage is contained. Your agent's memory, credentials, and other workspaces are untouched.

---

Quick comparison: Running agents on different platforms

---

What to do next

If you're building with AI agents, stop running them on shared infrastructure. The risk isn't worth the convenience.

1. Audit your current setup. Where does your agent execute code? Can it access your production database? Can it see other users' data?
2. Adopt hardware isolation. MicroVMs give you VM-level security without the VM-level boot time. Firecracker makes this practical.
3. Default to zero trust. Start with no access and add only what's needed. Never share a network between agents that don't need to communicate.
4. Use ephemeral environments. Don't let agent task environments persist. Create, use, destroy. Every time.

Oblien handles all of this out of the box. You focus on what your agent does - we handle making sure it can't do anything it shouldn't.

Get started with Oblien →