Security

What Can an AI Coding Agent Actually Access on Your Mac?

The mechanism is that an agent can read whatever your account can read. This is the concrete inventory: what actually lives in a typical home directory worth worrying about, and a realistic scenario where an agent touches all of it doing nothing malicious at all.

The inventory, specifically

Not a hypothetical list — these are real, common paths that exist on most developer Macs, unremarkable to the tools that put them there:

SSH keys — ~/.ssh/, private keys with no passphrase in many developer setups, ready to authenticate to every server and Git host they're registered with.
Cloud credentials — ~/.aws/credentials, plaintext access keys for an AWS account, often with far broader permissions than whatever task they were originally set up for.
GitHub CLI tokens — ~/.config/gh/hosts.yml (or the OS keyring, depending on configuration), enough to act as you against every repository your account can reach.
Container registry auth — ~/.docker/config.json, credentials for whatever private registries you've logged into.
Package manager tokens — ~/.npmrc can carry an npm auth token with publish access to your packages.
Shell history — ~/.bash_history or ~/.zsh_history, a plaintext log that often includes commands with credentials pasted directly into them.
Project-local secrets — .env files, sitting in the working directory of whatever project the agent was pointed at, often already in .gitignore specifically because they're not meant to leave the machine.
Browser data — session cookies and saved credentials, stored on disk in whatever format the browser uses, readable by anything with filesystem access to the profile directory.

A realistic scenario — no malice required

Here's the version that doesn't need a hypothetical attacker at all. You ask an agent to debug why a deploy script keeps failing. In the course of investigating, it runs aws configure list to check what credentials are active, greps the project directory for anything mentioning the failing service — which happens to include a .env file with a database password — and, trying to reproduce the failure locally, reads ~/.ssh/config to understand how the deploy target is reached. None of that is the agent doing anything wrong. It's exactly what a competent engineer troubleshooting the same problem would look at. The difference is that a human engineer has judgment about what to do with a credential they stumble across; an agent's next action is just whatever the model decides comes next, and if that decision gets steered by something it wasn't supposed to trust — a comment in a file, a string in a bug report — there's no human pause between "read the credential" and "use it."

Git and source code get their own treatment

Source code and Git-specific access — commits, hooks, dependency-install chains that lead to hooks — are a big enough topic to deserve separate treatment rather than a bullet point here; see can you trust an AI coding agent with your Git repository? for that.

Why this list, not a scarier one

None of the above requires an agent that's been compromised, jailbroken, or is acting outside its instructions. It's what's reachable by design, the moment an agent runs with the same filesystem access as the account that launched it — which is the whole point of the mechanism post this one builds on. The fix isn't a smarter agent that knows not to look at these files; it's running the agent somewhere this list simply isn't reachable at all, covered in VM vs. container vs. sandbox on macOS.