Four-Eyes Principle

The core mechanism of the Four-Eyes Principle is the strict separation of duties between the initiator and the authorizer. One individual requests a critical action, such as a model deployment, while a second, independent individual must approve it.

• No Self-Approval: The initiator can never be the authorizer.
• Role-Based Access Control (RBAC): System permissions are configured to enforce this separation technically, preventing a single account from executing both steps.
• Conflict of Interest Prevention: This segregation directly mitigates the risk of a single malicious or compromised actor unilaterally executing a harmful transaction.

The second set of eyes must perform a genuine, independent verification of the action's validity and safety, not just a rubber-stamp approval.

• Contextual Review: The authorizer must examine the specific parameters of the request, such as the model version, the target environment, and the change window.
• Evidence-Based: The authorizer should verify the action against objective evidence, like successful test results, approved change tickets, or compliance checklists.
• No Assumed Trust: The principle operates on a zero-trust model where the authorizer's default stance is to question the necessity and correctness of the initiator's request.

Every application of the Four-Eyes Principle must generate a cryptographically verifiable, immutable audit trail that captures the complete dual-authorization event.

• Non-Repudiation: The log must definitively prove who initiated the action, who authorized it, and the exact timestamp of both events.
• Tamper-Proof Logging: Logs should be stored in a write-once, read-many (WORM) compliant system or a blockchain-anchored ledger to prevent post-hoc alteration.
• Compliance Evidence: This unbroken chain of custody serves as the primary evidence for auditors to prove that a critical change was properly governed and not executed unilaterally.

The principle is applied selectively to gate critical actions that carry high risk or have irreversible consequences, not to every routine operation.

• High-Risk Triggers: Common gated actions include deploying a model to production, pushing a configuration change to a live system, or approving a high-stakes automated decision.
• Policy-as-Code Enforcement: The requirement for a second approver is embedded directly into the CI/CD pipeline or decisioning engine, making it impossible to bypass programmatically.
• Break-Glass Exceptions: A strictly controlled and audited emergency procedure must exist for scenarios where a second approver is unavailable, with automatic escalation to a higher authority.

A robust implementation must be designed to resist collusion, where the initiator and authorizer conspire to approve a malicious action.

• Rotational Duties: Regularly rotating the pool of authorized approvers prevents the formation of stable, long-term pairs that could develop into a collusion risk.
• Multi-Person Approval Pools: Instead of a single designated approver, the system can require approval from any one member of a larger, dynamically selected group.
• Anomaly Detection: Monitoring systems should analyze approval patterns to detect statistical anomalies, such as the same two individuals consistently approving each other's requests outside of normal hours.

The principle does not require both individuals to be present simultaneously. Asynchronous authorization allows the approver to review and sign off on a request at a later time, within a defined validity window.

• Time-Bound Tokens: The approval request is cryptographically signed and valid only for a specific, short-lived time window to prevent replay attacks.
• Out-of-Band Verification: For extremely sensitive actions, the authorizer should confirm the request through a secondary communication channel, such as a verified voice call or a secure push notification, before granting digital approval.
• Workflow Integration: The pending approval is queued in the authorizer's workflow, with automated reminders and escalation if the request is not actioned before the deadline.

A structured, hierarchical procedure that defines how a deadlock in a Four-Eyes workflow is resolved. If the two required parties cannot reach an agreement, the decision is automatically routed to a higher authority.

• Tiered Authority: The protocol defines a clear chain of command, e.g., if two peer reviewers disagree, the issue escalates to a team lead, then to a department head.
• Time-Bound Resolution: Each escalation level has a defined SLA for response to prevent operational paralysis.
• Conflict Documentation: The rationale for both the initial disagreement and the final decision is recorded for auditability, ensuring the process is transparent even when overridden.