What Are Infostealer Logs and Why Are They So Dangerous?

There is a moment, the first time you run a coding agent, where it asks for permission to do something — run a command, edit files, install a dependency — and the path of least resistance is to grant it everything, globally, forever. Don't. The convenience of an agent that can do anything is exactly the convenience an attacker wants when a poisoned repository or a prompt-injected README points your agent at a malicious command. The fix is old, boring, and effective: least privilege and isolation. Give the agent the smallest environment it needs to do the job, and nothing more.

This is a practical guide to sandboxing AI coding agents — what to isolate, how to do it with containers and restricted directories, and where the common shortcuts leak.

Why "the whole machine" is the wrong default

When you run an agent directly on your laptop with your normal user account, it inherits your trust. That means your shell history, your SSH keys in ~/.ssh, your cloud credentials in ~/.aws and ~/.config, your browser's cookie database, every .env file in every project, and your ability to push to every repo you can write to. An agent doesn't need any of that to refactor a function — but if it executes hostile code, all of it is in reach.

This is not hypothetical. The Miasma worm that hit Microsoft in June 2026, reported by StepSecurity, worked by committing malicious config files that ran a credential-harvesting payload the moment a repository was opened in an AI coding tool — with the same permissions as the developer's session. The lesson is structural: the agent's blast radius equals the privileges of the environment you run it in. Shrink the environment, shrink the damage.

The least-privilege checklist

Before the first run on any unfamiliar project, decide what the agent actually needs:

The principle behind every row is the same one in NIST's and OWASP's guidance: grant the minimum access required, and prefer ephemeral over standing privileges. An agent that finishes its task and leaves nothing behind it could have stolen is the goal.

Containers: the practical isolation layer

For most developers, a container is the right unit of isolation — light enough to spin up per project, strong enough to keep the agent off the host.

A workable pattern with Docker:

docker run --rm -it \
  -v "$PWD":/work -w /work \
  --network none \
  --user 1000:1000 \
  agent-sandbox:latest

What each flag buys you:

• -v "$PWD":/work mounts only the current project — not your home directory, not ~/.ssh, not sibling projects.
• --network none starts the agent offline. Exfiltration needs an outbound connection; deny it by default and only enable network access (ideally to an allowlist) when the task genuinely requires installing packages.
• --user 1000:1000 runs as a non-root user, so even inside the container the agent can't trivially escalate.
• --rm discards the container on exit, so any persistence the agent (or a payload) tried to establish is thrown away.

A devcontainer wraps the same idea in editor-native tooling. For stronger isolation than shared-kernel containers, a lightweight VM (or a microVM runtime) adds a real kernel boundary — worth it when the code is genuinely untrusted.

Restricted directories and environment isolation

Even inside a container, be deliberate about what you hand the agent:

• Mount the project read-only when you only need analysis. -v "$PWD":/work:ro lets the agent read and reason about code it cannot modify — ideal for a first-pass review before you let it touch anything.
• Keep secrets out of the environment entirely. Don't docker run --env-file .env into an agent you don't trust yet. If a task truly needs a credential, inject a scoped, short-lived token for that task and revoke it after, rather than your long-lived keys.
• Use a separate config home. Point the agent's HOME at a throwaway directory so it can't read your real ~/.config, shell history, or cached cloud sessions.
• Never bind-mount the Docker socket (/var/run/docker.sock) into an untrusted agent container — that is a well-known host-takeover path.

The recurring theme: the agent should ask for each capability, not find it lying around.

Keep a human gate on the dangerous actions

Isolation and approvals are complementary, not redundant. Configure your agent so that running a shell command, making a network request, or installing a dependency requires explicit approval — at least until you trust the codebase. Auto-approve safe, reversible actions (reading files, running tests in the sandbox); pause on irreversible or outbound ones. Our deeper write-up on securing AI coding agents covers the audit-log side of this, so you can review after the fact what the agent actually did.

FAQ

Isn't a container overkill for a quick task? For your own trusted code, maybe. For unfamiliar code — a repo you cloned to evaluate, a dependency you're inspecting — the container is the difference between a contained mistake and a compromised laptop. Make isolation the default for anything you didn't write.

Does --network none break package installs? Yes, by design. Run dependency installation as a deliberate, network-enabled step (ideally against an allowlist or a private mirror), then drop back to offline for the agent's actual work. Don't leave the network open "just in case."

Are containers a real security boundary? They share the host kernel, so they're weaker than a VM. For most agent isolation they're enough when run non-root with no dangerous mounts; for truly untrusted code, prefer a VM or microVM.

What about cloud-hosted agent sandboxes? They isolate the agent off your machine entirely, which is excellent for the filesystem/credential problem — just apply the same network and secrets discipline inside them, since a hosted sandbox with your production tokens mounted is no longer least-privilege.

Bottom line

The first run is where the bad habit forms: grant-everything-once and forget. Resist it. Run agents in a container that mounts only the project, starts offline, runs non-root, and carries no standing credentials; inject scoped tokens per task; and keep a human approval gate on commands, installs, and network calls. None of this slows you down once it's set up — and it converts "the agent executed something hostile" from a disaster into a discarded container.

Sources and further reading