PaperlayerView exact revision on arXiv

Source-linked AI summary

AuthorityLens: Rethinking LLM-Based Agent Systems Through the Lens of Authority

Shaojin Chen, Huihao Jing, Wun Yu Chan, Wenbin Hu, Jiaxing Li, Wu Pandy Pui Ching, Kshitij Bhatia, Xinlei He, Haoran Li, Yangqiu Song

arXiv:2609.32378v1cs.AI

TL;DR

LLM-agent permission settings and review mechanisms do not necessarily reflect the authority realized in practice. AuthorityLens measures authority through outcome-level participant coalitions and compares 13 configurations across three agent systems. The results show that nominal modes can leave coverage similar while changing who can act alone, how much joint participation is needed, or whether added agents replicate authority.

  • Problem

    Agent evaluations measure task success or attack robustness, but not how configurations distribute authority among participants, even as agents act on consequential resources and decisions.

    Source: §1 · pp. 1–2

  • Method

    AUTHORITYLENS derives System Authority, Authority Separation, and Principal Authority from minimal sufficient Principal coalitions for outcomes in a declared portfolio.

    Source: §1 · p. 2

  • Results

    Across 13 configurations, nominal modes do not map cleanly to realized authority: Codex Full Access barely changes coverage but raises unilateral Assistant authority from 53% to 100%.

    Source: §1 · p. 3

  • Takeaways & Limitations

    More agents do not by themselves mean more checks; only authority separation increases the number of participants who must act together.

    Source: §7 · p. 9

    Measurements cover possible realizations, not their likelihood or harm, for pinned product versions over a declared portfolio.

    Source: §7 · p. 9

Abstract

from arXiv · show

LLM-based agents are increasingly deployed with authority over consequential resources and decisions in real systems. These agents often operate alongside human and LLM-based participants who hold different forms of authority. Yet workflow roles, permission settings, and review mechanisms do not necessarily reflect the authority realized in practice. We introduce AuthorityLens, a framework for measuring a system's authority structure. Starting from an authority portfolio, we evaluate a system along three dimensions: what the system is authorized to do (System Authority), how much joint participation is required to exercise that authority (Authority Separation), and how much authority each participant holds (Principal Authority). We derive these measurements from the minimal combinations of participants sufficient to realize each outcome across admissible runtime states. We apply AuthorityLens to Codex, OpenCode, and Gemini CLI across 13 operating configurations over a common portfolio of agent operations. We find that nominal configurations do not map cleanly onto realized authority. In Codex, Full Access changes System Authority only marginally while substantially concentrating authority in the executing Assistant. OpenCode's Build and Plan configurations have the same System Authority and Authority Separation despite different workflows and root-level permissions. In Gemini CLI, model-based review increases Authority Separation without changing System Authority. Principal Authority further distinguishes authority replication from authority separation: spawned or delegated agents can become alternative holders of the same authority without increasing the required joint participation. Together, these results demonstrate that AuthorityLens provides a unified framework for measuring and comparing realized authority structures across agent systems.

1 Introduction

LLM-agent permissions and review mechanisms need not match the authority a system realizes: the relevant question is which combinations of Principals can bring about each outcome. AuthorityLens measures those combinations and applies the framework to three agent systems.

1 Introduction

  • AUTHORITYLENS measures authority through minimal sufficient coalitions, deriving System Authority, Authority Separation, and Principal Authority from which groups of Principals can realize each outcome.A minimal sufficient coalition can realize an outcome, and removing any member makes it insufficient.Source: §1 · pp. 2–3
  • Authority replication adds an independent holder of existing authority, whereas authority separation makes joint participation necessary for the same realization.Both add agents, but only separation increases how many must act together.Source: §1 · p. 3
  • Codex Full Access realizes nearly the same outcomes as approval-based modes, but raises the share the Assistant can realize alone from 53% to 100%.OpenCode Build and Plan agree outcome by outcome, while Gemini Model Review increases Authority Separation without changing System Authority.Source: §1 · p. 3
  • The study evaluates 13 configurations of Codex, OpenCode, and Gemini CLI over Agent-599, a portfolio of 599 authority-relevant outcomes.The portfolio spans files, execution environments, host and network operations, identity and access, software delivery, data systems, and applications.Source: §1 · p. 3
  • A control changes authority only when it removes routes to an outcome or requires more Principals along routes that remain.The analysis identifies command-mediation bypasses in Codex and OpenCode, with consequences depending on whether a resource boundary still applies after admission.Source: §1 · p. 3

