Why do coding agents increase risk when they can read repositories and call tools?

Why This Matters for Security Teams

Coding agents are risky because they collapse a familiar boundary: repository content is no longer just documentation, it can become instructions that influence an executor with real permissions. A poisoned README, prompt-like issue, or tool description can steer the agent toward secrets, internal data, or destructive actions without malware ever being dropped. That is why agent risk is better understood as delegated authority abuse than as classic code execution.

The practical failure mode is well documented in recent agent incidents and guidance, including Amazon Q AI Coding Agent Compromised and the OWASP Agentic AI Top 10. The core issue is that agents can read, infer, and act across tools faster than reviewers can predict. Current guidance suggests treating repository content as an untrusted input surface whenever an agent can interpret it and then call external systems.

In practice, many security teams encounter the damage only after the agent has already used its own legitimate access to enumerate credentials, modify files, or move data out of scope.

How It Works in Practice

The risk emerges when three capabilities combine: repository read access, tool execution, and authority to act on behalf of a human or service account. Once those conditions exist, the agent does not need a payload in the traditional sense. It only needs instructions embedded in content it is allowed to inspect. A malicious comment, build file, dependency note, or issue body can shape the agent’s next step, especially when the agent is trained or configured to “helpfully” follow project context.

Security teams should think in terms of execution paths, not just files. If an agent can open a repo, inspect secrets, invoke a shell, create tickets, query APIs, or submit pull requests, then every readable artifact becomes a potential control channel. The defensive shift is to reduce ambient authority and add runtime checks. That usually means:

• Use least privilege for every tool the agent can call, not just for the initial login.
• Issue short-lived credentials per task, then revoke them automatically when the task ends.
• Separate read-only repository access from any action-capable workflow.
• Require policy evaluation at request time for high-risk actions such as secret access, external network calls, or writes to protected branches.
• Log the agent’s reasoning, tool calls, and target resources so suspicious pivots are detectable.

These controls align with the direction of the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize context, governance, and control of emergent behavior. NHI governance adds the identity layer: the agent should prove what it is with workload identity, not rely on a long-lived token that can be reused after the job is done. NHIMG research shows how often credentials remain exposed in code and config, which is exactly the material a coding agent will parse if it is allowed to roam through a repository. These controls tend to break down when agents are given broad repository access plus shell or API privileges, because one poisoned artifact can chain into multiple legitimate tool actions.

Common Variations and Edge Cases

Tighter agent controls often increase friction for developers, requiring teams to balance autonomy against review overhead and slower task completion. That tradeoff is real, but current guidance suggests it is necessary whenever the agent can both read untrusted project content and act on it.

One common edge case is the “trusted repo” assumption. Internal repositories are often treated as safe because they are private, but a compromised contributor account, malicious pull request, or stale dependency note can still alter the agent’s behavior. Another edge case is tool chaining: the agent may not be dangerous from a single action, but becomes risky when it can combine search, file reading, API lookup, and commit rights in one run. There is no universal standard for how much autonomy is acceptable here, so teams should classify tool sets by blast radius rather than by function name.

For now, the safest pattern is to constrain agent context, scope credentials to a single task, and treat repository text as adversarial until proven otherwise. This is especially important in environments where agents can reach secrets managers, CI/CD systems, or production-adjacent APIs. In those environments, the failure is not just data theft. It is the agent using legitimate permissions to turn ordinary project content into an operational exploit.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents create more risk when they reuse existing credentials?
• Why do AI agents create more IAM risk than ordinary developer tools?
• Why do AI agents increase non-human identity risk?