Skip to main content
The MultiPartyChallenge is the strongest verification mechanism in Attesta. It requires two or more independent approvers, each completing a different sub-challenge, before a critical action is allowed to proceed. This prevents any single point of failure in the approval process.

​
When It Is Used

By default, MultiPartyChallenge is assigned to CRITICAL risk actions (score 0.8–1.0). These are irreversible, destructive operations like dropping databases, deleting production infrastructure, or purging user data.
ParameterDefaultDescription
required_approvers2Number of independent approvers needed
min_review_secondsInheritedEach sub-challenge uses its own minimum review time
The Trust Engine enforces a safety invariant: CRITICAL actions are never downgraded, regardless of trust score. Even a maximally trusted agent will always face multi-party approval for critical operations.

​
Sub-Challenge Rotation

Each approver receives a different sub-challenge, assigned in a rotating pattern:
ApproverSub-ChallengeMin Review
1stTeachBackChallenge30.0s
2ndQuizChallenge10.0s
3rdConfirmChallenge3.0s
4thTeachBackChallenge (rotation restarts)30.0s
5thQuizChallenge10.0s
………
The rotation order is: teach-back -> quiz -> confirm -> teach-back -> … This design ensures:
  1. The first approver must deeply understand the action (teach-back)
  2. The second approver must demonstrate comprehension (quiz)
  3. Subsequent approvers provide independent confirmation at lighter levels
  4. No two consecutive approvers face the same challenge type
All approvers must pass their respective sub-challenges. If any single approver fails or denies, the entire multi-party challenge fails and the action is blocked.

​
Usage

from attesta.challenges import MultiPartyChallenge

# Default: 2 approvers
multi = MultiPartyChallenge()

# Stricter: 3 approvers required
multi = MultiPartyChallenge(required_approvers=3)

# Use in a custom challenge map
from attesta import Attesta, RiskLevel

attesta = Attesta(
    challenge_map={
        RiskLevel.LOW: None,
        RiskLevel.MEDIUM: "confirm",
        RiskLevel.HIGH: "quiz",
        RiskLevel.CRITICAL: MultiPartyChallenge(required_approvers=3),
    }
)

​
Approval Flow

When all approvers pass:
StageApprover 1Approver 2
Actiondrop_database("prod") — Risk: 0.92 (CRITICAL)Same action context
Sub-challengeTeach-Back (30.0s min)Quiz (10.0s min)
ResultPASSPASS
OutcomeALL PASSED — Action Executes
When any approver fails:
StageApprover 1Approver 2
Sub-challengeTeach-BackQuiz
ResultPASSFAIL
OutcomeBLOCKED — AttestaDenied raised

​
Approver Identity

Each approver is identified by an approver_id, which is recorded in the audit trail. This enables post-hoc analysis of who approved what. 
# Approver IDs are recorded in the audit entry
{
    "action_name": "drop_database",
    "challenge_type": "multi_party",
    "challenge_passed": True,
    "approver_ids": ["alice@company.com", "bob@company.com"],
    "verdict": "approved",
}
In production environments, integrate approver identification with your organization’s SSO or identity provider. The approver ID should be a verifiable identity, not a self-reported name.

​
Terminal Experience

The TerminalRenderer presents multi-party challenges sequentially, showing progress: Approver 1 prompt (Teach-Back):
CRITICAL RISK — Multi-Party Approval Required (Approvals: 0/2) Action: drop_database | Arguments: database="production" | Risk: 0.92 (CRITICAL) APPROVER 1 — Teach-Back In your own words, explain what this action will do and what its impact will be. (minimum 15 words)
After the first approver passes (Quiz):
CRITICAL RISK — Multi-Party Approval Required (Approvals: 1/2) APPROVER 2 — Quiz Q1: Which database will be dropped? a) staging, b) production, c) development, d) testing

​
Configuration via YAML

attesta.yaml
policy:
  challenge_map:
    critical: multi_party

  multi_party:
    required_approvers: 3

  min_review_seconds:
    teach_back: 30.0
    quiz: 10.0
    confirm: 3.0

​
Scaling Approvers by Domain

Domain profiles can override the number of required approvers for specific action types:
attesta.yaml
domains:
  - healthcare:
      escalation_rules:
        phi_access: 3        # PHI access requires 3 approvers
        data_export: 3       # Data export requires 3 approvers
  - infrastructure:
      escalation_rules:
        production_deploy: 2  # Production deploys need 2
        database_drop: 4      # Database drops need 4

TeachBackChallenge

The first sub-challenge in the rotation

Trust Engine

Why CRITICAL actions are never downgraded