It becomes risky when generation outpaces verification. If teams cannot review diffs, validate behavior, and trace failures at the same pace they ship changes, the agent is effectively writing policy faster than the organisation can govern it. That gap is where insecure defaults, broken auth flows, and hidden regressions enter production.
Why This Matters for Security Teams
Agentic coding changes the risk model because the system is no longer just suggesting text, but initiating code changes, calling tools, and sometimes chaining actions across repositories and pipelines. That means ordinary review habits can miss failures in dependency selection, permissions, prompt handling, or insecure code paths. Guidance from the NIST AI Risk Management Framework is useful here because it treats governance, measurement, and monitoring as core controls rather than afterthoughts.
The security question is not whether the model is “good at coding,” but whether the surrounding controls can constrain what it is allowed to change, validate what it produces, and detect when it drifts outside acceptable behavior. That distinction matters for code review, CI/CD trust, secret handling, and release approvals. The most common mistake is assuming a faster author is automatically a safer engineer, when the real issue is whether the organisation can enforce review depth and accountability at machine speed. In practice, many security teams encounter agentic coding failures only after a merge has already propagated bad assumptions into production, rather than through intentional control testing.
How It Works in Practice
Security teams should evaluate agentic coding as a workflow risk, not just a model risk. The agent may draft code, open pull requests, execute tests, query documentation, or propose refactors, but each step expands the attack surface if permissions are broad or validation is weak. The right question is what the agent can access, what it can change, and what evidence exists before a change is accepted.
A practical control model usually includes:
- Least-privilege access to repositories, issue trackers, build systems, and secrets stores.
- Human approval for merges that affect authentication, authorisation, crypto, infrastructure, or data flows.
- Automated checks for dependency integrity, insecure patterns, unit and integration test coverage, and policy violations.
- Logging that preserves prompts, tool calls, diff output, and reviewer decisions for later investigation.
- Restricted use of secrets so the agent cannot embed, exfiltrate, or misuse credentials during generation.
This is where agentic AI guidance overlaps with software supply chain security. The OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework both reinforce the need to model tool misuse, prompt injection, and unsafe autonomy as first-class risks. The practical outcome is to gate high-impact code paths, test the agent against malicious inputs, and treat generated code as untrusted until it passes the same controls as human-authored code. These controls tend to break down in fast-moving environments with weak branch protection and direct-to-main release habits because there is no stable review boundary.
Common Variations and Edge Cases
Tighter control often increases delivery overhead, requiring organisations to balance speed against assurance. That tradeoff is real, especially when teams use agents for prototyping, internal tooling, or low-risk refactoring. Best practice is evolving, and there is no universal standard for how much autonomy is acceptable for every codebase.
Edge cases usually appear when the environment is more sensitive than the workflow suggests. A small code change can become a major security event if it touches identity flows, privilege boundaries, payment logic, or production secrets. In those cases, the agent may be productive for scaffolding, but not for direct implementation without review. The same caution applies when the model is asked to write tests for security-sensitive behavior, because weak tests can create false confidence rather than assurance.
Security teams should also distinguish between code generation and code execution. An agent that can run commands, modify files, or call deployment tools has materially more power than one that only drafts snippets. The NIST Cybersecurity Framework 2.0 is helpful here because it ties governance to protection, detection, and response instead of treating coding quality as a standalone concern. For adversarial behaviour patterns, the MITRE ATLAS adversarial AI threat matrix is especially relevant when prompts, tools, or outputs can be manipulated by external inputs.
Where the guidance becomes less certain is in highly autonomous development pipelines. Current guidance suggests caution, but the exact threshold between productivity gain and security risk depends on review maturity, blast radius, and how much trust is placed in the agent’s execution authority.
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, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI governance and monitoring are central when coding agents can act with execution authority. | |
| OWASP Agentic AI Top 10 | Agent tool misuse, prompt injection, and unsafe autonomy are core risks in this scenario. | |
| MITRE ATLAS | Adversarial input and manipulation techniques map directly to agentic coding abuse paths. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is critical when agents can touch repos, CI, and secrets. |
| CSA MAESTRO | Agentic workflows need threat modeling across tools, autonomy, and trust boundaries. |
Apply govern-map-measure-manage practices before allowing agentic code changes into production.
Related resources from NHI Mgmt Group
- When does identity security become a business risk rather than a technical issue?
- When does automated code review become a governance risk instead of a productivity gain?
- When does break-fix IT become a security risk rather than just an efficiency problem?
- When does Salesforce access become a security risk rather than an admin task?
