Multi-party approval: when one human isn't enough

Human-in-the-loop approval is the foundation of safe AI agent operations. But "human in the loop" is not a binary. There is a world of difference between a single tired engineer rubber-stamping a command at 3:17 AM and a structured multi-party review that requires sign-off from two independent reviewers with the right roles and context. Most teams start with single-approver workflows because they are simple. This post explains why that breaks down, what to replace it with, and how to configure it in expacti.

Why single-reviewer setups fail

A single approver seems fine until you examine the failure modes. There are at least three ways it breaks in practice, and all of them are predictable.

Single point of failure

Your reviewer is a human being. They get sick. They take vacations. They have dentist appointments on Tuesday afternoons. When your sole approver is unavailable, every pending agent command sits in a queue until they return, or someone bypasses the process entirely because production is on fire and "we'll fix the approval chain later." In practice, the bypass becomes permanent. Teams that depend on a single reviewer inevitably build escape hatches that undermine the entire approval workflow.

Insider risk

If one compromised account can approve any command an AI agent generates, your approval layer is a single key away from meaningless. An attacker who gains access to the reviewer's session — through credential theft, session hijacking, or a compromised workstation — can approve destructive commands without any additional check. This is not a theoretical risk. Credential-based attacks account for the majority of initial access vectors in breach reports year after year. Multi-party approval means an attacker needs to compromise multiple independent accounts simultaneously, which is a fundamentally harder problem.

Off-hours coverage gaps

Commands that arrive at 3 AM get approved faster and with less scrutiny than commands that arrive at 2 PM. This is well-documented in analogous domains: medical error rates spike during night shifts, security analysts miss more alerts after midnight, and code review quality drops on Friday afternoons. A single approver at 3 AM is likely tired, possibly on-call and handling multiple incidents, and strongly motivated to clear the queue so they can go back to sleep. The approval becomes a speed bump, not a gate.

The three approval policies in expacti

Different operations have different risk profiles, and different organizations have different compliance requirements. Expacti supports three approval models, each designed for a distinct class of problem.

AllOf — everyone in the group must approve

The strictest model. Every reviewer in the designated group must independently approve before the command executes. If any reviewer denies, the command is blocked. If any reviewer does not respond within the timeout window, the command is denied by default.

Use case: Irreversible operations with high blast radius. Database schema migrations that alter production tables. Infrastructure changes that affect multiple services. Anything where "undo" is not a realistic option and getting it wrong has a cost measured in hours of downtime or lost data.

The trade-off is speed. AllOf is inherently slower because it requires all parties to be available. This is a feature, not a bug — it forces teams to plan irreversible operations rather than running them ad hoc.

AnyOf — any one person from a designated group can approve

A pool-based model. You define a group of eligible reviewers and the system notifies all of them. The first person to respond handles the approval. This is the model you want for on-call rotations and distributed teams where you need 24/7 coverage without requiring a specific individual to be available.

Use case: Routine production operations where you need a human check but cannot guarantee a specific person is online. Deploys during business hours, scaling operations, config changes to non-critical services. The on-call primary, on-call secondary, and engineering manager are all eligible — whoever is available picks it up.

AnyOf scales naturally. As your on-call rotation grows, you add members to the group without changing the policy. Response times improve because the probability that at least one member is immediately available increases with group size.

MinRole — requires a reviewer with a minimum role level

A hierarchical model. The command can be approved by anyone, but the approver must hold a role at or above a specified level — for example, admin or security-lead. This is not about availability; it is about authority and context.

Use case: Operations where the risk is organizational, not just technical. Changes to IAM policies, security group rules, billing configurations, or compliance-sensitive infrastructure. A junior engineer might not have the context to evaluate whether an IAM policy change opens a privilege escalation path. A security lead will.

Real use case: database schema migration

Consider a production database schema migration. The application team has written an ALTER TABLE that adds a column and backfills data for 50 million rows. Getting this wrong could lock the table during peak traffic, corrupt data, or cause the application to throw errors on a schema it does not expect.

With single-approver review, the on-call engineer glances at the command, sees "ALTER TABLE" and approves it. They do not know whether the migration will acquire a table lock. They do not know the current table size or peak traffic window.

With AllOf multi-party approval, three reviewers must independently sign off:

• The dev lead confirms intent — "yes, this is the correct migration for the feature we are shipping."
• The DBA confirms safety — "this ALTER will use an online DDL strategy and will not lock the table. The backfill is batched."
• The security lead confirms compliance — "the new column does not store PII and does not require additional encryption at rest."

