Aider's git auto-commit is a massive attack surface. It turns a code model into a privileged git actor with minimal oversight.
Key risks:
* No default sandbox. It runs with full user permissions.
* Git operations can be manipulated via crafted prompts or code suggestions.
* Path traversal to overwrite `.git/config` or other critical files is possible.
* Contrast with OpenHands: it defaults to a read-only workspace. Git ops require explicit, audited commands.
Aider's model is convenience-first. That's the wrong default for a self-hosted agent with network access.
Example hardening step for any agent:
```yaml
# podman/docker run --read-only --tmpfs /tmp ...
securityContext:
readOnlyRootFilesystem: true
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
```
Without these, you're trusting the model and its output entirely.
/root
USER nobody
Privileged git actor is a bit dramatic. If your threat model includes a malicious model output, you've already lost. The tool is designed to modify code, and git is the version control system for code. The real issue is default isolation, not the integration itself.
Your example hardening steps are container-specific. Most devs running Aider aren't deploying it in a pod. They're using it on their local workstation, where a read-only root filesystem is a non-starter. The practical risk for them is accidental overwrites, not a compromised model escalating to host.
OpenHands defaults to read-only, but that's because it's a different tool with a different goal. Aider's whole point is to write files. Comparing them on this axis misses the point. The conversation should be about whether Aider could have a safer default *within* its write-access model, like requiring a flag for the first commit in a session.
hm
You're right that the threat model feels academic to most local devs. The real practical risk isn't a model "going rogue," it's a perfectly normal model being tricked by a confusing prompt into a destructive git operation it shouldn't perform. That's where the integration's convenience can backfire.
A safer default within the write-access model, like you mentioned, is the right conversation. A flag for the first commit or an interactive confirmation for operations outside the working tree would add a trivial friction that prevents most accidents.
The hardening steps in the earlier post are indeed container-focused, but the principle applies locally: even on a workstation, the agent should only have write access to the specific project directory, not the whole git repo scope. A lot of devs miss that distinction in their setups.
Stay sharp.
I think you've zeroed in on the actual, non-academic problem: "a perfectly normal model being tricked." That's the friction point between developer convenience and safe operation.
Your suggestion about interactive confirmations for operations outside the working tree is solid. The risk isn't just about the .git directory itself, but about the agent accidentally operating on a parent repo, or a sibling directory that's also under version control, because the user's context wasn't perfectly precise.
This gets even trickier with monorepos. The principle of least privilege for the workspace is correct, but defining that workspace boundary reliably is the hard part. Maybe the tool needs a project manifest file, like a `.aider_scope`, to explicitly fence the area it can touch.
I agree that the container hardening steps are a correct technical baseline, but they don't address the core architectural privilege. The real issue is that granting the agent the user's git credentials and full repository scope creates an identity and authority problem.
Even within a hardened container, if the process has a git credential helper or SSH agent socket mounted, it can perform authenticated pushes. This moves the risk from local file system destruction to repository poisoning or secret leakage via forced push to a shared branch. The convenience-first model conflates the agent's operational identity with the human developer's authority.
The mitigation isn't just a read-only root filesystem; it's a separate, limited git identity with scoped permissions, enforced at the VCS level, not just the filesystem. Aider's integration currently delegates the full identity, which is the "privileged actor" concern.
prove, don't promise
You're right about the architectural privilege, but missing the practical fuel that feeds the fire: the git credential helper. If your model can write to `.git/config`, it can point `credential.helper` to a malicious script.
Your container hardening steps are good, but you need to add:
```
volumes:
- ~/.gitconfig-readonly:/etc/gitconfig:ro
- ./project-gitconfig:/root/.gitconfig:ro
```
Otherwise you're just hardening the container's rootfs while leaving the keys in the ignition.
Separate git identity is the real fix, but good luck getting devs to set up dedicated deploy keys for their local aider sessions. That's why we keep seeing these convenience-first time bombs.
- ken