Because they can modify code, dependencies, and pull requests from inside the development workstation, often with fewer human checkpoints than standard engineering workflows require. If the agent is also allowed to browse, ingest untrusted content, or use community forked software, the repo becomes a delivery point for unreviewed machine-authored change.
How local AI agents change the trust boundary in git workflows
Local agents are different from ordinary developer automation because they run on a workstation that already has access to source code, credentials, build tools, and often the active git repository. That means the agent can influence commits, branches, dependency files, and pull requests from inside the same environment a developer trusts, which lowers the number of checkpoints between intent and repository change.
A practical way to think about the risk is that the workstation becomes both the control plane and the execution plane. If the agent can read context, write files, invoke package managers, and open or amend changes, then a malicious prompt, poisoned file, or unsafe tool action can turn a helper into a supply-chain insertion point.
When agents are allowed to browse the web or ingest outside content, the trust boundary expands again. Untrusted snippets, copied commands, README instructions, package metadata, and forked code can all become inputs to the agent’s next action, so the repository can receive changes that were never reviewed by a human in the normal engineering flow.
Why git repositories are especially exposed
Git is not just a storage layer. It is the system through which code, configuration, dependency pinning, and review evidence move toward production. An agent that can create or rewrite a branch, stage files, or modify a pull request can therefore influence what reviewers see and what eventually gets merged.
This matters most when the agent has access to AI coding agents security guidance, because the same capabilities that make them productive also create the highest blast radius: file writes, command execution, package installation, and commit authoring. The supply-chain concern is not only malware in the codebase, but also dependency drift, injected build steps, and subtle changes that look legitimate in a pull request.
The danger is amplified when a local agent can act faster than the review process. Even if the output is technically “proposed” rather than auto-merged, a reviewer may only see the final diff, not the sequence of tool calls, web pages, or hidden assumptions that produced it.
What makes the risk real in practice
Three conditions usually turn convenience into supply-chain exposure. First, the agent has write access to repository files or CI-related configuration. Second, it can fetch or interpret content from outside the trusted codebase. Third, the surrounding process treats machine-authored changes as low-friction developer work instead of as higher-risk third-party input.
That is why dependency manifests, lockfiles, build scripts, test fixtures, and release automation deserve special scrutiny. If an agent can update them without strong review, it can introduce code paths or transitive dependencies that reviewers did not intend to approve. This is the same structural problem that makes SLSA valuable: provenance and integrity checks reduce the chance that an untrusted change slips through as a normal build artifact.
The local setting also creates an attractive compromise path for attackers. A prompt injection, malicious fork, or poisoned dependency page may not need to compromise the repo directly if it can steer the agent into making the change on the attacker’s behalf.
Risk and Threat Considerations
Local AI agents widen the attack surface by letting outside content and repository authority meet on the same workstation. The key risk is not just accidental error, but abuse of the agent’s ability to translate untrusted instructions into code, dependency, or workflow changes that look developer-authored.
Failure mechanism: The agent ingests untrusted material, applies it with excessive local permissions, and produces commits or pull request updates that bypass the normal human checkpoints that would have caught the issue.
Impact: Attackers can land malicious dependencies, altered build logic, credential exposure, or subtle source changes that compromise integrity across the repository and downstream release process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Repository changes can alter build provenance and artifact integrity. |
| Recommendation — Require provenance checks for agent-authored changes that affect builds or dependencies. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Agent-generated code and dependency changes need evaluation before integration. |
| CM-5 — Access Restrictions for Change | The issue centers on limiting who or what can change repository and build assets. | |
| Recommendation — Evaluate agent-produced changes before accepting them into the codebase. Restrict agent ability to modify protected files and release workflows. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Agent-written code and dependency edits must preserve secure architecture and change control. |
| Recommendation — Review automated code changes for insecure dependencies and unsafe design shifts. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Local agents can inject unreviewed software changes into the development pipeline. |
| Recommendation — Apply software security checks to all agent-generated repository changes. | ||
Practitioner Guidance
What to verify: Check whether the agent can write to source, dependency, or CI files without a separate approval step. If it can, treat that as a supply-chain control gap rather than a productivity feature.
Decision rule: If the agent can browse or ingest external content, require a stricter review path for any diff that touches imports, lockfiles, scripts, or release automation. If the change is purely local and non-executable, the review burden can be lighter.
What good looks like: The agent may draft changes, but humans retain control over trust boundaries, dependency updates, and any action that can alter what gets built or shipped. For agent authorization patterns, AI agent authorisation guidance is the right reference point.
Common mistake: Treating a local agent like a smarter editor instead of a privileged actor that can chain instructions, tools, and repository writes into one continuous change path.
Practitioner takeaway: The real control question is not whether the agent is useful, but whether any action it can take would be hard to distinguish from a trusted human change if the surrounding review process failed.