Commits and pushes aren't the interesting part

An agent running git add, git commit or git push is doing what those commands always do; Git has no separate trust level for who's typing. The access it needs to push, a credential helper or a loaded SSH key, is the same access already covered for your account in general. It's real, but it isn't specific to Git.

Where it gets interesting: hooks

Git has a deliberate safety property many people don't know about: hooks live in .git/hooks/, which isn't part of the tracked tree, so a plain git clone never installs hook scripts from the repository you cloned. That property disappears when a project uses a hook manager (Husky, the pre-commit framework, Lefthook) that keeps hook scripts under version control and links or copies them into .git/hooks/ during setup. From then on, a hook committed to the repository, by a pull request or by an agent, can run automatically on the next commit or checkout.

There's a documented vulnerability class here too: a symlink pointing a checkout path at a submodule's hooks directory could make a submodule's post-checkout hook run unintentionally. Current Git has patched it, but it was real, not theoretical.

The chain that matters: install scripts feed hooks

Installing dependencies already runs arbitrary code. What's specific to Git is how directly that connects to hooks: in a project using Husky, npm install commonly runs a postinstall script that installs Git hooks, as a normal part of setup. An agent that clones a repository and follows its setup steps, exactly as asked, can end up with hooks that run on every later commit, without ever being told to install one.

What gets committed isn't always what you'd commit

A developer has an instinct for what doesn't belong in a commit: a stray .env, a debug print with a token in it, a half-finished credential test. An agent doesn't, unless something gives it one; it stages and commits whatever the task seemed to need. The scenario where an agent reads a .env file while debugging becomes a different problem once that file's contents land in a generated fix, a test fixture or a commit message.

The mitigation

Asking the agent to be careful doesn't solve this. As everywhere else on this blog, the boundary has to sit outside the agent's process. In a disposable workspace, thrown away after the task (see what is a disposable development environment), a hook that got installed or a credential that got read doesn't outlive the session. Give the workspace only the credentials the task needs, such as a narrowly scoped token, rather than your own keys, and review what it pushes as you'd review anyone's pull request. Combined with the isolation levels in the security deep dive, that's the answer: not a more disciplined agent, but an environment where its mistakes don't add up.

Related reading: how AI coding agents use your computer, what an agent can access, running AI agents safely in an isolated VM, and the full checklist. Or download Velo Workspaces and try it yourself.