How should organisations govern coding agents that can modify code and config?

Why This Matters for Security Teams

Coding agents that can edit source code, change infrastructure files, or update deployment configuration are not simply productivity tools. They can alter runtime behaviour, weaken controls, or introduce supply chain risk if their scope is too broad. Current guidance suggests treating them as governed agentic systems with bounded authority, traceable actions, and explicit approval points, rather than as trusted collaborators with unrestricted repository access.

The risk is usually not that the agent “decides” to be malicious. The more common failure is that it is placed inside a workflow where prompts, tool calls, and file writes are all implicitly trusted. That creates room for prompt injection, unsafe dependency installation, hidden logic changes, and configuration drift that bypasses normal review paths. The NIST AI Risk Management Framework is useful here because it frames governance around mapping, measuring, and managing AI-related risk, not just model output quality.

For identity and access teams, the important shift is to classify the coding agent as a non-human identity with delegated privileges, not as a human developer account. That means its access should be narrower than a senior engineer’s, even if it is allowed to act faster. In practice, many security teams encounter code and config abuse only after a deployment pipeline has already propagated the change into production, rather than through intentional approval design.

How It Works in Practice

Effective governance starts by separating read, write, and execute permissions. A coding agent may need to inspect repositories, generate patches, or run tests, but that does not justify unrestricted access to secrets, package managers, cloud consoles, or production infrastructure. The practical control model is to bind the agent to a specific project, a limited toolset, and a narrow set of files or directories. High-impact paths such as deployment manifests, IAM policies, CI/CD definitions, and secret-handling code should require human review before merge.

Security teams should also log the agent’s prompts, tool invocations, file diffs, and approval events so that changes are attributable. That audit trail matters because incident response often depends on distinguishing a legitimate automated change from an unsafe action triggered by manipulated context. The MITRE ATLAS adversarial AI threat matrix is useful for thinking about prompt injection, model abuse, and downstream manipulation of agent behaviour, while the CSA MAESTRO agentic AI threat modeling framework helps teams model tool-chain and delegation risks.

• Use least privilege for repositories, build systems, and cloud APIs.
• Require human approval for runtime-impacting files and privilege-bearing changes.
• Prevent the agent from reading or emitting secrets unless there is a specific, reviewed use case.
• Validate generated code through tests, policy checks, and diff review before merge.
• Separate experimental workspaces from production-connected workflows.

Where possible, pair the agent with policy as code, branch protections, and signed commit workflows so the security model is enforced by the pipeline rather than by memory or convention. These controls tend to break down when agents are connected to shared service accounts and broad CI/CD permissions because one compromised delegation path can affect multiple repositories and environments.

Common Variations and Edge Cases

Tighter agent controls often increase developer friction, requiring organisations to balance delivery speed against the risk of unsafe autonomous changes. Best practice is evolving on how much autonomy to allow, especially for agents that can open pull requests, run migrations, or adjust infrastructure code without a prompt for every step. There is no universal standard for this yet, so the governance model should reflect the organisation’s risk tolerance and release criticality.

One common edge case is a low-risk development sandbox that later becomes connected to shared credentials, artifact registries, or a production-like dataset. Another is an agent that cannot directly deploy code but can edit a config file that changes authentication, logging, or network exposure. Those changes can be more dangerous than ordinary source edits because they alter control planes rather than application logic. The strongest pattern is to treat any file that can influence runtime behaviour as a protected asset requiring explicit approval.

For oversight design, the most practical control objective is not perfect prevention but constrained blast radius. The agent should be able to help, but not to self-authorise privileges, persist new tooling, or bypass review. The current generation of guidance from OWASP Top 10 for Agentic Applications 2026 and related research is converging on this point, especially where tool access and code execution intersect with identity and environment trust.

Related resources from NHI Mgmt Group

• How should organisations govern AI agents that can modify repository code?
• How should organisations govern libraries that download data after installation?
• Why do coding agents complicate governance for software identities?
• How should security teams govern non-human identities at scale?