A taxonomy for describing how much of the software development lifecycle is performed by AI rather than humans. It helps security and engineering leaders classify control points, review burden, and governance needs as teams move from assisted coding to delegated agents and increasingly autonomous delivery.
What the taxonomy measures
Levels of autonomy in software development describe how far development work shifts from human execution toward AI-led execution. The taxonomy is useful because autonomy changes who sets intent, who validates outputs, and where control boundaries still need to be enforced.
At the lowest end, AI is mainly an assistant that suggests code, tests, or documentation while a person remains the primary decision-maker. As autonomy increases, the system begins to plan tasks, chain tools, make intermediate choices, and carry out more of the delivery workflow with less direct human prompting.
How autonomy changes the development lifecycle
Autonomy is not a single feature, it is a progression across design, coding, review, testing, release, and rollback. A team may allow AI to draft a function but still require humans to approve merges, approve production changes, or sign off on infrastructure updates.
The most important shift is not just faster output, but the changing distribution of control. Higher autonomy can reduce manual effort, yet it also increases the need to define which steps are advisory, which are supervised, and which are delegated. That distinction determines whether the AI is merely assisting development or participating in delivery authority.
This is why autonomy taxonomies are often used alongside agentic AI terminology: they help separate an AI-assisted workflow from one where the system is acting with broader delegated behaviour.
Why the taxonomy matters for control and governance
For security and engineering leaders, the value of the taxonomy is that it turns a vague discussion about “using AI in development” into a clearer control model. Each higher level of autonomy can imply more review burden, stronger approval gates, tighter tool scoping, and clearer ownership for changes made by the system.
It also helps distinguish between productivity gains and governance debt. A low-autonomy assistant may fit inside existing code review and change-management processes, while a more autonomous workflow may require explicit policy decisions about what can be generated, what can be executed, and what must remain human-approved.
Used well, the taxonomy creates a shared language for engineering, security, and risk teams to discuss where accountability sits when AI contributes to software delivery.
Common ways the concept is misunderstood
One common mistake is treating all AI development tools as if they belong at the same maturity level. A code completion tool, a repo-aware coding assistant, and an autonomous delivery agent may all improve productivity, but they do not create the same control posture.
Another misunderstanding is assuming that autonomy is only about code generation. In practice, the more significant governance question is whether the system can act on development assets, modify repositories, trigger pipelines, or influence release decisions without direct human intervention.
For that reason, the taxonomy is best read as a control and accountability model, not just a description of how helpful the tool feels to the user.
Risk and Threat Considerations
As autonomy increases, the blast radius of a mistake or compromise can expand from a single suggestion to broader workflow manipulation. Higher-autonomy systems can accelerate unsafe code changes, pipeline abuse, secret exposure, or unintended deployment actions if their permissions and review checkpoints are too loose.
Failure mechanism: The system is allowed to perform more of the development lifecycle than the organisation has actually governed, so tool access, execution rights, and review expectations drift apart. That gap creates an opening for prompt abuse, poisoned inputs, overbroad credentials, or unsafe automation to reach source control and delivery systems.
Impact: Organisations can end up with faster release paths but weaker assurance, especially when AI-generated changes are merged, tested, or shipped with insufficient human scrutiny. The result can be insecure code, broken releases, or control failures that are hard to trace back to the point where autonomy was granted.
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 addresses the attack and risk surface, while NIST AI RMF, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Higher autonomy changes who can act and with what authority. |
| ASI08 — Cascading Failures | Autonomous development workflows can amplify one error across delivery stages. | |
| Recommendation — Constrain delegated actions with per-step approval and least privilege. Limit automation scope and add containment around chained actions. | ||
| NIST AI RMF | Govern | Autonomy levels define accountability, oversight, and governance for AI-enabled development. |
| Recommendation — Define ownership, approval gates, and oversight for each autonomy tier. | ||
| NIST SP 800-53 Rev 5 | CM-3 — Configuration Change Control | Autonomous code and pipeline changes depend on controlled change approval. |
| Recommendation — Require formal approval before AI-driven changes reach controlled environments. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Autonomous development affects how software is produced and reviewed before release. |
| Recommendation — Apply secure development and review controls to AI-assisted code paths. | ||
Practitioner Guidance
Governance implication: Treat autonomy level as a policy decision, not a product setting. The practical question is which lifecycle steps remain human-approved, which can be delegated, and which need stronger monitoring, narrower permissions, or explicit rollback authority.
What to watch for: Review whether the AI is only producing content, or is also acting on repositories, pipelines, tickets, or deployment workflows. Once the system can initiate actions rather than simply suggest them, the organisation should treat that as a materially different operating mode with corresponding controls.
Related resources from NHI Mgmt Group
- Why do AI pipelines expose more credential risk than traditional software development?
- Why do AI-assisted development pipelines change software trust requirements?
- Why does software supply chain security matter more in AI-assisted development?
- How do identity and NHI controls fit AI-assisted software development?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
