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

One working day with a very fast intern

An AI agent is like a very fast intern with terminal access. It can find a file, run tests, install a dependency, change code, and call an API in minutes. But if that intern immediately receives the home directory, production tokens, and unrestricted internet access, the problem is no longer AI. The problem is our access policy.

That is why safe AI-agent execution should be treated as an operational procedure, not as a magic setting. The agent is an untrusted executor: useful, fast, and still capable of misunderstanding a task, making a mistake, or running a dangerous command. The good news is that most risks can be reduced with ordinary boundaries: isolation, least privilege, controlled networking, careful secret handling, and an audit log.

09:30. The agent runs directly on a laptop

A typical beginning looks harmless. A developer opens a repository, starts an AI agent in the terminal, and asks it to fix a failing test. The agent reads files, suggests a command, installs a package, and runs a script. Everything feels efficient until we remember that the same machine also holds SSH keys, local cloud configuration, shell history, other projects, and package-manager caches.

The worst anti-pattern is running the agent in the same place where a person works every day, with no boundaries and no logging. If the agent can access the whole file system, it can accidentally read the wrong file or change the wrong directory. If the network is open, it can download a dependency from a questionable source or send data somewhere the team never intended. If secrets are available as environment variables, the agent or a tool it launches may use them without a separate human decision.

10:15. The workspace becomes disposable

The first practical step is a separate workspace. For local development, that may be a container, a separate virtual machine, or another isolated mechanism. For CI, it may be a short-lived runner created for one task and destroyed afterward. The tool name matters less than the properties: the agent sees only the files it needs, changes are easy to review, and the environment can be wiped without regret.

The operational rule is simple: do not mount the home directory, do not pass the entire repository unless the task requires it, and do not grant write access where read access is enough. If the agent must update documentation, it does not need deployment configuration. If it must fix a test in one module, the rest of the repository can be read-only or unavailable.

After the task ends, the workspace is deleted. Useful artifacts are saved separately: the patch, test output, command list, and a summary of network requests. This prevents accidentally installed packages, temporary files, and hidden changes from carrying over into the next run.

11:40. The network is closed until explicitly opened

AI agents often need network access: downloading dependencies, reading documentation, or calling an internal API. But unrestricted outbound access is a weak point. A safer starting rule is: the network is denied by default, and required destinations are added to an allowlist.

For a common development task, the agent may only need a package registry, an internal Git server, and a test API. Access to arbitrary domains, production APIs, personal email, file-storage services, and control panels should be blocked. If the agent asks for a new network destination, that should trigger a separate decision: why it is needed, for how long, and what data may leave the environment.

The anti-pattern is allowing the whole internet because it reduces install errors. That is convenient, but if a malicious dependency appears or the agent makes a bad choice, the team loses control over outbound traffic.

13:00. Secrets are not left on the desk

Secrets are the most sensitive part. They do not live only in source code. GitHub, in its article about secret scanning, shows that secrets can appear in support tickets, vulnerability reports, incident notes, and wiki pages. For an AI agent, the lesson is clear: do not assume the risk is limited to a .env file.

A basic policy says: the agent does not receive production secrets directly. If access is required, prefer test tokens, short lifetimes, limited permissions, or a secret broker. A broker can perform a specific action on behalf of the agent without showing the raw secret. For example, the agent asks to run an integration test, the broker grants temporary access only to the test environment, and the access is revoked after completion.

Secrets should also be kept out of logs. The audit log should show that access was requested and used, but it must not store the actual tokens.

15:20. The human remains the gatekeeper for dangerous actions

Not all agent actions are equal. Running a linter can often be automatic. Deleting files, changing CI configuration, upgrading dependencies, calling a production API, or creating a release should require human approval.

A good policy describes action classes. Green actions run without approval. Yellow actions require a short explanation from the agent and human consent. Red actions are forbidden or allowed only in a stronger isolated environment. This is not bureaucracy. It is how a team avoids turning an AI agent into a process with administrator-level freedom.

Final execution policy

Before the first real run, the team should agree on a minimal rule set. The agent runs with isolation. The workspace is disposable. File access is minimal. Network access is denied by default and opened through an allowlist. Secrets are not passed directly, and any access to them is short-lived and limited. The audit log records commands, file changes, network requests, and human decisions.

The main rule is simple: the more an agent can do, the stricter its boundaries must be. If it only explains code, read access may be enough. If it runs commands, edits files, and reaches the network, it should be treated as an untrusted workload. AI speed is useful only when the team does not hand it the keys to the whole machine.

Sources

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