2 AuthorityLens: A Measurement Framework

AUTHORITYLENS represents authority through outcomes and the coalitions of participants able to realize them. It evaluates a fixed operating configuration across the runtime states it admits, then summarizes outcome coverage and required participation.

2 AuthorityLens: A Measurement Framework

  • AUTHORITYLENS describes authority through the outcomes a system can realize and the participation required, tracking each participant’s possible contribution.Its framework derives a system authority profile and Principal Authority from groups of Principals that jointly realize outcomes.Source: §2 · p. 3

2.1 Principals and Assigned Authority

  • A Principal is an attributable authority holder; its authority signature specifies permitted operations, resources, and approval relations.A configuration fixes system settings and authorization rules, while its admitted runtime states may vary in participants, resources, and bindings.Source: §2.1 · pp. 3–4

2.2 Outcomes and Authority Portfolio

  • The evaluation uses a finite, nonempty, versioned authority portfolio because no finite assessment can exhaust a general-purpose system’s resources and environments.Each outcome names a protected target, relevant conditions, and a completion criterion; requests and approvals may contribute without themselves being the measured outcome.Source: §2.2 · p. 4

2.3 Authority Structure

  • A minimal sufficient coalition can realize an outcome, and removing any member makes it insufficient; such coalitions capture unilateral or joint authority.Coalitions are collected across admissible runtime states without minimizing their union again, so participants need not coexist in every state.Source: §2.3 · p. 4

2.4 System Authority Profile

  • System Authority measures portfolio coverage, while Authority Separation averages the minimum participation required across realizable outcomes.The configuration-level minimum ranges across admitted states; Figure 2 plots System Authority v against Authority Separation m̄ for 13 configurations.Source: §2.4 · pp. 4–5, Figure 2 · p. 5

3 System Authority Profiles across Agent Systems

Across Codex, OpenCode, and Gemini CLI, nominal configurations do not consistently predict realized outcomes or required participation. The results show that access can remain nearly fixed while controls change who must act.

3.1 Codex: Full Access Concentrates Authority

  • 599 vs. 597 outcomes: Codex Full Access barely changes System Authority (1.000 vs. 0.997) but makes all outcomes unilateral, up from 53% in Ask and Auto.In Ask and Auto, 279 of 597 realizable outcomes require the Assistant and a reviewer; Full Access removes that separation.Source: §3.1 · p. 5

3.2 OpenCode: Workflow Restrictions Need Not Restrict Authority

  • 537 outcomes (v = 0.896): OpenCode Build and Plan realize the same outcomes, each through a single Principal, with no User participation required.Plan blocks native editing but retains shell access and delegation, leaving routes to the same outcomes.Source: §3.2 · p. 6

3.3 Gemini: Authority Separation Can Be Layered

  • Gemini CLI layers Authority Separation while System Authority stays fixed: Default, Auto-edit, and Yolo realize the same 552 outcomes (v = 0.922), with or without Model Review, requiring User confirmation for 473, 382, and seven, respectively.Source: §3.3 · p. 6
  • Model Review adds nearly one Principal to Gemini execution paths reaching its checker without changing System Authority; mean participation rises from 1.857 to 2.837 in Default and 1.013 to 1.993 in Yolo.Review preserves required User confirmation; only 11 validation-output outcomes remain unilateral because they complete before review.Source: §3.3 · p. 6
  • 76 outcomes (v = 0.127): Gemini Plan removes the shell entrypoint and routes, unlike OpenCode Plan, which retains shell execution and delegation.The Gemini Plan restriction reduces realizable outcomes rather than adding reviewers.Source: §3.3 · p. 6, §3.2 · p. 6

4 Principal Authority: Replication versus Separation

Principal Authority identifies which participants hold authority, distinguishing independent alternative holders from participants whose joint action is required. The distinction separates replication from separation even when both add agents.

