How should security teams govern coding agents that can execute repository instructions?

Why This Matters for Security Teams

Coding agents are not passive tooling. When they can read repository instructions and execute tasks, unreviewed files such as AGENTS.md become a control plane for action, not just context. That changes the risk model: repository content can direct shell commands, trigger secret reads, or steer destructive changes before a human ever sees the plan. Current guidance suggests treating these instructions as executable input and governing them with the same caution used for untrusted code.

This matters because the agent’s authority often extends beyond the prompt. A malicious pull request, dependency update, or copied instruction block can redirect the agent into credential paths, CI artifacts, or deployment scripts. The lesson is consistent with NHI governance: trusted execution must be explicit, bounded, and revocable. NHI Management Group research has shown that long-term credentials and poor visibility remain common failure points, as documented in Ultimate Guide to NHIs, while agentic attack patterns are now being catalogued in OWASP NHI Top 10. In practice, many security teams discover instruction abuse only after the agent has already executed the repository’s hidden agenda rather than through intentional code review.

How It Works in Practice

Governance starts by separating repository instructions from trusted policy. An agent should not auto-execute AGENTS.md, README directives, or task-specific prompt files unless those artefacts have been reviewed, scoped, and approved. Security teams should classify repository instructions as untrusted input, then place decision authority outside the model so the agent cannot self-authorise risky actions. That means pre-task checks, explicit allow or block gates, and logging of the exact instruction source that influenced execution.

Operationally, this works best when the agent runs with a constrained workload identity and just-in-time access. A build or coding agent should receive only the secrets, tokens, or filesystem reach required for the current task, and those credentials should expire automatically when the task ends. This aligns with the runtime decision model described by the NIST AI Risk Management Framework and the agent-specific threat modeling in CSA MAESTRO agentic AI threat modeling framework. Teams should also inspect instruction files for shell invocation, package installation, environment-variable disclosure, credential-path access, and any request to modify security controls. NHI Management Group’s Amazon Q AI Coding Agent Compromised analysis illustrates why these files cannot be treated as harmless documentation.

• Review repository instructions before the agent is allowed to run unattended.
• Use policy-as-code to decide whether the task may proceed, not the model’s own judgment.
• Restrict secret exposure to the minimum task scope and revoke credentials on completion.
• Log instruction provenance, command execution, and file access for later review.

These controls tend to break down in monorepos and CI pipelines where the agent can traverse many directories, inherit broad workspace access, and chain instructions across multiple files without a clear human approval point.

Common Variations and Edge Cases

Tighter instruction governance often increases friction, requiring teams to balance developer speed against the risk of autonomous execution. That tradeoff is real, especially in environments that rely on agentic code review, automated refactoring, or large-scale dependency remediation. Best practice is evolving, and there is no universal standard for how much repository content an agent may trust by default.

Edge cases include trusted internal repositories that still accept external pull requests, forks that reuse the same agent config, and generated codebases where instruction files are produced by other automation. In those environments, a clean repository origin does not guarantee clean instructions. Security teams should assume that any repo-facing instruction surface can be poisoned and should pair approval workflows with content scanning and provenance checks. The broader industry direction is consistent with OWASP Agentic AI Top 10 and MITRE ATLAS adversarial AI threat matrix, which both emphasize runtime abuse paths rather than static prompt safety alone.

The practical rule is simple: if the agent can execute repository instructions, those instructions must be governed like code execution input, not prose. That approach is especially important when agents have access to deployment keys, package registries, or production-adjacent automation.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that use OAuth access?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern machine identity credentials in agentic AI environments?
• How should security teams manage permissions for AI agents?