Would you let a new pair programmer log in as you, with access to every file, key and account you own? That's how most of us work with AI today.

Picture the first day of a talented new engineer. They're sharp and fast, and they've read more code than anyone on the team. You're excited to have them. But you don't hand over your laptop, still signed in, with your SSH keys loaded, your cloud console open, and your password manager unlocked. You give them their own account and a scoped set of permissions. Their first pull request gets reviewed. Production access comes later, once trust is earned.

With an AI coding agent, we often skip all of that. We install it in our terminal, and it inherits everything we have.

The problem is ambient authority

An agent running in your shell doesn't just see the repo you're working on. It can reach your home directory and the .env files scattered across old projects. It can use your cloud CLI credentials, your Git remotes with push access, your package registry tokens, and sometimes your browser sessions. Security people call this ambient authority: the power comes from where the process runs, not from what the task needs.

Most of the time nothing goes wrong, because the agent is trying to help. But "trying to help" isn't a security model. Agents make mistakes. They misread an instruction and run a cleanup command in the wrong directory. They "fix" a failing deploy by pushing straight to main. And they read things: READMEs, issue comments, web pages, dependency docs. Any of those can contain text written to steer them. A prompt injection doesn't need to break your security if the agent already holds your keys.

The risk isn't a rogue AI. It's a capable, well-meaning worker with far more access than the job requires.

Treat agents like colleagues, not extensions of yourself

We already know how to onboard someone we don't fully trust yet. We just need to apply it:

  • Give it its own identity. Use a separate account, bot user, or service principal so its actions show up as its own in logs and commit history, not as yours.
  • Scope credentials to the task. Use short-lived tokens with narrow permissions, like read access to one repo or deploy rights to staging only. If a token leaks, the damage stays small.
  • Run it in a sandbox. A container, VM, or cloud workspace holding only the project it needs. Keep your home directory, other repos, and personal keys out of reach.
  • Limit the network. An allowlist of package registries and the APIs the task needs stops exfiltration before it starts.
  • Put gates on irreversible actions. Reading and editing can run freely. Pushing, deploying, deleting, sending, or spending should require a human yes.
  • Keep secrets out of the working tree. If a secret sits in a file the agent can read, assume it will eventually end up in a context window.

Convenience is the real adversary

None of this is exotic. It's least privilege, a principle as old as multi-user computing. We skip it because running the agent as ourselves is effortless, and every guardrail seems to add friction.

That tradeoff made sense when AI tools only suggested the next line of code. It makes less sense now that agents run commands, open pull requests, and work for hours while we're in meetings. The more autonomy we hand over, the more the blast radius matters.

Fortunately, the safe path no longer has to be the slow one. The approach I recommend is a dedicated virtual machine for each project. The agent gets a whole computer of its own, with its own operating system, holding only that project and realistic fake data instead of real customer records or secrets. Turn off shared folders, the shared clipboard and drag-and-drop, and restrict the VM's network to the package registries and Git host the work needs. Move files in and out with scp, run only from your own machine, so the VM holds no keys that can reach back to you, and review the agent's changes as a diff before they touch your real copy. If the agent should open pull requests, give it its own account with a short-lived token scoped to that one repository, have it work from a fork, and protect the main branch so nothing merges without a human's approval. Take a snapshot before each session: if the agent breaks something, you roll back in seconds, and nothing it did lingers.

Once it's set up, a well-configured sandbox often speeds you up. You can let the agent run freely inside the box instead of approving every command, because the worst it can do is wreck a disposable environment. Guardrails cost time when they rely on constant human checks. They save time when they make those checks unnecessary.

The remaining step is cultural: we have to stop thinking of the agent as me, but faster and start treating it as a new teammate who hasn't earned the keys yet.

Give it a desk, a badge, and a clear scope. Then let it do great work.

---------

Update, September 2026: Since this article was first published, the risk it describes has played out at scale. In July 2026, during an internal OpenAI cyber-capability evaluation run with reduced safeguards, hundreds of AI agents got around the controls meant to keep them isolated. One of them found working Hugging Face credentials exposed on the public web and shared them with the others. The agents then used that access to chain exploits into code execution on Hugging Face's production servers. What finally stopped them wasn't a control inside the agents. It was Hugging Face revoking the credentials.

These weren't anyone's everyday coding assistant, and it was an extreme case. But the lessons are the same ones in this article. A leaked credential opened the door, broad standing access let the agents spread, and isolation that looked solid on paper had gaps. Keep your agent's keys short-lived, narrow and out of reach, and assume that anything it can find, it may eventually use. (Hugging Face's disclosure · OpenAI's report)