The Two-Sided Invariant: Formal Mirroring of Render-Time UI Controls and Distributed Write-Path Authorization in Autonomous Swarms

#Abstract

In modern human-in-the-loop and multi-agent platforms, user interfaces frequently present interactive mutation controls (e.g., “Approve”, “Reject”, “Deploy”) based on simplified, render-time visibility checks (e.g., status === 'review'). However, the backend write-path endpoints enforcing those mutations typically evaluate a multi-layered security matrix (role-based access control, squad boundaries, capability grants, assignment constraints, and seat liveness). This asymmetry produces the False-Promise UI Anti-Pattern: an interface promises execution capability to an operator, only for the subsequent network request to fail with HTTP 403 Forbidden. In autonomous AI swarms, this gap leads to catastrophic execution loops, where agents repeatedly attempt impossible actions.

In this paper, we formalize the Two-Sided Authorization Invariant: the mathematical requirement that the boolean predicate governing UI control rendering must be provably equivalent to the authorization predicate guarding the corresponding mutation endpoint. We analyze the theoretical failure modes of decoupled authz predicates, present the reference implementation of the canCallerVerdictTask evaluation engine in Mupot, and provide empirical forensic data from Flight-008 (PR #1076, PR #1081).

We show how enforcing formal render/write parity eliminates deadlocked agent loops, prevents operator disorientation, and guarantees that interactive web surfaces serve as honest projections of distributed system capability.

#1. Introduction: The False-Promise Pathology in Agentic Systems

In classical web development, UI authorization is often treated as an aesthetic concern: buttons are hidden or disabled based on crude role checks, while the backend API serves as the “true” security perimeter.

graph TD
    subgraph The Decoupled Vulnerability: False-Promise UI
        U[Operator / Agent View] -->|Renders UI via naive check| B{can_verdict: Simple Status Check}
        B -->|Returns true| C[Renders Active 'Approve' Button]
        C -->|Operator Clicks Submit| API[POST /api/tasks/123/verdict]
        API -->|Enforces 5-Gate Write Security Matrix| GATE{Complex Authz Check}
        GATE -->|Fails Gate 3: Scope Mismatch| ERR[HTTP 403 Forbidden: Execution Deadlock]
    end

    subgraph The Two-Sided Invariant: Zero-Gap Parity
        V[Operator / Agent View] -->|Evaluates shared engine| ENG[canCallerVerdictTask: Unified 5-Gate Matrix]
        ENG -->|Evaluates FALSE for Caller| DOM[Button Structurally Omitted from DOM + Diagnostic Text Rendered]
        ENG -->|Evaluates TRUE for Caller| DOM2[Button Rendered & Guaranteed 200 OK on Submit]
    end

While a human user encountering an unexpected 403 Forbidden modal experiences frustration, an autonomous AI agent encountering a 403 Forbidden on an active UI control frequently enters an infinite retry loop. The agent observes the button on the DOM, reasons that it possesses the right to click it, submits the action, receives an error, re-reads the page, sees the active button again, and repeats the cycle until token exhaustion.

To eliminate this failure mode, Mupot establishes the Two-Sided Authorization Invariant.

#2. Mathematical Formalization of the Two-Sided Invariant

Let $\mathcal{U}$ be the set of authenticated callers (human operators or agent principals), $\mathcal{T}$ be the set of target tasks, and $\mathcal{A}$ be the set of allowable mutation actions (e.g., $\text{approve}, \text{reject}$).

Let $\mathcal{S}$ represent the current global state of the database (memberships, capabilities, squads, task states).

#2.1 The Write-Path Authorization Predicate

The mutation endpoint POST /api/tasks/:id/verdict is protected by a write-path authorization predicate $\Psi_{\text{write}}$: $\Psi_{\text{write}}: \mathcal{U} \times \mathcal{T} \times \mathcal{A} \times \mathcal{S} \to \{0, 1\}$ The API guarantees: $\text{ExecuteMutation}(u, t, a) \iff \Psi_{\text{write}}(u, t, a, \mathcal{S}) = 1$

#2.2 The Render-Path Visibility Predicate

The UI rendering engine evaluates whether to present an interactive control to caller $u$ for task $t$ via a render predicate $\Phi_{\text{render}}$: $\Phi_{\text{render}}: \mathcal{U} \times \mathcal{T} \times \mathcal{S} \to \{0, 1\}$ Where $\Phi_{\text{render}} = 1$ causes the button to be rendered in the DOM, and $\Phi_{\text{render}} = 0$ causes the button to be structurally omitted.

#2.3 The False-Promise Metric (Theorem 1)

Definition 1 (False Promise): A state tuple $\langle u, t, \mathcal{S} \rangle$ represents a False Promise if the UI presents an action control that the backend will reject: $\text{FalsePromise}(u, t, \mathcal{S}) \iff \Phi_{\text{render}}(u, t, \mathcal{S}) = 1 \land \Big( \forall a \in \mathcal{A}, \Psi_{\text{write}}(u, t, a, \mathcal{S}) = 0 \Big)$

Theorem 1 (Two-Sided Invariant): A software platform is immune to False-Promise deadlocks if and only if for all reachable states $\mathcal{S}_{\text{reachable}}$ and all $u \in \mathcal{U}, t \in \mathcal{T}$: $\Phi_{\text{render}}(u, t, \mathcal{S}) = 1 \iff \exists a \in \mathcal{A}, \Psi_{\text{write}}(u, t, a, \mathcal{S}) = 1$

#3. The 5-Gate Security Matrix in Mupot

In Mupot, write-path authorization for reviewing tasks is governed by a 5-Gate Conjunction:

$\Psi_{\text{write}}(u, t, a, \mathcal{S}) = G_{\text{admin}}(u) \lor \Big( G_{\text{squad}}(u, t) \land G_{\text{owner}}(u, t) \land G_{\text{cap}}(u, t) \land G_{\text{scope}}(u, t) \Big)$

                                    5-Gate Authorization Matrix
                                                │
         ┌──────────────────┬───────────────────┼───────────────────┬──────────────────┐
         ▼                  ▼                   ▼                   ▼                  ▼
1. Sovereign Admin    2. Squad Boundary    3. Gate Owner       4. Capability Grant 5. Outreach Scope
   • org:admin        • caller ∈ squad     • sole resolved     • caller holds      • task-type
     bypass             or tenant-wide       principal           gate:<owner>        permitted

1. $G_{\text{admin}}$ (Sovereign Admin Bypass): Callers with org:admin capability can unblock orphaned or deadlocked tasks.
2. $G_{\text{squad}}$ (Squad Boundary Confinement): The caller must belong to the squad owning task $t$.
3. $G_{\text{owner}}$ (Gate Owner Resolution): The task’s gate_owner field must resolve to a valid, active principal.
4. $G_{\text{cap}}$ (Capability Grant Validation): The caller must possess a cryptographic capability grant matching the required gate lane (gate:athena, gate:kasra-core).
5. $G_{\text{scope}}$ (Outreach / Action Scoping): The action must not violate domain-specific policy boundaries (e.g. outreach:send-gated).

#4. Empirical Case Study: The Flight-008 Incident (PR #1076 & PR #1081)

During Flight-008 Slice 2, Kasra implemented PR #1076 to humanize the /approvals queue.

#4.1 The Defect

The initial implementation of can_verdict in src/dashboard/approvals.ts evaluated:

// Naive render check in PR #1076
const can_verdict = Boolean(resolvedGateOwner && resolvedGateOwner.status === 'active');

#The Forensic Failure:

1. can_verdict checked whether a gate owner existed on the task, but did not check whether the current viewing caller $u$ held the capability to execute that gate.
2. A viewer with zero capabilities viewing an Athena-gated task (gate_owner = 'gate:athena') was presented with active “Approve” and “Reject” buttons.
3. Upon clicking “Approve”, the browser issued POST /api/tasks/:id/verdict, which evaluated $\Psi_{\text{write}}$ and rejected the request with 403 Forbidden.

#4.2 The Architectural Split & Resolution

An Opus correctness lens flagged the violation: authorizing render-time buttons on a loose check while rejecting write-time requests is an architectural contradiction.

Loom immediately ordered an architectural split:

1. Flight-008 was re-scoped to land Slices 1 and 3.
2. Flight-008b (Issue #1081) was spawned to extract a single, shared evaluation engine:

// src/gates/grants.ts
export function canCallerVerdictTask(
  caller: AuthenticatedCaller,
  task: TaskRow,
  grants: CapabilityGrant[]
): { allowed: boolean; reason?: string } {
  // Evaluates the exact 5-Gate Matrix shared by both render-time and write-time paths
  if (hasCapability(caller, "org:admin")) {
    return { allowed: true };
  }
  if (!isCallerInSquad(caller, task.squad_id)) {
    return { allowed: false, reason: "Caller outside squad boundary" };
  }
  const resolvedOwner = resolveGateOwner(task.gate_owner, grants);
  if (!resolvedOwner || !callerHoldsGateGrant(caller, resolvedOwner)) {
    return { allowed: false, reason: `Waiting for ${task.gate_owner} grant holder` };
  }
  return { allowed: true };
}

#5. Structural DOM Omission vs. Visual Disabling

A common anti-pattern in web security is rendering a disabled button (<button disabled>) with client-side CSS. Mupot rejects this approach.

#5.1 Why Disabled Buttons Fail in Agentic Systems

Language model vision and DOM parser tools inspect button elements and text nodes. A disabled button with an accessible label still signals to an agent that the capability exists, prompting the agent to draft plans around requesting elevation or waiting for enablement.

#5.2 The Mupot Structural Omission Standard

When canCallerVerdictTask evaluates to false:

1. The <button> element is completely omitted from the HTML payload.
2. An explanatory, diagnostic state badge is rendered in its place (e.g. [Pending: gate:athena sign-off]).
3. This guarantees that neither human nor AI agent can attempt an impossible write action.

#6. Architectural Axioms for Two-Sided Authorization

1. Axiom of Single-Source Evaluation: The logic determining UI action visibility and backend API authorization must reside in the exact same shared library function.
2. Axiom of Structural Omission: If a caller lacks write authority, the corresponding interactive DOM control must not exist in the rendered output.
3. Axiom of Diagnostic Replacement: Every suppressed mutation control must be replaced by a human-readable and agent-parseable explanation of why the action is blocked and who possesses authority to unblock it.
4. Axiom of Idempotent Replay: Batch mutation endpoints (POST /batch-verdict) must execute each item through single-item authorization pipelines with conditional UPDATE guards, ensuring duplicate submissions are safe no-ops.

#7. Conclusion

In autonomous multi-agent environments, user interfaces are not mere presentation layers; they are active sensory fields for decision-making agents. Decoupling render-time checks from write-time security perimeters introduces false promises that induce execution deadlocks and break operator trust.

The Two-Sided Authorization Invariant restores mathematical symmetry to web interfaces, ensuring that every rendered control represents a guaranteed, executable action.

#References

1. Saltzer, J. H., & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. Proceedings of the IEEE, 63(9), 1278–1308.
2. Mumega Synthetic Council. (2026). Paper 200.401: Falsificationist Substrates for Multi-Agent Systems: Beyond Tautological Task Execution. Mumega Paper Series.
3. Mumega Synthetic Council. (2026). Paper 200.402: Kill-Witness Verification: Adversarial Falsification of Code in Autonomous AI Swarms. Mumega Paper Series.
4. Mumega Synthetic Council. (2026). ADR-007: Domain-Substrate Decoupling and Autonomous Gate Governance. Mumega Architecture Repository.
5. Mumega Synthetic Council. (2026). ADR-009: Mupot Company-Layer Organs & Capability Matrix. Mumega Architecture Repository.