4 Principal Authority: Replication versus Separation

  • Replication adds an independent holder of existing authority; separation makes an additional Principal necessary for the same realization.Only separation increases the number of Principals that must act together.Source: §4 · p. 6
  • Principal Authority measures capacity, not a normalized share: replication does not dilute an independent holder, while separation lowers its score when the smallest coalition grows.A positive score does not mean that Principal is globally indispensable.Source: §4 · pp. 6–7

4.1 Authority Replication Creates Alternative Holders

  • Codex spawned Assistants match the main Assistant’s Principal Authority—0.764 in Ask and Auto, and 1.000 in Full Access—so spawning adds independent holders without dividing authority.Eligible spawned Assistants inherit the main Assistant’s authority-relevant permissions and approval configuration.Source: §4.1 · p. 7
  • OpenCode Build executors across General, Explore, Build-child, and Plan-child classes each match the root at 0.896; Gemini replication ranges from full matching to native-read-only or none.Gemini Generalist matches the Assistant in shell-enabled modes, Investigator replicates native-read outcomes (0.115 without Model Review), and CLI Help scores 0.000.Source: §4.1 · p. 7

4.2 Authority Separation Creates Jointly Necessary Holders

  • In Codex Ask, 279 reviewed outcomes require both Assistant and User, each contributing 1/2; in Gemini Yolo with Model Review, Assistant scores 0.468 and reviewer 0.450.Only outcomes completed before review remain unilateral in the Gemini case.Source: §4.2 · pp. 7–8
  • Replication preserves the original holder’s score while increasing independent holders; separation lowers that score as the smallest coalition grows and increases required joint participation.Figure 3 reports class-level capacity scores, not normalized shares.Source: Figure 3 · p. 7, §4.2 · p. 8

5 Controls Change Authority Only by Changing Coalitions

Controls change realized authority only when they alter the minimal coalitions that can reach outcomes. The section distinguishes removing routes from requiring more participants on the routes that remain.

5 Controls Change Authority Only by Changing Coalitions

  • A control matters only if it changes minimal sufficient coalitions; blocking one request or interface is insufficient when another route reaches the outcome with the same coalition.Controls can remove realization routes or keep an outcome reachable while requiring more Principals.Source: §5 · p. 8
  • Bypassing request mediation removes a reviewer only when no resource boundary still applies: Codex sandboxes still constrain external deletion, while OpenCode’s admitted shell has no sandbox.Codex’s in-workspace deletions become unilateral, but external deletions still require the User in Ask or Guardian in Auto; OpenCode external-path review can be bypassed so the executor acts alone.Source: §5 · p. 8
  • OpenCode Plan blocks native editing but preserves shell and delegation routes, whereas Gemini Plan removes the shell entrypoint and reduces realizable outcomes from 552 to 76; Gemini Model Review instead adds a necessary reviewer.The distinction is route removal versus increased participation on routes that remain.Source: §5 · p. 8

6 Related Work

The related work connects AuthorityLens to task-level separation of duty, authority and least-privilege analysis, and LLM-agent safety research. It positions the framework as measuring the authority realized when a configuration’s controls and routes are composed.

6 Related Work

  • Task-level separation-of-duty research considers collective authority for completing sensitive tasks; AuthorityLens instead identifies the minimal Principal coalitions through which configured agent-system outcomes are realized [1, 3, 7].The cited task-level work does not prescribe a particular workflow.Source: §6 · pp. 8–9
  • Prior safety and least-privilege work designs or enforces individual controls, while AuthorityLens measures realized authority after controls and routes are composed [5, 6, 7].Principal Authority relates to cooperative-game power indices but measures capacity rather than dividing a fixed budget [1, 2].Source: §6 · p. 9
  • LLM-agent safety studies attacks, defenses, isolation, and multi-agent failure propagation; AuthorityLens complements this work by measuring authority that attacks can exploit and defenses must constrain [1, 2, 3].Source: §6 · p. 9

7 Conclusion

AuthorityLens measures realized authority through outcomes and the coalitions that can realize them, rather than relying on nominal settings or roles. The conclusion emphasizes that more agents do not necessarily create more checks, and controls constrain authority only when they change those coalitions.

