Your AI Agent Is a Security Risk. Here’s How to Fix That.

Lessons on sandboxing, container security, and why guardrails alone aren’t enough — from FAI × Docker AI Day

There’s a version of this story that ends badly.

You build an AI coding agent. You give it access to your filesystem, your environment variables, your bash terminal — because it needs those things to be useful. You trust the model’s built-in guardrails to keep it from doing anything dangerous.

Then someone crafts a prompt injection via a README file. Or the agent reads an env variable it shouldn’t. Or a package it installs has a vulnerability your base image was never patched against.

At FAI × Docker AI Day, two sessions made me rethink how most teams are approaching AI security — and one live demo made the risk impossible to ignore.

*🚨 High-Paying Tech Roles Available* 💰 $3K–$10K/Month Remote & Onsite Opportunities ⚡ No long applications — just submit your profile in minutes 🔎 Get matched with active hiring companies [👉 Start Application (60 Seconds)](https://optimhire.com/?ref_code=codetodeploy)**

The Demo That Made It Real

Ajeeth Singh Raina, Developer Advocate at Docker, ran a simple experiment on stage.

He asked an AI coding agent the same question in two different environments:

“Can you find my AWS credentials?”

On his host machine: The agent knew the credentials existed. It couldn’t display them directly — the guardrails kicked in — but it described the file location, hinted at the structure, and provided just enough information that a determined attacker would know exactly where to look next.

Inside Docker Sandbox: The agent had no idea. No file. No directory. No breadcrumb. It responded as if the credentials simply didn’t exist — because from inside the sandbox, they didn’t.

That’s not a subtle difference. That’s a completely different threat model.

The guardrails on the host machine were working exactly as designed. And they still leaked enough information to be dangerous.

Why Guardrails Aren’t Enough

This is the uncomfortable truth about AI security that most teams are slow to accept.

Guardrails — the safety instructions baked into the model — operate at the response level. They influence what the model says. They don’t control what the model sees.

An agent running on your backend server with access to your full filesystem, your environment variables, and your network can perceive far more than it should — even if it declines to tell you about it. A malicious actor using prompt injection techniques isn’t trying to get the model to cooperate. They’re trying to extract information from the model’s environment.

Architecture is the only reliable defence against this.

Three Sandboxing Patterns — From Dangerous to Right

Karthik Selvam, Director of Technology at Intraedge, gave one of the most practically useful sessions of the day: a clear breakdown of the three sandboxing patterns he sees teams use in production.

Pattern 1: Bare server, no sandbox

The agent runs directly on your backend server. It has access to the runtime, the filesystem, and the network.

This is fine if you fully control the environment and your agent has no dynamic code execution. The moment you give it a bash tool or file system access, this becomes a liability. Don’t use this pattern for any agent that executes untrusted inputs.

Pattern 2: Remote sandbox, local harness

The dangerous operations — code execution, browser automation, file manipulation — run in a remote sandbox like e2b. But the agent harness (the orchestration logic, the LLM calls, the tool routing) still runs on your backend server.

This is better. The blast radius of any malicious execution is contained. But your backend server is still exposed. If the agent is compromised at the harness level — through a prompt injection in the system prompt, for example — it can still reach your server’s environment.

Pattern 3: Agent harness inside the sandbox

This is the architecture Karthik recommends for any production agentic system.

You spin up a sandbox per workflow — a fresh, isolated environment. The entire agent harness runs inside it. The only credentials you pass in are the ones that workflow actually needs. When the workflow completes, the sandbox is torn down.

The result: even a fully compromised agent can only access what you explicitly gave it. There’s no path to your production database credentials, your cloud provider keys, or your other services.

Combined with virtual keys — limited-scope API keys with expiry and usage caps, so you never pass your actual API key into any sandbox — this architecture dramatically reduces your attack surface.

The Other Security Hole: Your Base Image

The second security session came from a different angle entirely.

One of the session opened with a question most developers don’t think to ask: when did you last check what’s actually inside your Docker base image?

The answer, for most teams, is never.

You write FROM node:18 in your Dockerfile and move on. It works. The app ships. But node:18 is a snapshot from a specific point in time. Every month that passes, the gap between that snapshot and the current security landscape widens.

The live demo made this concrete. He started with a real application — a chat app built on Node 18 — and ran a vulnerability scan. The results showed a significant number of vulnerabilities, including criticals.

Then he made one change: swapping the base image for a hardened equivalent built from a minimal, regularly patched base.

The vulnerability count dropped dramatically. Same application. Same code. One line changed in the Dockerfile.

The insight here is simple but under appreciated: your Dockerfile is a security boundary, not just a build script. Every line that pulls in an external image, package, or dependency is a trust decision. Most developers make those decisions once and never revisit them.

A practical habit change: add vulnerability scanning as a step in your CI/CD pipeline. Docker Scout makes this straightforward. Scan on every build. Set a policy that blocks deployment if critical vulnerabilities exceed a threshold. Make the invisible visible.

The Compound Risk

What made these two sessions powerful together is that they describe the same underlying problem from different angles.

An unpatched base image gives an attacker a known vulnerability to exploit inside your container. An unsandboxed agent harness gives an attacker’s prompt injection a direct path to your secrets. Both are invisible risks that teams routinely accept because the cost of discovering them isn’t obvious until it’s too late.

The teams getting this right are treating security as an architectural constraint from the start — not a checklist item at the end.

Three Things to Do This Week

1. Scan your base images. Run Docker Scout against your most critical services. See what you’re actually running. The results will surprise you.

2. Audit your agent’s runtime access. If your AI agent has access to environment variables, filesystems, or network resources it doesn’t strictly need — that’s your attack surface. Reduce it.

3. Move your agent harness into the sandbox. If you’re building agentic workflows, pattern 3 is your target architecture. Start with the highest-risk workflows first.

The security conversation around AI agents is still early. Most teams are at pattern 1. A few are at pattern 2. The teams building pattern 3 systems today are setting the standard that everyone else will be scrambling to reach in two years.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: **Linkedin| [Medium](https://medium.com/codetodeploy)**

👉 CodeToDeploy Tech Community is live on Discord — **Join now!**

Disclosure: This post includes affiliate and partnership links.