Securing agentic workflows: the container approachSecuring agentic workflows: the container approachSecuring agentic workflows: the container approach

The article discusses the security risks associated with running agentic AI tools with full user permissions, which can expose sensitive data such as SSH keys and cloud credentials. To mitigate this "silent security debt," one great option is to use containers, specifically dev containers, to establish a "visibility boundary" based on the principle of least privilege. By implementing a tiered risk model (ranging from local Docker containers for solo projects to ephemeral cloud sandboxes for high-stakes work), developers can achieve better security, reproducibility, and consistency.

AI-native engineering (”AINE”) is reshaping how software gets built. At Nearform, agentic workflows are now at the core of how we deliver. Senior engineers set the direction through specs, tests, and reviews. Agents do the build-out and produce high-quality solutions on timelines that were simply not reachable before.

AINE shifted the developer experience from autocompletion to a fully generated solution. This shift, from tools that suggest to tools that act, comes with drawbacks. Modern agents read and write files, run commands and invoke APIs, and the more accurate and larger the context, the better the agent's output. But if you are not careful, the context could end up encompassing all the data on your machine. Instead, the context should be limited to the only information the agents need to know, following the security principle of least privilege.

Here is where trust quietly becomes the central question of AINE. Many developers run tools like Claude Code, Cursor, or GitHub Copilot with the same permissions as their user account; this is a silent security debt. Running these tools with this level of access gives agents permission to access all folders, including ones such as ~/.ssh or ~/.aws, which can contain production access credentials.

The agents always ask before doing something, but this is more of a UI feature than a real boundary. How can we build real boundaries for agents? And how do we make a structural solution? How can we scale the adoption of agentic workflows without compromising sensitive data?

One possible response is containers. By running agentic AI tools inside containerised environments, developers can achieve safety, reproducibility and auditability of their development environments. But it's worth mentioning that a container, or any other tool we will mention here, does not make an agentic tool trustworthy. What it does is make the boundary of your trust explicit. This shift, from blind hope to managed risk, is what the rest of this article is about, and it is one of the foundational disciplines we keep coming back to on AINE engagements.

When a developer launches an agentic AI tool, that tool uses the same permissions as the user. This means that the agent can access each folder and data that the user owns, as it runs as a child process of the shell. It's a broad attack surface:

• Identity and Access: Your ~/.ssh directory contains the private keys that grant access to production servers, staging environments, and private repositories. An agent with file system access can read these keys as easily as it reads a source file.
• Cloud Infrastructure: Most developers have a ~/.aws/credentials or ~/.azure folder. These files often contain long-lived access keys that grant broad permissions across cloud accounts, which could be leveraged to leak data or spin up unauthorised resources.
• Environment Secrets: We’ve all fallen into the habit of keeping .env files in our project roots for local development. These files are gold mines of sensitive data, such as database passwords, Stripe API keys, and third-party service tokens.
• Configuration Leaks: Our dotfiles (.zshrc, .bash_profile, .vimrc) often contain exported API tokens or hardcoded paths to sensitive tools. These are the first places an automated process looks when trying to understand the environment it's inhabiting.
• Code Integrity: Git signing keys (GPG/SSH) allow an agent to not only write code but to sign it as you, making it nearly impossible to distinguish between a human-authored commit and an AI-generated one in a secure audit log.

This is not an edge case; this is a typical modern development environment.

AI isn't necessarily malicious or designed to leak secrets, but it's autonomous. So a wrong command or a prompt-injection attack could lead an agent to exfiltrate secrets or personal information. Thus, it's very important to give structural boundaries to an agent.

The problem of an over-privileged environment has a solution: a harder boundary. What we need is to move the agent from our machine to a place where we can decide what the agent can access. The container is an easy and secure solution. With a container, we can decide and explicitly define the visibility boundaries rather than just guessing what the agent can see.

Lately, all modern development environments support dev containers. Dev containers are a standardised way to define a full-featured development environment and support packaging the dev environment into a container. Key aspects include:

• Consistency: every developer has the same environment
• Configuration as Code: the dev environment is defined by code (typically devcontainer.json)
• Isolation: the host machine remains clean

If a dev container is well configured and mounts only the necessary project folders, agents can access only this isolated, well-controlled environment. In this way, the agent is effectively sandboxed, with exactly the tools needed to be productive and nothing more, implementing the security principle of least privilege.

But the benefit of this isolation extends beyond security; it solves the fundamental problem of trust and reproducibility. By standardising the environment via a container, we ensure that every developer, every agent run, and every CI job is operating on the exact same foundation. This brings:

• Instant Onboarding: A new developer (or a new AI agent) can spin up a fully configured environment in seconds, rather than spending a day debugging installation scripts.
• Eliminating Drift: You no longer have to worry about “environment drift,” where different team members are using slightly different versions of a runtime or CLI tool.
• Environment as Code: Because the environment is defined in a file, it can be versioned, peer-reviewed in a pull request, and rolled back if a configuration change breaks the workflow.

There are other tools than dev container to implement the safety net for AI agents:

• Cloud-based IDEs like GitHub Codespaces and Gitpod.
• Lightweight environments like smol-machine.
• E2B and Daytona: These provide specialised sandboxes designed to be spun up and torn down rapidly by an API, offering better control over the agent's environment.
• Firecracker/microVMs: These offer hardware-level virtualisation, providing a much stronger security boundary than standard containers.

Some of these tools are designed specifically for AI agent security, while others are designed for wider scopes and can be configured for this specific scope. This is a sparkling moment for these tools, and the industry is adapting to meet the unique demands of agentic AI. The problem is not yet "solved", but rather being actively iterated upon.

To make the discussion concrete, here is a dev container we would consider a reasonable default for a Python project where an agent works.