7 Conclusion

  • Authority depends on outcomes reachable across admitted routes and the participation each outcome requires; these dimensions can vary independently.Adding agents can replicate existing authority or separate it across jointly necessary holders.Source: §7 · p. 9
  • The measurements cover possible realizations for pinned product versions and a declared portfolio, not their likelihood or harm.Missed routes make System Authority a lower bound and required participation an upper bound, while Principal Authority has no such bound.Source: §7 · p. 9

Ethics Statement

  • Authorization was evaluated through source inspection and experiments in controlled simulations using prepared resources, synthetic data, and credentials.Approval decisions were explicit branch inputs; command-mediation findings were privately reported, without implying maintainer confirmation, and executable bypass sequences were omitted.Source: Ethics Statement · p. 9

AI Use Statement

  • AI-assisted tools helped verify mathematical proofs, create figures, revise formatting and layout, and modify document-generation scripts.The authors take responsibility for the final manuscript and artifacts.Source: AI Use Statement · p. 10

Reproducibility Statement

  • Reproducibility materials specify portfolio construction, operating conditions, coalition recovery, pinned revisions, configurations, audits, and all 599 outcomes.The evaluation scope is tied to the pinned versions and outcome contracts; complete executable bypass sequences are omitted.Source: Reproducibility Statement · p. 10

A Foundations and Finite Representation of Authority

  • Appendix A maps main-text claims to supporting results, including finite representation for Proposition 1 and an additional invariance condition for Proposition 2.A.6 addresses complete pattern representation, while Appendices C–E examine Section 5 control mechanisms.Source: Figure 4 · p. 13, A Foundations and Finite… · p. 13

A.1 Coalition Semantics across Runtime States

  • The coalition semantics allow runtime states and Principal identities to vary while preserving identities across states.Minimal coalitions are formed within each state and retained across the configuration, so different states can contribute distinct necessary participants or realizations.Source: §A.1 · pp. 13–14

A.2 Principal Authority as Authority-Carrying Capacity

This section defines and characterizes Principal Authority, including its invariance and finite-representation properties, and describes the construction of Agent-599, the common outcome portfolio, and the procedure linking product audits and operation evidence to authority measurements.

A.2 Principal Authority as Authority-Carrying Capacity

  • Principal Authority is the largest local share a Principal can claim in any admissible minimal coalition, without normalizing across Principals.Adding an independent unilateral holder replicates authority without reducing an existing holder’s score; requiring an additional participant instead increases separation. A Principal can receive a positive score for a necessary role in a minimal coalition even if another route bypasses them.Source: §A.2 · pp. 14–15

A.3 Axiomatic Characterization

  • The unique rule satisfying local calibration and dominated-opportunity irrelevance assigns the reciprocal of a Principal’s smallest available coalition size, or zero if none exists.The measure depends on available coalition sizes, not their multiplicity or frequency; additional opportunities requiring at least as many participants do not change the score.Source: §A.3 · p. 15

A.4 Within-Class Invariance of Principal Authority

  • Under within-class participation-opportunity invariance, same-class instances have identical available coalition sizes and therefore identical Principal Authority for every outcome.The assumption concerns opportunities across admissible states and preserves the number of necessary participants, even when coalition partners differ.Source: §A.4 · p. 16

A.5 Exact Finite Representation of the Measures

  • A finite set of at most k + 1 witness states per outcome can exactly recover the measures, even when the class-pattern family is infinite.The witnesses retain a system-minimum coalition and each finite class minimum; recovering instance scores from class minima requires within-class invariance.Source: §A.5 · pp. 17–18

A.6 Complete Pattern Representation

  • With finitely many classes, a finite portfolio, and finite populations per state, bounded class multiplicities in minimal coalitions are equivalent to finite pattern families.This characterization does not require within-class invariance. Complete pattern coverage can be infinite even when a single singleton state suffices to recover finite measures.Source: §A.6 · pp. 18–19

