Agentic development increases risk because the volume and pace of generated code can exceed what humans can review effectively. When agents produce most of the application, infrastructure, and integration logic, security findings arrive too late if they are only checked in pull requests. Continuous analysis in the development loop is needed to keep control coverage aligned with production impact.
Why This Matters for Security Teams
Manual pull request review assumes security can keep pace with human developers, but agentic development changes the operating model. Agents generate code, infrastructure, tests, and integration glue continuously, which means risk appears faster than reviewers can inspect it. That gap matters because security defects are no longer confined to a single commit; they can be propagated across workflows, toolchains, and deployment logic before a human ever sees the change. The practical issue is not just code quality, but review latency against autonomous execution. Guidance in the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to runtime governance as a core requirement, not a post hoc assurance step. NHIMG research on OWASP NHI Top 10 shows how quickly agent-driven environments expand the blast radius when identity and authorization are not continuously controlled. In practice, many security teams encounter the failure only after an agent has already chained tools, merged unsafe changes, or deployed a risky dependency, rather than through intentional review.
How It Works in Practice
Agentic development environments need controls that operate inside the build and execution loop, not only at the merge gate. The most effective pattern is continuous analysis combined with runtime authorization: the agent should prove what it is, request only the access needed for the current task, and lose that access when the task ends. That is why workload identity matters so much for autonomous systems. Instead of relying on a long-lived user account, teams should bind actions to a verifiable workload identity and issue short-lived credentials or tokens per task, then revoke them automatically.
This approach aligns better with policy-as-code than with static approvals. Runtime policy evaluation can compare the agent’s intent, the requested tool, the target resource, and the risk level before allowing an action. That is the operational direction reflected in the CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix, especially where tool use, prompt injection, and indirect control flow can alter the agent’s path in real time. NHIMG’s Analysis of Claude Code Security is a useful example of why code scanning, policy checks, and secret handling must move earlier in the development loop.
- Use JIT credentials for each task or repo action, not persistent developer tokens.
- Scope agent permissions to the minimum tool, branch, environment, or dataset required.
- Evaluate policy at request time, with context about the task and the destination resource.
- Scan generated code, configs, and dependency changes continuously, not just during PR review.
- Revoke access automatically when the agent completes or changes tasks.
These controls tend to break down in fast-moving multi-agent pipelines because one agent can inherit or amplify another agent’s mistake before the policy engine or reviewer catches it.
Common Variations and Edge Cases
Tighter runtime control often increases delivery overhead, so organisations have to balance speed against assurance. That tradeoff is real: excessive prompts for approval can slow teams enough that they bypass the control entirely, while weak controls let autonomous code ship unchecked. Current guidance suggests there is no universal standard for this yet, especially for highly parallel agentic workflows where one agent writes code, another tests it, and a third opens deployment changes.
There are also edge cases where manual review still has value. For small, well-bounded changes, humans can spot design flaws that automated policy engines may miss. But for large-scale agent output, review should be treated as one layer among several, not the primary control. NHIMG research in the State of Non-Human Identity Security shows that weak visibility, inadequate rotation, and over-privileged accounts remain common failure modes, which is exactly why agentic environments need short-lived identity and tighter telemetry. The security lesson is simple: manual review can validate intent, but it cannot keep up with autonomous throughput or chained tool execution. In environments with long-lived shared credentials, multi-tenant build runners, or delegated agent-to-agent handoffs, the guidance breaks down because the reviewer cannot see or stop the full sequence fast enough.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AP-1 | Agentic code creation raises tool-use and prompt-injection risk. |
| CSA MAESTRO | T1 | MAESTRO covers agent threat modeling and runtime trust boundaries. |
| NIST AI RMF | AI RMF governance supports continuous oversight for autonomous systems. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived credentials reduce exposure from autonomous workload abuse. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero trust fits agentic environments that need continuous authorization. |
Assign ownership for agent risks and verify controls throughout the development lifecycle.
Related resources from NHI Mgmt Group
- How should security teams govern machine identity credentials in agentic AI environments?
- How should security teams limit the risk from AI agents that have access to production systems?
- Why do ERP environments increase identity risk for security teams?
- Why do abuse mailboxes create more risk when teams rely on manual review?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org