A control pattern that separates code generation from code validation so the same system does not approve its own work. In agentic development, this reduces bias, improves auditability, and creates a defensible review trail for engineering, security, and compliance teams.
Expanded Definition
Maker-checker split is a governance control pattern, not a single technology. It requires one actor or system to create an artefact and a separate actor or system to validate, approve, or reject it. In software and security operations, the pattern is used to reduce self-approval risk, expose flawed logic before deployment, and preserve a review trail that supports accountability. For NHIMG, the most important distinction is that maker-checker split applies to both human workflows and autonomous software workflows, including AI agents that can generate code, policies, or configuration changes.
In agentic development, this pattern becomes especially relevant because an AI agent with execution authority can produce changes faster than a human reviewer can inspect them. That is why organisations often combine maker-checker split with code review, signed approvals, and restricted deployment permissions. The idea aligns with governance principles reflected in the NIST Cybersecurity Framework 2.0, even though no single standard formally names maker-checker split as a standalone control. Industry usage is still evolving, and some vendors apply the label to any two-person review, which can be misleading when one party is effectively rubber-stamping the other.
The most common misapplication is treating maker-checker split as satisfied when the same pipeline, account, or agent can both generate and approve a change.
Examples and Use Cases
Implementing maker-checker split rigorously often introduces workflow latency, requiring organisations to weigh faster delivery against stronger assurance and clearer accountability.
- A developer creates a code change, but a separate reviewer signs off before merge, preventing a single person from approving their own insecure implementation.
- An AI coding agent drafts infrastructure-as-code, while a human security engineer checks for secrets exposure, unsafe permissions, and policy drift before deployment.
- A platform team uses separate service accounts for change creation and release approval so one automation path cannot both propose and publish privileged configuration.
- A finance or compliance workflow requires one operator to prepare an access request and another to verify justification, preserving a defensible audit trail.
- A security orchestration flow blocks incident-response automation from approving its own high-risk actions, forcing independent confirmation for destructive or irreversible steps.
Patterns like this are commonly discussed alongside software assurance practices and secure development guidance in public-sector references such as the NIST Cybersecurity Framework 2.0, especially where separation of duties supports stronger decision quality.
Why It Matters for Security Teams
Maker-checker split matters because many security failures begin when the same identity can create, alter, and approve a sensitive change without independent scrutiny. That collapse of separation increases the risk of hidden backdoors, misconfigured access, unreviewed secrets, and policy exceptions that bypass normal governance. For security teams, the control is as much about evidencing trustworthy process as it is about catching technical defects. It gives auditors and risk owners a way to verify that high-impact changes were not self-approved.
The identity and agentic-AI angle is increasingly important. When an AI agent can open pull requests, adjust infrastructure, or trigger deployment steps, maker-checker split becomes a practical guardrail against autonomous self-approval. Strong implementations tie approval rights to distinct identities, distinct trust boundaries, and immutable logs. That is consistent with broader control objectives in NIST Cybersecurity Framework 2.0, especially around access control, change governance, and accountability.
Organisations typically encounter the consequences only after a privileged change is traced back to the same actor or agent that authored and approved it, at which point maker-checker split becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Supports separation of privileges so no single identity can self-approve sensitive changes. |
Separate change creation from approval and ensure distinct access rights for each step.
Related resources from NHI Mgmt Group
- How should security teams split identity governance from implementation work?
- How should organisations split responsibilities between IGA and PAM?
- What breaks when privileged access is split across multiple tools and platforms?
- What breaks when identity governance is split across vaults, IGA, and PAM tools?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