B.1 Building a Common Authority Portfolio

  • Agent-599 covers 599 outcomes across seven themes and 46 categories, with equal weight assigned to every outcome.The portfolio includes 586 Linux-qualified and 13 macOS-qualified outcomes; equal weighting is a comparison convention, not a claim that outcomes are equally harmful, likely, or important.Source: §B.1 · pp. 19–20
  • Each portfolio entry is an operation contract specifying its target, initial conditions, admitted realization forms, completion criteria, and preservation or lifecycle requirements.For example, deployment requires a changed running application, while credential rotation requires activating the new credential and retiring the old one.Source: §B.1 · p. 20
  • Fixed environments determine operating conditions, while a fresh authorization or binding decision adds its supplying Principal to the coalition; existing grants do not.The same outcome contract applies across configurations, and superficially similar actions do not count when they violate its identity, process, session, lifecycle, or execution requirements.Source: §B.1 · p. 20

B.2 Connecting Product Audits to Outcome Measurements

  • Audits derive each configuration’s effective authority signatures, and controlled operation evidence supplies target-operation witnesses for all 599 outcomes under shared qualifications.Audits cover tool registration, resource scope, authorization, review, delegation, spawning, and runtime boundaries; targeted probes validate interaction-dependent behavior.Source: §B.2 · pp. 20, 22
  • Across all three products, a small number of programmable interfaces—especially general command execution—can mediate authority over hundreds of outcomes.Thus, the size of a tool surface can diverge sharply from the size of the authority surface.Source: §B.2 · p. 20
  • The analysis identifies statewise minimal sufficient coalitions across admitted routes, then derives System Authority, Authority Separation, and Principal Authority from those coalitions.Participation counts only contributions required for the target operation, and the analysis records 7,787 outcome–configuration records across 599 outcomes and 13 configurations.Source: §B.2 · pp. 20, 23

B.3 Reading the Results

Across 13 configurations, the measured outcome profiles show that nominal modes can differ in realized authority and that Codex authority depends on routes beyond direct command requests. The Codex audit distinguishes role classes and execution boundaries, then compares minimal coalitions across admissible routes.

B.3 Reading the Results

  • Codex Ask and Auto each realize 597 outcomes, Full Access 599; Gemini Plan realizes 76, and OpenCode Build and Plan each realize 537.Table 5 reports profiles for all configurations over the same 599 equally weighted outcomes.Source: Table 5 · p. 23, §B.3 · pp. 23–24

C Codex Structural Audit

  • Codex’s Guardian both reviews actions and independently exercises retained capabilities, while eligible spawned Assistants replicate the Assistant class’s authority.Session continuation can bypass command mediation while the workspace boundary remains effective.Source: C Codex Structural Audit · p. 24

C.1 Operating Configurations and Authority Classes

  • Codex audits three configurations and distinguishes the executing Assistant, human User, and Guardian reviewer as authority classes rather than treating role names as Principals.Spawning or termination can change the runtime Principal population without changing the operating configuration.Source: §C.1 · p. 24, §C.1.1 · p. 24

C.1.1 Authority Classes

  • The Guardian class contributes binding review decisions and independent execution under a read-only permission profile in the audited scope.The Guardian is Codex’s model-based Reviewer, a distinct review agent using a dedicated review model.Source: §C.1.1 · p. 25

C.1.2 Instance Notation

  • Ask and Auto share a sandbox boundary but assign binding review to different classes; Full Access changes both the execution boundary and mediation availability.An Assistant’s authority class depends on its operations, resource scopes, exercise conditions, and approval relations.Source: §C.1.2 · p. 25, §C.1.1 · p. 25

C.2 Authorization across Alternative Realization Routes

  • A rejected request rules out only that route; reviewer necessity requires excluding every admitted realization that succeeds without the reviewer in that state.Statewise minimal coalitions are collected across admitted states without minimizing their cross-state union again.Source: §C.2 · pp. 25–26

C.2.1 Native Patching and the Sandbox Boundary

  • For a native write outside initial writable roots, Ask and Auto require an Assistant and reviewer, while Full Access requires only the Assistant; review changes separation, not realizability.The example isolates native patching; the broader analysis also considers command execution and other admitted routes.Source: §C.2.1 · p. 26

