AI agents with shell access: how to move the workflow into isolation

Start with a household rule for access

You would not give an intern keys to your apartment, safe, and server room on day one. Even if the person is smart and motivated, access is granted gradually: first a workspace, then specific systems, then permission for dangerous operations. The same logic applies to an AI agent that can run commands.

When AI only suggests a code snippet in chat, the risk is limited by what a human copies and runs. But a coding agent with shell access already acts inside an environment. It can run npm install, modify files, read environment variables, start tests, make HTTP requests, or accidentally touch the wrong directory. That is no longer a suggestion; it is an operational workflow.

So the migration should not be based on trust in the model. It should be based on boundaries. A good target state is simple: the agent can complete the task, but it cannot see unnecessary data, change unnecessary files, or connect to arbitrary places on the network.

Map the risks by area

The first area is files. If an AI agent works directly in your home directory or in the main repository checkout, it sees more than it needs. The dangerous scenarios are not exotic: broad formatting changes, deleted artifacts, modified IDE configuration, private notes being read, or unrelated files accidentally added to a commit.

The second area is dependencies. The agent may install packages, run postinstall scripts, update lock files, and start local services. This is useful for fast work, but risky when there is no boundary between an experiment and the real working environment.

The third area is network egress. A task might only require access to a package registry and a test API. Without control, however, the agent may contact external domains, download scripts, send diagnostics, or use tools that open network connections on their own.

The fourth area is secrets. GitHub’s write-up on secret scanning shows a familiar problem: secrets spread not only through repositories, but also through tickets, wiki pages, incident notes, bug bounty reports, and other work artifacts. If such data exists on a machine or in CI, the AI agent should not receive it automatically.

The fifth area is persistence. After the task, installed packages, caches, changed configs, background processes, new keys, or temporary files may remain. If the workspace is not disposable, each run accumulates hidden state.

Target state: put the agent in a small lab

A safer minimal architecture starts with a disposable workspace. For each task, create a clean copy of the required repository or subset of files. After completion, keep only the diff, logs, and artifacts that passed review. Delete everything else.

Next, add a sandbox. This might be a container, an isolated CI environment, or a microVM-based approach. The specific tool is less important than the properties: limited access to the host system, controlled mounts, clear write permissions, no access to the home directory, and no access to system sockets unless there is an explicit reason.

Build network access from deny to allow. First remove unnecessary network egress, then add an allowlist: package registry, internal test API, documentation site, or mock services. If the agent needs a third-party API, prefer a proxy with limited operations over a full key.

Secrets should not exist inside the agent environment just because it is convenient. For local work, use test tokens or short-lived access. For CI, use a separate credential set with minimum permissions. For production-like tasks, require manual approval and a separate path for granting access.

Logging is not about punishment; it is about replayability. The team needs to see which commands the agent ran, which files it changed, which packages it installed, and where it connected over the network. Without that, it is hard to distinguish useful automation from accidental damage.

Rollout for the team

Start locally. Do not allow AI agents to run with full access to a laptop. Create a template: new workspace, restricted directories, test secrets, network allowlist, command log. Add one rule: a human reviews the diff before merge or before applying changes to the main branch.

The second stage is CI. An agent in CI should run as a separate job with minimal permissions. It should not automatically receive every pipeline secret. If it needs to open a pull request, create an issue, or call an API, use a narrow and short-lived token.

The third stage is production-like work. Here the agent can analyze logs, prepare commands, write a migration draft, or suggest a rollback plan. But actions that change data, infrastructure, or access should go through manual approval.

When to stop the agent and call a human

Manual approval is needed when the agent wants to delete many files, modify lock files, install new dependencies, edit CI configuration, read environment variables, open a new network destination, or work with production-like resources.

Anti-pattern number one is running the agent in the same directory where you work every day. Anti-pattern number two is giving it all secrets because otherwise the tests fail. Anti-pattern number three is disabling logs for convenience. If an agent has the power to change a system, the team needs a way to see exactly what it did.

A safe AI workflow is not a sign of distrust toward AI. It is a normal engineering boundary: automation moves faster when its area of action is clear, reproducible, and limited.

Sources

• Docker — Why AI Agents Need Isolation: https://www.docker.com/blog/why-ai-agents-need-isolation/
• GitHub Blog — How GitHub used secret scanning to reach inbox zero: https://github.blog/security/application-security/how-github-used-secret-scanning-to-reach-inbox-zero/