How can organisations decide whether AI should write code while humans retain security responsibility?

A practical split is to let AI handle implementation tasks while humans own architecture, threat modelling, and security oversight. That division works only if teams define clear review thresholds, escalation paths, and approval requirements for risky changes. Without that boundary, non technical users can ship functional software without the judgment needed to secure it.

Why This Matters for Security Teams

Letting AI generate code can speed delivery, but it also changes who is responsible for secure design, secure review, and release approval. The core risk is not that AI writes code, it is that teams mistake output quality for security assurance. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant because secure development still requires defined controls, accountable approvals, and evidence that changes were tested before release.

For security leaders, the decision is really about operating model. If humans retain responsibility, then they must own architecture decisions, threat models, code review standards, secret handling, dependency approval, and exception handling. AI can assist with implementation, but it cannot be the control owner for risk acceptance. Current guidance suggests that the more autonomy AI has, the more explicit the guardrails must be around what it can change, what it can merge, and what must always be escalated.

In practice, many security teams discover the boundary only after an AI-generated change has already bypassed review expectations or introduced an unsafe pattern into production.

How It Works in Practice

The safest operating model is to treat AI as a coding assistant, not a decision-maker. Humans define the secure architecture, the data handling requirements, and the change-risk thresholds. AI then drafts code, tests, refactors, or documentation, but the release path still depends on human review. That review should be based on the sensitivity of the system, the blast radius of the change, and whether the code touches authentication, authorization, secrets, cryptography, or external integrations.

For practical control design, organisations usually separate low-risk from high-risk work:

• Low-risk tasks: formatting, scaffolding, unit-test generation, benign refactoring, and non-sensitive documentation.
• Medium-risk tasks: feature implementation behind feature flags, internal tooling, and code that still requires standard peer review.
• High-risk tasks: identity flows, payment logic, security tooling, privilege changes, production configuration, and any code handling secrets.

That split is strongest when paired with secure SDLC controls, protected branches, mandatory code review, secrets scanning, dependency checks, and policy-based CI/CD gates. It also helps to log when AI was used, what prompt context was provided, and who approved the final change. For teams managing agentic or semi-autonomous systems, this becomes part of software supply chain governance as well as application security.

Security teams should also validate outputs against known attack patterns and secure coding guidance. OWASP guidance on software and AI-assisted development, plus control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls, can be used to anchor review requirements in policy rather than ad hoc judgment.

These controls tend to break down when AI is allowed to make production-impacting changes in fast-moving environments with weak review discipline because the approval step becomes a formality instead of a real security gate.

Common Variations and Edge Cases

Tighter human approval often increases delivery friction, requiring organisations to balance speed against risk tolerance. That tradeoff becomes more visible in startups, platform teams, and highly automated DevOps environments where developers want near-instant merges. Best practice is evolving here: there is no universal standard for how much autonomy an AI coding tool should have, so policy must reflect the system’s sensitivity rather than a blanket rule.

One important edge case is non-technical users generating code with AI in low-code or internal tooling platforms. Even if the output is functional, the approval burden should not disappear, because security failures often come from insecure defaults, overbroad permissions, or hidden data exposure. Another edge case is regulated environments, where the right answer may be to constrain AI to suggestions only for production code while allowing broader autonomy in sandboxes and prototypes.

Where AI is connected to privileged credentials, production APIs, or deployment automation, the model should be treated as an implementation aid only and never as the final security authority. Human owners should remain accountable for risk acceptance, exceptions, and release sign-off, especially when code changes authentication, authorization, logging, or data retention behaviour.

Related resources from NHI Mgmt Group

• How should organisations decide whether to buy AI security tools through procurement channels?
• Should organisations let AI write remediation code directly from security findings?
• How can organisations decide whether their AI security workflow is mature enough?
• How do organisations decide whether to standardise on one agentic AI security control model?