C.2.2 Direct-Command Mediation

  • For all eight force-delete outcomes, direct requests alone yield a different coalition family: workspace deletion can include an unnecessary reviewer, while Full Access direct requests are rejected despite Assistant-only outcome minima.The analysis also considers alternative realization routes for the fixed outcomes.Source: §C.2.2 · p. 27, Table 9 · p. 27

C.2.3 Session Continuation Bypasses Command Mediation

Session continuation and equivalent command encodings bypass fresh-command mediation, but the workspace boundary still constrains external deletion. The resulting minimal coalitions distinguish removing unnecessary review from overcoming resource limits.

C.2.3 Session Continuation Bypasses Command Mediation

  • An admitted interactive shell can execute a force-delete continuation, and shell-variable encoding also avoids static recognition of the executable.The operation checks preserve target and control files; blocked external requests leave target entries intact rather than partially deleting them.Source: §C.2.3 · pp. 27–28
  • Ask and Auto complete five workspace deletions independently, while the three external deletions require review; Full Access completes all eight without review.Guardian completes none independently under its read-only profile, and external file-set and directory-tree deletions remain blocked like the external single-file case.Source: §C.2.3 · pp. 27–28
  • For workspace outcomes, the complete minimal family is the Assistant singleton, while external outcomes retain reviewed pairs; Full Access yields the Assistant singleton for every row.Alternative request encodings do not provide external target access, so the reviewed pairs remain minimal there.Source: §C.2.3 · p. 28
  • Shell continuation bypasses the command classifier, removing command mediation from internal-deletion coalitions while the filesystem boundary still constrains external deletion.The admitted shell session is not rechecked by the command policy classifier when supplied continuation bytes execute.Source: §C.2.3 · pp. 27–28

C.2.4 Alternative Implementations Remove Incidental Review

Outcome-level alternatives can remove review that a reference implementation appears to require, but alternative routes count only when they preserve the outcome contract. The audit also finds mutable Guardian authority under a read-only filesystem profile.

C.2.4 Alternative Implementations Remove Incidental Review

  • Eight outcomes have Assistant-only alternatives to reviewed reference implementations, showing that incidental cache or temporary-path access can overstate Authority Separation.The outcome contract, not a preferred implementation, determines minimality; examples include alternative package and environment operations and ACL revocation.Source: §C.2.4 · p. 28

C.2.5 Lifecycle Constraints Preserve Outcome Identity

  • Lifecycle-sensitive alternatives count only when they preserve session identity and the outcome contract; approval can create a new execution environment but cannot change an already-bound process.Prepared PTY shells allow job-control operations to complete in the same session, while tested password-change and group-activation continuations fail in Ask and Auto.Source: §C.2.5 · pp. 28–29

C.3 Guardian: Execution Authority under a Read-Only Profile

  • Codex Guardian’s read-only profile restricts filesystem access, not all system-state authority, including mutable shell, terminal, IPC, and existing-channel resources.Guardian is a distinct execution Principal with a read-only permission profile and no approval requirement for its independent executions.Source: §C.3 · p. 29

C.3.1 Shell, Terminal, and Existing-Channel State

The audit finds that Guardian can change state through resources beyond ordinary files, and that spawned or delegated participants can replicate authority without increasing required joint participation. OpenCode’s realized authority likewise depends on admitted routes and executor classes, not workflow labels alone.

C.4.2 Guardian Instances

  • For 27 state-changing outcomes, Guardian adds an alternative singleton to the Assistant’s singleton without increasing minimum participation.Runtime multiplicity similarly adds instance-level alternatives without requiring every available member of an authority class.Source: §C.3.1 · pp. 29–30, §C.4.2 · p. 31

C.3.1 Shell, Terminal, and Existing-Channel State

  • Guardian exercises authority over shell state, terminal settings, synchronization, IPC, and an existing database channel despite its read-only filesystem profile.The database witness changes an existing PostgreSQL transaction through a FIFO without opening a new network connection.Source: §C.3.1 · pp. 29–30, §C.3.2 · p. 30

