Should organisations let the same workflow generate code and sign off on it?

Why the same workflow should not both create and approve code

Separate code generation from code approval because those are different control functions. Generation is supposed to produce a change; approval is supposed to challenge it, catch defects, and confirm it meets security and operational expectations. If one workflow does both, the review step becomes ceremonial, and risky code can move forward without a meaningful second set of eyes.

That separation matters most when the generated code can touch shared libraries, deployment pipelines, infrastructure, or production-facing systems. A workflow that can both write and bless changes concentrates trust in one place, which weakens defect detection and makes it easier for insecure logic, hidden dependencies, or unsafe assumptions to pass through as if they had been independently validated.

The issue is not whether automation can help. It can. The issue is whether the approval step remains independent enough to be a real control instead of an extension of the same actor, prompt, or pipeline. In practice, independence is what turns review into a gate rather than a rubber stamp.

Where independence breaks down in practice

The most common failure mode is role collapse. The same agent, script, or user that produced the change also decides it is acceptable, so the review no longer tests the change against a separate judgment standard. That is especially dangerous when the workflow has access to secrets, build credentials, or deployment rights, because the generated output can inherit the same privileges used to approve it. See CISA Secure by Design for the broader product-security principle that controls should be built so risky defaults do not slip through unchecked.

A second failure mode is review-by-same-context. If the approval step only rechecks what the generator already knew, it will tend to confirm the same assumptions instead of testing them. That is why code review, change approval, and release authorization work best when they are owned by different roles, different tooling permissions, or at least different decision paths. The control is strongest when the approver can reject the change without also owning its creation.

A third failure mode is privilege reuse. When the same workflow can both create and approve code, it often means the same credentials can also access repositories, artifacts, or release systems. That creates a broad blast radius if the workflow is misused or compromised. NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support the underlying principle that access, change control, and integrity checks should be separated enough to reduce systemic error and abuse.

What a safer approval model looks like

A safer design keeps generation, review, and release authorization distinct, even if they are all automated parts of the same delivery pipeline. The approver should be able to inspect diffs, test results, policy checks, and provenance signals without sharing the same execution authority that created the code. That can be a human reviewer, a separate policy engine, or a second automated control, but it should not be the same workflow path that authored the change.

Where identity and secrets are involved, the control should also prevent self-approval through shared service credentials or overly broad tokens. If a generator can sign its own output and also authorize deployment, the organisation has not separated duties in any meaningful sense. That pattern is exactly where least privilege and independent verification become operational requirements rather than nice-to-have governance language. OWASP Non-Human Identity Top 10 is a useful reference when those workflows depend on machine credentials, and NIST AI Risk Management Framework reinforces the need for oversight where automated systems influence consequential outcomes.

For teams using AI-assisted development, the practical standard is simple: the system may propose, but it should not be the sole authority that approves its own output. If you cannot explain how the approver is independent, how the approval is logged, and how exceptions are handled, then the workflow is too collapsed to trust.

Risk and Threat Considerations

When creation and approval share one workflow, the main risk is that malicious or defective code can be laundered through an apparently valid process. That weakens defect detection, makes policy exceptions harder to spot, and can let unsafe changes reach shared environments before anyone outside the workflow has a chance to challenge them.

Failure mechanism: The same automated path that generates code also grants it legitimacy, so approval no longer provides independent scrutiny and can be bypassed by assumption, automation, or compromised credentials.

Impact: Insecure code, hidden dependencies, or malicious logic can reach production faster, increasing the chance of outage, privilege abuse, supply-chain contamination, or persistent exposure across shared systems.

Practitioner Guidance

What to prioritise: Separate authoring from approval first, then check whether any workflow can both alter code and bless its release. If that exists, treat it as a segregation-of-duties problem, not just a tooling preference.

What to verify: Confirm that the reviewer can reject a change without sharing the same credentials, execution context, or automation path that produced it. Also verify that approval leaves an audit trail showing who or what approved, what evidence was reviewed, and whether any exception was used.

Common mistake: Teams often count a second automated check as independent review when it is only a rerun of the same logic. That is useful for validation, but it is not the same as a separate approval control.

Practitioner takeaway: The goal is not to eliminate automation from code delivery, but to prevent the same trusted path from both creating and certifying change. Independence is what makes approval meaningful.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?