.devcontainer/devcontainer.json:

{
  "name": "Python Dev",
  "build": {
    "dockerfile": "Dockerfile",
    "args": {
      "PYTHON_VERSION": "3.12"
    }
  },
  "features": {
    "ghcr.io/devcontainers/features/git:1": {},
    "ghcr.io/devcontainers/features/github-cli:1": {}
  },
  "forwardPorts": [8000, 5000, 8888],
  "postCreateCommand": "pip install --user -r requirements.txt || true",
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "ms-python.vscode-pylance"
      ],
      "settings": {
        "python.defaultInterpreterPath": "/usr/local/bin/python",
        "python.terminal.activateEnvironment": true,
        "terminal.integrated.defaultProfile.linux": "bash"
      }
    }
  },
  "remoteUser": "vscode",
  "mounts": [
    "source=python-venv-${devcontainerId},target=${containerWorkspaceFolder}/.venv,type=volume"
  ]
}

.devcontainer/Dockerfile:

ARG PYTHON_VERSION=3.12
FROM mcr.microsoft.com/devcontainers/python:1-${PYTHON_VERSION}-bookworm

# Install extra OS packages commonly needed for Python work
RUN rm -f /etc/apt/sources.list.d/yarn.list \
    && apt-get update && export DEBIAN_FRONTEND=noninteractive \
    && apt-get install -y --no-install-recommends \
        build-essential \
        curl \
        jq \
        git \
        zsh \
        libpq-dev \
        default-libmysqlclient-dev \
        pkg-config \
    && apt-get clean -y && rm -rf /var/lib/apt/lists/*

# Upgrade pip and install commonly-used Python tooling globally
RUN pip install --no-cache-dir --upgrade pip setuptools wheel \
    && pip install --no-cache-dir \
        pipx \
        poetry \
        uv \
        black \
        ruff \
        mypy \
        pytest \
        ipython

USER vscode

WORKDIR /workspace

Running VS Code inside this dev container, the project files live under /workspace/<project-folder> and the venv is mounted as a named volume for performance.

Why does this solution enhance security?

• Least privilege: The agent sees only the workspace. Nothing outside the project folder is mounted into the container: no ~/.ssh, no ~/.aws, no dotfiles, no random .env files from other projects. If the agent tries to cat ~/.aws/credentials, the file simply does not exist.
• No root privilege: The agent runs as a non-root user: remoteUser: vscode. This means even inside the container, the agent does not have full administrative power.
• Only declared ports cross the boundary. forwardPorts makes the network surface between host and container explicit instead of implicit.
• The toolchain is pinned and reviewable. PYTHON_VERSION, the apt packages, and the global pip packages are all in version control. A change to the agent's available tools requires a commit, a diff, and a review, increasing reproducibility and auditability.
• The environment is reproducible and disposable. If something goes wrong, rebuild the container. The host stays clean either way.

This is not a maximum-security setup; there is still network egress, and the agent can read and write everything inside the workspace. It is a sensible default: enough boundary to make the agent's reach explicit, light enough to live with day-to-day.

Not every project needs the same level of security; implementing a high-overhead solution could be overkill. To make this practical, we can consider a tiered model based on the risk profile:

Tier 1: Solo side projects and rapid prototyping

• Recommendation: Local Docker containers.
• Approach: For a developer working alone on a non-critical project, the primary goal is speed and basic isolation. A simple docker run or a basic Compose file is usually sufficient to keep the host OS clean while providing a sandbox for the agent to experiment in.

Tier 2: Team collaboration and production-ready work

• Recommendation: dev containers with explicit restrictions.
• Approach: When multiple developers are involved or the code is moving towards production, consistency is key. By using dev containers, the team ensures the agent operates in a mirrored environment. At this stage, "intentional setup" becomes critical: implementing resource limits (CPU/RAM) and restricting the agent's ability to modify the container's own configuration.

Tier 3: High-stakes, client work, or multi-tenant apps

• Recommendation: Ephemeral cloud sandboxes with strict network controls (e.g., E2B, Daytona, or Firecracker).
• Approach: When the cost of failure is high, such as when handling client data or executing untrusted code in a multi-tenant environment, local containers are not enough. The goal here is "Zero Trust." Every agent session should trigger a fresh, ephemeral sandbox that is destroyed immediately after the task, with egress network filtering to prevent data exfiltration.

In our experience at Nearform delivering AI-native engineering projects, we've found the most difficult challenge isn't the technology, but the "friction vs security" trade-off.

Our experience suggests some takeaways:

• Provide a pre-configured dev container template that is secure by default. In this way, the developers don't need to configure their sandboxes.
• Observability as a second safety layer. Combining container isolation with log streaming of the agent's terminal output is the way to debug why an agent is failing or trying to access something private.
• Avoid configuration drift. Don't change the container manually just to make it work. We advocate for a strict "immutable infrastructure" approach. Update devcontainer.json to add the fix, then rebuild it. Then commit the change and share it with the team.

The goal is not just to use the perfect sandbox tool, but to create a secure and predictable development environment tailored to the agents and the project the developers are working on. This infrastructure, even if it's on the developer machine, must be treated with the same rigour as any other part of the technical stack, something the team explicitly defines, commits to Git and owns.

It's important to be honest: a container, or the other tools mentioned before, does not make an agentic tool trustworthy. Rather, it makes the boundary of your trust explicit. By defining the agent boundaries precisely and programmatically, we move from a state of blind hope to a state of managed risk. That shift in perspective is not just a theoretical ideal: it is a practical, achievable reality.

If you are working through these trade-offs in your own engineering organisation, scaling agentic workflows safely, putting structure around developer environments, or building the platform layer that supports both, we would love to talk. Get in touch with Nearform.