Use AGENTS.md for stable project instructions, then add structured, task-scoped controls for architecture, security, and dependency decisions. The most reliable model is layered: a short instruction file, live repository analysis, and verification checks that operate on the specific change. That approach governs behaviour at the moment it matters, rather than hoping prose survives context drift.
Why This Matters for Security Teams
Coding agents are not governed well by static prose alone because their most consequential actions happen in context, not in a README. A short instruction file can set intent, but it cannot reliably judge whether a change crosses an architecture boundary, introduces a risky dependency, or creates an unsafe production path. Teams need controls that inspect the live repo state, the proposed diff, and the specific task before approving action. That is the real governance problem: keeping the agent aligned with project rules while also constraining what it may do when the request becomes ambiguous or high impact. This is especially important when agents can open pull requests, edit infrastructure, or modify dependency graphs. Those capabilities turn routine coding assistance into change authority, which means review quality matters as much as model quality. NIST Cybersecurity Framework 2.0 is useful here because the Govern and Protect functions map cleanly to defining agent authority, monitoring change outcomes, and enforcing approval gates around risky operations. For teams building AI workflows, the NIST AI Risk Management Framework also helps frame governance as an ongoing control process rather than a one-time prompt design exercise. In practice, many failures show up only after the agent has already made a plausible but context-blind change.How It Works in Practice
Effective governance for coding agents usually follows a layered control model. AGENTS.md should remain the stable baseline for local conventions, but it should be treated as one input, not the control plane. The stronger pattern is to combine it with repository-aware checks that evaluate the current branch, file paths, dependency changes, and risk level of the task before the agent acts. That lets teams separate low-risk edits from changes that touch build pipelines, auth flows, release scripts, or dependency resolution. A practical setup often includes:- short, durable instructions in AGENTS.md for style, scope, and safe defaults;
- task-scoped policy checks that classify the requested change before execution;
- automated verification for tests, dependency updates, and sensitive-file edits;
- explicit human approval for architecture, security, or release-impacting changes.
Common Variations and Edge Cases
Tighter governance often increases friction, so teams have to balance velocity against blast-radius reduction. A lightweight agent editing documentation does not need the same guardrails as an agent modifying infrastructure code or dependency manifests. The control model should therefore be tiered by task sensitivity, not applied as a single blanket rule that either blocks everything or allows too much. One common edge case is partial trust in repo instructions. If AGENTS.md conflicts with branch policy, dependency policy, or security review rules, the higher-integrity control should win. Another is multi-repo or mono-repo work, where the agent can cross boundaries and inherit assumptions from the wrong project. In those cases, repo-local instructions need to be validated against the actual target context before the agent acts. The practical question is whether the agent is making a reversible edit or a change that can alter runtime behavior, supply chain trust, or release safety. Where AI governance is a larger organisational concern, the NIST AI Risk Management Framework and the NIST Cybersecurity Framework 2.0 both support the same underlying judgment: instructions are not enough without verification, accountability, and bounded authority. A useful rule is to treat any agent action that can change production behavior, credential handling, or dependency trust as a controlled operation, not a normal edit.Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV — Govern | Agent governance needs defined authority and oversight. |
| PR.IP — Information Protection Processes and Procedures | Repo-scoped checks and verification are core protective procedures. | |
| Recommendation — Define agent authority, review thresholds, and accountability for risky changes. Require task-specific verification before agent changes are accepted. | ||
| NIST AI RMF | GOVERN — GOVERN | Coding agents need ongoing AI governance and accountability controls. |
| Recommendation — Establish oversight, roles, and escalation for agent actions that can affect production. | ||
| OWASP Agentic AI Top 10 | A1 — Prompt Injection and Instruction Hierarchy Abuse | Agents governed by repo instructions remain exposed to instruction conflicts and misuse. |
| A3 — Tool Misuse and Privilege Abuse | Coding agents can misuse repository and deployment tools if over-authorised. | |
| A4 — Memory, Context, and State Poisoning | Task-scoped governance must handle stale or misleading context in agent workflows. | |
| Recommendation — Add policy checks that override or block unsafe agent instructions. Limit tool scope and require approval for high-impact actions. Validate current repository state before trusting agent-generated changes. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Agent actions often need assurance about who or what is authorised to act. |
| Recommendation — Bind high-risk actions to stronger identity assurance and approval paths. | ||
Practitioner Guidance
What to prioritise: Put decision gates around the changes that can alter security posture, release integrity, or dependency trust. If the agent can only draft text, the control burden is low; if it can modify code that reaches production, governance must become much stricter.
What to verify: Verify that the agent’s allowed actions are enforced by tooling, not just by instruction quality. The key check is whether the system can still stop an unsafe change when the prompt is vague, overbroad, or adversarially shaped.
Decision rule: If the task affects architecture, security logic, dependency selection, or deployment paths, require live repository context plus explicit verification before acceptance. If it is a low-risk local edit, keep the controls lighter so the workflow stays usable.
Practitioner takeaway: The best governance model does not ask whether the agent followed instructions, it asks whether the system made the unsafe action impossible, detectable, or reviewable before impact.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