C.3.2 Login Records and Root-Qualified Remounting

  • The audit establishes 134 independent Guardian outcomes, including login-record access and root-qualified crontab and chroot operations.The root-qualified routes rely on retained CAP_SYS_ADMIN; ordinary file-write and force-delete trials remain constrained by Guardian’s read-only mounts.Source: Table 10 · p. 30, §C.3.2 · p. 30

D OpenCode Structural Audit

  • OpenCode Build and Plan realize the same outcomes despite different native-tool permissions, and both admit shell routes that bypass external-path review.Delegated Explore and Build-preset children can also provide realization routes unavailable to the selected root.Source: D OpenCode Structural Audit · p. 31, §D.1.1 · p. 32, §D.2 · p. 33

D.1 Operating Configurations and Authority Classes

  • The OpenCode comparison fixes the unmodified presets, model and project resources, and default delegation-depth bound, while treating concrete participants as runtime-state instances.Build and Plan roots differ in available delegation classes; their child sessions receive additional restrictions.Source: §D.1 · p. 32, §D.1.1 · p. 32, §D.1.2 · p. 32

D.1.1 Authority Classes

  • OpenCode distinguishes authority classes by assigned operations, resource scope, exercise conditions, and authorization relations, not merely by workflow labels.Children retain substantial target-operation authority but lose some workflow-control operations, including further delegation at the audited depth bound.Source: §D.1.1 · p. 32, §D.1.2 · p. 32

D.2 Authorization and Execution Paths

  • OpenCode’s distinct native-read, native-edit, shell, MCP, and delegation paths mean configuration-level authority depends on the coalitions induced by all admitted routes.Plan denies ordinary native workspace edits outside exceptions while retaining ordinary shell execution.Source: §D.2 · p. 33

D.3 External-Path Review Can Be Bypassed by Equivalent Requests

Equivalent shell requests can bypass OpenCode’s external-path review, while delegated executors can reduce participation or supply routes unavailable to a root. Gemini CLI instead combines tool availability, base policy, and model review in determining which coalitions can realize outcomes.

D.3 External-Path Review Can Be Bypassed by Equivalent Requests

  • Twelve OpenCode external-operation outcomes with reviewed literal requests complete through executor singletons after equivalent shell encodings bypass the file-command lookup.The bypass preserves the program, arguments, working directory, target, and OS qualifications; the deletion comparison is summarized in Table 14.Source: §D.3 · p. 34, Table 14 · p. 34

D.4.1 Reduced Participation through Explore

  • Explore supplies a singleton read route, so the complete OpenCode configuration does not enforce the two-Principal participation required by a root-level read route.Executor–User alternatives remain in the outcome family, preserving authority information beyond the minimum participation count.Source: §D.4.1 · pp. 34–35

D.4.2 Native Editing through Delegation

  • A Build-preset child can provide a native-edit route unavailable to the Plan root, illustrating how delegation can supply an outcome realization the root lacks.Delegation leaves the selected configuration as Plan while making another configured authority class available.Source: §D.4.2 · p. 35

D.5.1 Family Summary

  • Every available OpenCode executor class independently realizes all 537 realizable Agent-599 outcomes in the family summary.Delegation changes the available Principal population without making the delegating root jointly necessary for a delegated operation.Source: §D.5 · p. 35, §D.5.1 · p. 36

E.1 Operating Configurations and Authority Classes

  • Gemini’s comparison covers interactive base modes with Model Review on or off, under a trusted-project setup without custom policies, remembered approvals, or an explicitly enabled sandbox.Headless operation is outside the eight configurations studied.Source: §E.1 · p. 36

E.2 Shell Authorization and Execution

  • Gemini shell coalitions reflect a sequence of authority-relevant checks, and tool availability precedes policy and review.The effective registry and active-tool and schema checks determine whether invocation can enter later authorization stages.Source: §E.2 · p. 37, §E.2.1 · p. 38, Table 16 · p. 38

E.2.1 Effective Entrypoint Availability

  • Plan has no effective shell entrypoint, so review cannot make a hypothetical shell route executable; native routes still realize 76 Agent-599 outcomes.Deletion remains unavailable in Plan, and Conseca cannot supply a missing executor interface.Source: §E.2.1 · p. 38

