Release authority

The permission and process that allow code to move into production. In AI-assisted environments, release authority should remain separate from generation authority so that a model can draft code without being able to ship it. That separation is a core governance boundary.

Expanded Definition

Release authority is the control point that determines who, or what, can approve and promote software into production. In modern delivery pipelines, that authority is distinct from code generation, build execution, and test automation, especially when AI agents can produce code faster than humans can review it. The governance objective is not to slow delivery for its own sake, but to ensure that the actor able to draft or modify code is not automatically the actor able to release it. That separation aligns with the broader identity and access discipline described in the NIST Cybersecurity Framework 2.0, where access, change control, and recovery are treated as distinct operational concerns.

Definitions vary across vendors when release authority is bundled into CI/CD tooling, ticketing workflows, or environment permissions, so practitioners should treat it as a governance boundary rather than a single product feature. In NHI and agentic AI programs, release authority must also account for machine identities that trigger deployments, sign artifacts, or approve policy exceptions. The most common misapplication is giving the same service account both build privileges and production release rights, which occurs when pipeline convenience is prioritised over separation of duties.

Examples and Use Cases

Implementing release authority rigorously often introduces friction in delivery flow, requiring organisations to weigh deployment speed against stronger assurance that production changes are intentional and reviewable.

• A developer commits code, but a separate approver with production release authority must sign off before the pipeline can deploy.
• An AI coding agent creates a patch, while a human or tightly scoped release service account performs the final promotion step.
• A change-management system requires a production deployment token that is different from the token used to run tests or publish artifacts.
• An NHI review finds that a CI service account can merge, build, and release, so the team splits duties and rotates the release credential.
• An incident response drill uses release authority logs to identify who approved a risky deployment and when it was executed.

These patterns become more defensible when paired with the NHI lifecycle and secret governance guidance in Ultimate Guide to NHIs, especially in environments where deployment automation is heavily credentialed. They also map cleanly to the identity assurance and access control concepts in NIST Cybersecurity Framework 2.0 because release rights are a privileged action, not a routine operational task.

Why It Matters in NHI Security

Release authority matters because production access is often held by non-human identities long after the original design intent has faded. NHIMG reports that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means release credentials can be copied, reused, or exposed without detection. Once a release token, API key, or deployment credential is compromised, an attacker may not need to steal a human password at all. That is why release authority must be treated as a high-value NHI control surface, not just an engineering workflow detail. The same logic supports least privilege, separation of duties, and rapid revocation when a pipeline or agent is suspected of misuse.

Understanding release authority is also essential in AI-assisted delivery because generation authority can be delegated to a model while release authority must remain constrained and auditable. Without that separation, an agent with tool access can move from suggestion to production change with no meaningful barrier. Organisations typically encounter the consequences only after a bad deployment, credential leak, or agent misuse event, at which point release authority becomes operationally unavoidable to address.

For broader context on how hidden non-human access expands risk, see the Ultimate Guide to NHIs and the governance expectations described in the NIST Cybersecurity Framework 2.0.

Related resources from NHI Mgmt Group

• What is the difference between identity governance and authority governance?
• What is the difference between access visibility and access authority?
• What is the difference between delegated user access and machine authority for AI agents?
• What is the difference between delegated access and agent authority?