Guide

How AI Coding Agents Use Your Computer

This isn't the incident-report version — that one's here, with real 2026 cases and what stopped them. This is the calmer, mechanical question underneath it: what does an AI coding agent actually touch on your machine, and how? Understanding the mechanism is what makes the risk legible in the first place.

The same account, the same permissions

The single fact that explains everything below: an AI coding agent isn't a separate, more restricted kind of user. It's a normal process, launched by your normal user account, using the same system calls any other program on your machine uses — typically subprocess or exec() to run shell commands. There's no OS-level concept of "this process is an AI agent, treat it differently." It can do anything your user account can do, because as far as the operating system is concerned, that's exactly what's asking.

Shell: commands run exactly like you typed them

When an agent "runs a command," it's invoking the same shell interpreter a human terminal session would, with the same working directory, the same PATH, the same ability to chain commands together. There's no intermediate layer inspecting each command for intent before it executes — the shell doesn't know or care whether a human or a model decided what string to run.

Filesystem: whatever the process can open

File access follows ordinary filesystem permissions, nothing more restrictive. If your user account can read or write a path, so can a process your account launched — your home directory, your dotfiles, any project directory you've opened the agent inside of. Nothing about being "an AI agent" narrows that by default. For the concrete inventory of what that actually includes on a typical Mac, see what can an AI coding agent actually access.

Git: the agent's commits are Git's normal operations

An agent that runs git commit, git push, or installs a hook is using Git exactly as designed — Git has no separate trust tier for who or what is invoking it. Anything Git itself is configured to trust on your behalf — a stored credential helper, an SSH key already loaded in your agent, a hook script that runs automatically — the agent can use too, the same way any other process on your account could.

Package managers: installers run arbitrary code by design

A pip install, npm install, or brew install triggered by an agent isn't sandboxed by the package manager itself — setup.py scripts, npm's install-time hooks, and Homebrew formulae can all run arbitrary code as part of a normal install, which is exactly how they'd run if you'd typed the same command yourself. The package manager isn't evaluating "was this install command typed by a human," because it has no way to know — see the version of this risk with no agent involved at all, just you and an unfamiliar GitHub repo's own setup instructions.

Network: outbound calls are just outbound calls

Unless something outside the agent process itself restricts it — a firewall rule, a network namespace, a VM boundary — an agent's process can make the same outbound network requests your account's other processes can. There's nothing agent-specific about the request at the network layer; it looks like traffic from your Mac because, mechanically, that's what it is.

Environment variables: readable the same way `printenv` reads them

A process inherits the environment of the account that launched it. Whatever's exported into that environment — API keys, cloud credentials, tokens set for a different tool entirely — is visible to an agent process the same way it would be visible to any other process you started, because environment inheritance doesn't distinguish between them either.

None of this is a flaw in a particular agent

Every point above is standard, decades-old operating system behavior, not a bug specific to any coding agent or vendor. Processes inherit the permissions of the account that launched them; that's how the process model has always worked, for a shell script, a build tool, or an AI agent alike. Which is exactly why meaningful isolation can't come from the agent behaving more carefully — it has to come from a boundary outside the agent's own process entirely: a container's namespace, or a VM's separate kernel, covered in VM vs. container vs. sandbox on macOS. For what actually goes wrong when that boundary is missing, and which level of isolation would have stopped each case, see the security deep dive.