Each reviewer catches different categories of problems because they bring different expertise. The DBA catches the table lock the dev lead would miss. The security lead catches the PII exposure the DBA would not think to check. This is not redundancy — it is complementary expertise applied at the right moment.

Regulated industries

If you operate in a regulated industry, multi-party approval is not optional. The specifics vary by framework, but the principle is consistent: no single individual should have unchecked authority over critical operations.

Finance: the four-eyes principle

Dual control (the "four-eyes principle") is a foundational requirement in financial services. Any transaction or system change above a risk threshold must be reviewed by at least two independent parties. This applies to infrastructure changes, not just financial transactions. If an AI agent is executing commands on systems that process financial data, every command is in scope. Expacti's AllOf and AnyOf models map directly to dual control requirements — two independent reviewers, documented in an immutable audit trail.

Healthcare: HIPAA change control

HIPAA's Security Rule requires covered entities to implement procedures for authorizing access to electronic protected health information (ePHI). Change management controls must ensure that modifications to systems handling ePHI are reviewed and authorized by appropriate personnel. An AI agent executing commands on systems that store or process patient data needs documented, multi-party authorization. MinRole is particularly relevant here: only reviewers with the appropriate clearance level should approve commands that touch ePHI-adjacent systems.

SOC 2: CC6.1 separation of duties

SOC 2 Common Criteria 6.1 requires logical access security controls, including separation of duties. The person who develops or configures a system should not be the same person who approves changes to production. For AI agents, this means the engineer who configures the agent's behavior should not be the sole approver of the commands it generates. Expacti enforces this structurally: the requesting identity is automatically excluded from the eligible reviewer set, and policy rules can require reviewers from a different team or role than the requester.

How to configure in expacti

Multi-party approval is configured through approval policies in your config.toml. Each policy specifies a name, a pattern to match commands against, a requirement type, and the eligible reviewers.

[[approval_policies]]
name = "schema-migration"
pattern = "migrate*"
requirement = "all_of"
reviewers = ["dev-lead", "dba", "security"]

[[approval_policies]]
name = "on-call-approve"
pattern = "*"
requirement = "any_of"
reviewers = ["oncall-primary", "oncall-secondary", "eng-manager"]

[[approval_policies]]
name = "prod-deploy"
pattern = "deploy*"
requirement = "min_role"
min_role = "admin"

The schema-migration policy uses AllOf: all three reviewers must approve any command matching migrate*. The on-call-approve policy uses AnyOf: any one person from the on-call pool can approve general commands. The prod-deploy policy uses MinRole: only a reviewer with the admin role (or higher) can approve deploy commands.

You can also manage approval policies through the reviewer dashboard. Navigate to the Approval Policies tab, where you can create, edit, and reorder policies. The UI shows a live preview of which commands each policy will match, making it straightforward to verify coverage before saving changes.

Anti-pattern: approval theater

The most common failure mode of multi-party approval is not technical — it is human. "Approval theater" is what happens when every reviewer rubber-stamps without reading. You have two or three sign-offs in the audit log, but nobody actually evaluated the command. You have satisfied the letter of the policy while completely missing the point.

This happens when reviewers lack context. If the approval notification says "approve this command: kubectl apply -f deploy.yaml" and nothing else, the reviewer has no basis for evaluating risk. They approve because they trust the requester, not because they reviewed the action.

Expacti addresses this with three mechanisms:

• Risk scores provide context. Every approval request includes a computed risk score based on the command, the target environment, the time of day, and historical patterns. A reviewer who sees "risk: high — this command modifies production IAM policies and has never been executed before" engages differently than one who sees a raw command string.
• Anomaly detection flags suspicious patterns. If an agent suddenly generates a command type it has never used before, or targets an environment it does not normally access, expacti flags the anomaly in the approval request. This draws the reviewer's attention to exactly the commands that deserve scrutiny.
• The audit trail shows review quality. Expacti logs not just who approved, but how long they took to decide. A reviewer who approves 15 commands in 8 seconds is not reviewing — and that pattern is visible in the audit trail. Teams can set minimum review time thresholds to prevent instant rubber-stamping.

The goal is not to make approval slower. It is to make the approval moment meaningful — to give reviewers the information they need to make a real decision in a few seconds, rather than a performative one in zero seconds.