How to run AI agents safely: isolation, secrets, and network boundaries

Scenario: a fast intern with terminal access

An AI agent in a repository is like a very fast intern with access to a terminal. It is not malicious by default, and it is not trying to break the system. The risk is different: the agent can confidently run a command without understanding its consequences. It can install a package, rewrite a file, send a request to an API, or read an artifact that accidentally contains a secret.

So the main question is not whether we trust the model. The question is what operating model we build around its actions. If the agent only suggests text, the risk is lower. If it runs commands, works with dependencies, changes code, and has network access, it needs boundaries.

Step 1. The agent only reads code

The safest starting point is read mode. The agent can see the repository, analyze files, and suggest a plan, but it does not change the working copy. The rule is simple: reading a repository should not automatically mean access to the whole home directory, shell history, or private notes.

A common mistake is to run the agent from the root of a personal machine, where old archives, configuration files, SSH keys, and local notes may sit next to the code. A better control is a separate workspace that contains only the required repository. If the task does not require changes, mount the files as read-only. This is not perfect security, but it is a useful first boundary.

Step 2. The agent runs commands

When the agent receives permission to execute shell commands, the risk increases sharply. A test command may be fine, while a cleanup command may be destructive. Scripts inside a repository can also do more than the user expects.

The minimum control is to run the agent in a container or another sandbox with a disposable file system. After the task, the environment should be reset. Direct write access to important local directories should not be allowed. For code changes, use a separate branch or copy that can be compared and rolled back easily.

An anti-pattern is letting the agent decide what to run while the user sees only the final result. A safer pattern is to show the command plan before execution and require human approval for commands that delete files, change permissions, push code, or run long installation steps.

Step 3. The agent installs dependencies

Package installation is a separate risk area. The agent may mistype a package name, choose an unreviewed dependency, or run an installation script. Even when the intent is correct, the supply chain can become the weak point.

The practical rule is this: do not install dependencies into the developer main environment. Let the agent do it in a disposable environment. Be careful with caches: they make work faster, but they can carry state from one task to another. If a package is meant to become part of the project, the change should go through normal review: dependency file, lock file, reason for adding it, and test results.

Step 4. The agent receives an API token

Secrets should not enter the agent environment out of habit. Often a token is passed in simply because a command fails without it. That is a dangerous path: the agent may print the secret in logs, send it in an external request, or use it more broadly than intended.

A better approach is scoped credentials. If the agent needs to read a test API, give it a short-lived read-only token. If it needs write access, limit it to the specific resource. For critical actions, use a proxy or service layer that accepts a narrow command and does not reveal the full secret.

It is also important to remember that secrets do not live only in .env files. They can appear in support tickets, bug reports, wiki pages, incident notes, and chats. That is why broad access to work artifacts is dangerous even when the agent does not have direct access to a secrets manager.

Step 5. The agent uses the network and CI

Network access should follow a deny-by-default model. The agent does not need access to the whole internet, the company private network, or internal metadata endpoints. It needs specific destinations: a package registry, a test API, documentation, or an internal service that has been explicitly allowed.

In CI, the risk is higher because the environment is closer to the release process. Here you need an audit log, separation of permissions, scoped credentials, and human approval before actions such as publishing a package, deploying, changing secrets, or merging into the main branch.

A minimal execution model

For a local task, a reasonable starting point is a separate workspace, read-only mode where possible, a container for commands, limited network access, and a short action log. For untrusted code, dependency installation, or API access, stronger isolation may be required, such as a microVM or managed sandbox.

The core idea is simple: an AI agent should not receive human-level access just because it works on behalf of a human. Give it exactly what it needs for the task, and make mistakes easy to see, stop, and roll back.

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/