E.2.2 Base Policy and Human Participation

  • Yolo’s base policy allows ordinary shell execution and produces substantially more Assistant-only realizations before model review, unlike the ASK-based Default and Auto-edit modes.A safe-command classifier can lift ASK for eligible commands, while some commands retain ASK even when not classified as dangerous.Source: §E.2.2 · p. 38

E.3 Model Review and Required Participation

This section documents the portfolio map, including its outcome categories and counts, and specifies the scope and completion rules for the 599-outcome catalogue.

E.3 Model Review and Required Participation

  • Eleven validation-output outcomes retain single-Principal minima, while reviewed execution requires Conseca as an additional jointly necessary authority holder.Conseca may return ASK and add User participation, but the admitted approving branch shows the structural effect of review most directly.Source: Table 17 · p. 39, §E.3 · p. 39
  • Model Review leaves every mode’s realizable outcome set unchanged, and Plan gains no shell deletion route.Review is reached only along an admitted interface; the reviewed execution route cannot complete without the reviewer contribution.Source: §E.3 · p. 39

E.4.1 Generalist

  • Assistant and Generalist remain different authority classes but occupy corresponding executor positions and have the same Principal Authority over the measured shell portfolio.Their coalitions represent alternative holders of the same measured shell authority, not additional jointly required executors.Source: §E.4.1 · pp. 39–40

E.4.2 Codebase Investigator and CLI Help

  • Investigator has Principal Authority of 69/599 ≈0.115 without review and 40/599 ≈0.067 with review, while CLI Help’s score is zero.Investigator supplies singleton alternatives for 69 native reading outcomes without review; CLI Help’s documentation interface realizes none of the portfolio outcomes.Source: §E.4.2 · p. 40

E.4.3 Local-Agent Instances

  • Creating or terminating local-agent instances changes Pq without changing the operating configuration.Creating a Generalist does not by itself make the Assistant part of the Generalist’s later target-operation coalition; parent participation counts only when the measured outcome requires it.Source: §E.4.3 · p. 40

F Complete Outcome Catalogue

  • The catalogue specifies 599 outcomes across seven themes and 46 categories, with target operations, required results, and shared completion rules.Existing grants and prepared components are fixed conditions, while fresh authorization counts as participation; request acceptance or successful exit alone does not establish completion.Source: F Complete Outcome Catalogue · pp. 40–41

F.1 A. Files and content; F.2 B. Execution environments

F.2 B. Execution environments

  • The supplied execution-environment tables cover local IPC and synchronization (6 outcomes) and containers and execution isolation (5 outcomes).The passages do not provide a total for this theme.Source: Table 32 · pp. 54–55, Table 33 · p. 55

F.3 C. Host, network and service operations

  • Host, network, and service operations contains 83 outcomes across 6 categories.Source: §F.3 · p. 55

F.4 D. Identity and access

  • Identity and access contains 57 outcomes across 4 categories.Source: §F.4 · p. 60

F.5 E. Software development and delivery

  • Software development and delivery contains 99 outcomes across 8 categories.Source: §F.5 · p. 64

F.6 F. Data systems and integrations

The section inventories data-system integrations and applications/business-record operations by outcome category. Together, the themes cover 107 outcomes across 12 categories.

F.6 F. Data systems and integrations

  • Theme F contains 45 outcomes in four categories; cited categories are F1 databases and transactions (26 outcomes), F2 plugins, MCP and tool composition (4), and F3 knowledge indexes and retrieval access (8).Source: §F.6 · p. 69, Table 52 · p. 69, Table 53 · p. 71

F.7 G. Applications and business records

  • Theme G covers 62 outcomes across eight categories, including browser state and interaction (13), issues and code-review records (5), business commitments and reversals (2), and mailboxes and mail delivery (7).These categories are labeled G1 through G4.Source: §F.7 · p. 72, Table 56 · pp. 72–73, Table 57 · p. 73
  • The remaining Theme G categories are channel messages and membership (8), documents and collaboration (14), spreadsheets and calculations (6), and calendars and invitations (7).These categories are labeled G5 through G8.Source: Table 60 · p. 74, Table 61 · p. 75, Table 62 · pp. 75–76
Loading 2609.32378v1…