Yes. The deployer should be able to request a change without automatically inheriting the permissions of the build identity that executes it. That separation limits blast radius, preserves accountability, and prevents a legitimate automation path from becoming a privilege escalation channel. It also makes access review more meaningful because the executor's rights are explicitly governed.
Why split deployer access from executor access?
Human deployer access and build executor access should be separate because they represent different trust boundaries. A person requesting or approving a release should not automatically gain the rights the build system uses to perform the release. That separation keeps the execution path narrowly scoped, reduces the damage of compromised credentials, and preserves a cleaner approval trail.
The practical difference is between authority to initiate change and authority to perform it. When those are merged, a deployer can accidentally inherit broad system, repository, environment, or signing permissions that were meant only for automation. Keeping them distinct makes the build identity easier to reason about and prevents a routine delivery workflow from turning into a standing privilege channel.
This separation also improves auditability. A reviewer can assess whether the human action was authorised and whether the executor had only the rights needed for that specific job. It becomes easier to answer who requested the change, which identity executed it, and whether the executor’s permissions were appropriate for the target environment.
Where the separation matters most in delivery pipelines
The control is most important when the build executor can touch production systems, signing keys, release registries, deployment credentials, or infrastructure APIs. Those are high-impact privileges, so the executor should hold only the minimum access required to assemble, sign, package, and deploy. The human deployer may be permitted to approve, trigger, or request the release, but not to impersonate the executor or reuse its credentials.
That distinction is especially valuable when deployments are automated across multiple environments. A build identity that can publish artifacts, mutate configuration, or interact with cloud control planes should be tightly bounded to the pipeline step that needs it. If the same permissions are handed to the requester, you lose the ability to tell whether access was needed for release execution or merely convenient for the operator.
Teams should also treat executor credentials as lifecycle-managed secrets rather than shared convenience accounts. Rotating, scoping, and recording those credentials separately from human access makes revocation faster when a person changes role, leaves a team, or loses trust in their workstation. The executor should remain a controlled machine path even when the deployment process itself is human-approved.
How to keep the two roles cleanly separated
Use distinct identities, distinct authentication paths, and distinct permissions for the human and the build system. The human account should control the request or approval step, while the executor account should only perform the release action and related technical tasks. If a workflow needs escalation, add an explicit approval or temporary delegation step rather than reusing the executor’s standing access.
Document which actions belong to the human and which belong to automation, then test that boundary during access review. A good review asks whether the deployer can reach the same systems the executor can, whether that access is necessary, and whether any token, key, or certificate gives the person an indirect way to act as the executor. The answer should be no unless the design intentionally requires a short-lived exception.
For delivery pipelines, the safest pattern is least privilege plus traceable delegation. The release request should carry intent, the executor should carry authority to execute only the approved job, and the logs should preserve that distinction. If a team cannot explain that split in one sentence, the access model is usually too coarse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain provenance and integrity | Build execution and release integrity depend on separating request and execution trust. |
| Recommendation — Enforce provenance and integrity checks on release artifacts before deployment. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Executor credentials must be lifecycle-managed and distinct from human access. |
| AC-6 — Least Privilege | Separate roles so deployers do not inherit executor permissions. | |
| Recommendation — Rotate and govern build credentials separately from deployer accounts. Limit each identity to only the permissions needed for its role. | ||
| CIS Controls v8 | CIS-5 — Account Management | Distinct human and automation identities require separate account governance. |
| Recommendation — Inventory and control build and deploy accounts as separate managed identities. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about access separation between a person and an executor identity. |
| Recommendation — Define and enforce access rules that keep approval and execution roles separate. | ||
Practitioner Guidance
What to prioritise: Separate approval authority from execution authority first, then audit whether any shared credential, token, or service account still lets a person act as the build identity. That is the fastest way to expose hidden privilege overlap.
What to verify: Confirm that the build executor can complete the pipeline without interactive human access, and that the deployer cannot reuse executor credentials to bypass the intended approval path. If either condition fails, the separation is incomplete.
Common mistake: Teams often preserve convenience by giving operators access to the same automation account used by CI/CD. That shortcut usually creates the exact privilege-escalation path the separation was meant to remove.
Practitioner takeaway: Treat deployment as a controlled delegation chain, not a shared admin role, and keep the executor’s authority narrower than the person who asked for the change.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org