Permissions Are Not Technical Configurations, But Falsifiable Governance Contracts

The minimal semantic unit of permission is not 'person' or 'role', but the ternary structure 'subject–action–object', which is indispensable—if omitted, permission loses both auditability and configurability. In a DAO, declaring only 'Address A has governance rights' without specifying the proposal type, timing, or action (vote/queue/execute) renders it impossible to construct a verifiable on-chain transaction or generate an Etherscan-auditable log; in an enterprise HR system, labeling only 'Employee C has salary permissions' without clarifying whether the permitted actions are read, update, or delete—and without restricting the object to 'their own salary record' versus 'the department-wide salary summary'—makes RBAC policy deployment infeasible and prevents forensic tracing of specific overreach during audits; a one-person company may seem exceptional—the founder serves simultaneously as shareholder and operator—but legal and financial practice mandates identity separation: signing contracts as the 'legal representative', where the action is 'signing' and the object is 'amendments to the company's articles of incorporation'; operating online banking as the 'account holder', where the action is 'transfer' and the object is 'funds in the company's basic account'. Omitting any element—for instance, stating merely 'Alice has authority'—renders the claim untestable (no definable inputs or outputs), unauditable (no log fields to map), and non-compliant (ISO 27001 A.9.2.3 requires permissions to be bound to specific information assets). Although ISO/NIST standards do not explicitly define this ternary structure as the 'minimal unit', all mainstream models (ACL/RBAC/ABAC/ReBAC) implicitly adopt it as their formal foundation; even XACML, with its finer-grained Attribute-Based modeling, still requires explicit declaration of Subject, Resource, and Action attribute sets within its PolicySet—otherwise, policy evaluation fails. Thus, this structure is not a theoretical preference, but an operational necessity for verifiability: without it, permission cannot transition from a normative statement ('ought-to-be') to an empirical constraint ('is').

Critics argue that no genuine permission boundaries exist internally within a one-person company, since ownership and management rights are absolutely unified, and the founder could theoretically bypass all self-imposed constraints. This critique strikes a vital point—yet precisely confirms the irreplaceability of the ternary structure: precisely because no natural internal separation exists, external anchors must be deliberately introduced to construct subject–action–object relationships. Business registration confers the statutory identity of 'legal representative'; bank U-keys bind the operational identity of 'account holder'; tax CA certificates authenticate the accountable identity of 'tax filer'. These are not technical redundancies, but institutional mechanisms that 'split' a single natural person into multiple distinguishable subject identities—enabling independent verification across distinct action–object combinations. Abandoning the ternary structure would push the one-person company entirely into 'permissionless governance': all operations become unauditible black-box behaviors—neither provable to regulators (e.g., demonstrating that a dividend resolution was approved by the shareholders' meeting rather than by individual will) nor verifiable to banks (e.g., proving large transfers require dual signatures rather than unilateral instructions). Therefore, the ternary structure is not simplification of complexity, but reinforcement against governance fragility: it transforms the vague 'What can I do?' into the precise 'Under identity X, I execute action Z upon object Y'—making deviations locatable, feedback loops actionable, and calibration evidence-based.

A transferable insight is: any permission design attempting to bypass the ternary structure inevitably incurs governance costs. For example, certain low-code platforms allow administrators to describe permissions in natural language (e.g., 'Sales team can view customer data'), appearing convenient but embedding latent risk—when a data breach occurs, it becomes impossible to determine whether the violation was 'sales director viewing competitor customers' (overreach) or 'sales representative exporting full customer list' (policy breach), because neither the action (view/export) nor the object (industry-specific customers / all customers) is explicitly modeled. Real efficiency does not come from omitting elements, but from automating the generation and verification of ternary tuples: DAO tools like Tally automatically package proposal ID, voting action, and block height into verifiable events; enterprise IAM systems like Okta enforce association of 'accessible applications' (objects) and 'permitted operations' (actions) when creating roles; e-signature platforms used by one-person companies (e.g., eSignBao) automatically record 'signer identity' (subject), 'signing action' (subject–action), and 'signed document hash' (object) for every signature. This reveals a universal principle: the maturity of a permission system is not determined by how many advanced policies it supports, but by whether each affirmative answer ('yes') inherently carries a reproducible counterexample ('no').

The validity of a permission decision does not depend on how rigorous the rule itself is, but on whether it is anchored to a context anchor that can be independently verified; permission lacking such an anchor is equivalent to unconditional authorization. The one-person company most starkly exposes this principle: when the same natural person operates under different identities, permission switching is not a psychological act—it must rely on external trusted credentials. The business registration system’s registered ID number anchors the 'legal representative' identity; the bank’s pre-registered U-key certificate anchors the 'account holder' identity; the tax authority’s issued digital certificate anchors the 'tax filer' identity. These anchors are effective precisely because they are issued by third-party authoritative institutions, cross-system cross-validated (e.g., banks can query the national government service platform to verify legal representative status), and automatically trigger permission downgrade upon failure (e.g., expired ID, revoked U-key). If identity switching relies solely on internal memory or verbal agreement, permission devolves into an unverifiable subjective assertion—incapable of supporting legal enforceability or audit requirements.

The enterprise scenario elevates anchor complexity one level further: instead of relying on a single external credential, it constructs a multidimensional, dynamic anchor network. A typical example is the OA approval workflow, where the permission 'Finance Director may approve expense reports exceeding RMB 50,000' is actually locked by three co-dependent anchors—'department' (Finance Department), 'job level' (Director), and 'process stage' (status = pending review). Any anchor change (e.g., the director’s transfer to Marketing Department, or the expense report’s status changing to 'archived') instantly invalidates the permission. Systems like SAP SuccessFactors and DingTalk Approval mandate modeling such anchors precisely because they constitute traceable, auditable, and automatable governance infrastructure. If an enterprise defines only 'Directors have approval authority' while ignoring the process-stage anchor, the system cannot distinguish between 'expense reports currently under approval' and 'archived historical documents', leading to either permission abuse or erroneous rejection. The crux here is not technical feasibility, but precision of governance logic expression: richer anchors yield finer-grained permissions; more verifiable anchors yield more trustworthy decisions. When the triple anchor 'department–job level–process stage' is codified into policy, it ceases to be a manager’s ad hoc discretion and becomes part of the organization’s world model—available for new employees to learn, auditors to inspect, and automation tools to reason over.

DAOs push anchors to the extreme—fully decentralized, natively on-chain, and requiring no trust in third parties. Their permission anchors derive directly from consensus-layer state: e.g., 'a proposal passes only if quorum is met and block.height > deadline', where quorum is the real-time on-chain tally of voting weight, and deadline is the immutable block-height timestamp. Nodes need trust no one—they simply synchronize the blockchain to independently verify whether the anchor condition holds. This design eliminates single-point-of-failure risks inherent in centralized anchors (e.g., compromised CA institutions, crashed business registration systems), yet introduces new challenges: excessive anchor rigidity. For instance, if the on-chain time anchor ignores network latency, a legitimate proposal might be rejected due to a minuscule timing discrepancy—causing deviation between the expected outcome and the actual outcome, necessitating off-chain coordination to activate a feedback loop for calibration. A transferable insight is: anchor selection is fundamentally a choice of governance trust model. One-person companies anchor in nationally backed credentials; enterprises anchor in internal procedural authority; DAOs anchor in cryptographic consensus. There is no hierarchy of superiority—only contextual fitness. The critical requirement is that anchors satisfy the hard constraint of 'verifiability': they cannot be vague 'leadership approval', nor easily tampered-with 'local configuration files', but must be objective facts whose conclusion can be reproduced by at least one independent observer. When anchors are verifiable, permission truly evolves from 'I believe it is permissible' to 'anyone can confirm it is permissible'.

Permission changes are never the result of technical operations, but the product of a governance event—the redefinition of rights and responsibilities; this event must be non-atomic, leave traces, and be fully traceable—otherwise, the permission system forfeits its governance foundation. DAOs provide the most transparent exemplar: modifying a Timelock administrator address is never a one-line code update, but a multi-stage on-chain process spanning proposal, voting, and execution. Each stage generates an immutable log—proposal transaction hash, voting block, execution transaction—whose chronological sequence forms a complete causal chain. This design is not inefficient, but intentional: it ensures permission changes are not silent privilege escalations via developer backdoors, but concrete manifestations of community consensus. Skipping voting to execute directly—even if technically feasible (e.g., a single transaction calling grantRole)—means the collapse of the governance contract, eroding user trust in the protocol. Thus, non-atomicity is not a flaw, but a fuse for governance resilience.

In enterprise scenarios, the governance nature of permission changes manifests as strict coupling between HR processes and IT systems. When an employee transfers roles, the HR system generates a transfer order (specifying new department, new job level, effective date); this document acts as a governance event triggering synchronized updates to AD group policies, ERP permissions, and email access controls in the IT system. If an IT administrator bypasses the HR order to arbitrarily expand permissions—though technically possible—it constitutes serious compliance violation: both ISO 27001 and GB/T 22080 mandate that permission changes must be based on formal personnel change documentation. Here, 'non-atomicity' appears in the temporal dimension: the HR document precedes the system update, and their timestamps must logically align (e.g., document effective date ≤ system update date), forming a cross-system traceable closed loop. This design prevents 'ghost permissions': inactive accounts of departed employees remaining enabled, or transferred employees retaining sensitive permissions from their former departments. Verifiable traceability ensures every permission adjustment answers the question 'Who changed what, when, based on what, and why?'—a prerequisite for identifying deviation sources and initiating feedback loops.

One-person companies are often mistakenly assumed to require no governance traceability—yet the opposite is true: their legal risk is higher, and traceability requirements stricter. Legal representative changes demand not only filing with market regulation authorities (generating a registration amendment notice), but also synchronously updating bank reserved seals (generating a new seal card), tax CA certificates (generating a new key pair), and social security/housing fund accounts (generating amendment receipts). These cross-system credentials collectively form a complete governance evidence chain. Updating only the business license while neglecting bank seal renewal will cause subsequent large transfers to be rejected; failing to renew the CA certificate will prevent electronic invoice issuance. This mandatory multi-point traceability essentially uses external institutions to impose governance rigidity on the one-person company: it forces the founder to acknowledge that permissions are not innate rights, but contractual privileges granted and continuously verified by law. A transferable insight is: the 'non-atomicity' of permission changes is not a technical limitation, but a governance necessity. It transforms permission from 'one-time configuration' into 'ongoing negotiation', enabling organizations to identify intent drift (e.g., DAO proposals diverging from original mission) via feedback loops, calibrate coordination entropy (e.g., enterprise approval workflows lengthening due to departmental silos), and repair world model deviations (e.g., a one-person company discovering old seals are still being misused). When the change process is traceable, permission truly becomes part of the organization’s memory—not a transient state easily overwritten.

The permission matrix is never a runtime decision engine across any scenario—it is a static contractual snapshot at the governance layer; real-time authorization must occur through an abstraction layer, otherwise permissions lose hot-updatability, audit credibility, and compliance effectiveness. In DAOs, the Governor contract’s roles mapping merely declares 'which addresses hold which roles'—a static snapshot stored on-chain; actual decisions happen during `onlyRole()` modifier execution, which dynamically reads the current mapping state and combines it with runtime variables like msg.sender and block.timestamp. Hard-coding permission logic into business functions (e.g., writing `if (msg.sender == admin)` directly inside mint()) would require redeploying the contract for every permission adjustment—violating governance agility principles—and prevent standardized access control logging.

Enterprise permission matrices (e.g., Oracle EBS’s Responsibility-Function matrix) operate similarly. They do not participate directly in runtime decisions, but serve as the policy source output by the Policy Administration Point (PAP), loaded and parsed by the Policy Decision Point (PDP) for each request, then combined with the user’s real-time attributes (e.g., current department, job level, active project) to compute the final decision. This separation ensures centralized policy management and dynamic enforcement: after HR adjusts an employee’s job level, their permissions auto-update without restarting application servers. If the permission matrix were queried directly (e.g., hardcoding `WHERE role = 'FINANCE_DIRECTOR'` in SQL), policy changes would require synchronizing modifications across all business code—risking omissions that lead to privilege escalation vulnerabilities, and preventing auditors from distinguishing 'policy definition' from 'policy enforcement', violating NIST SP 800-53 AC-6 (Policy Change Control).

Local permission tools for one-person companies (e.g., macOS Parental Controls) follow the same paradigm: GUI configuration generates a .plist policy file—the serialized expression of governance consensus; at runtime, a systemd daemon (e.g., com.apple.parentalcontrols.check) loads and parses it, dynamically enforcing rules based on current user login sessions and application launch events. Hard-coding permission logic into application layers (e.g., an educational app independently judging screen time) would prevent parents from unified system-level control and eliminate arbitration mechanisms when conflicting app policies arise. A transferable insight is: abstraction-layer transformation is the lifeline preserving 'governance–execution' decoupling in permission systems. It elevates permission from 'part of the code' to 'the organization’s constitution'—a constitution amendable (via permission matrix updates), but whose amendment process follows defined procedures (governance workflows); executors (PDPs, contract modifiers, daemons) faithfully interpret the constitution without legislating. This separation grants organizations critical capabilities: when world model deviations occur (e.g., new business lines requiring new permissions), rapid response is possible via updating the contractual snapshot; when judgment is insufficient (e.g., AI assistants misjudging operational risk), calibration becomes feasible using standardized input/output interfaces provided by the abstraction layer; when multi-agent collaboration occurs, agents need only understand the unified contract—not coordinate underlying execution logic.

The ultimate convergence point of permission mechanisms across all three organizational types is not functional completeness, but the 'falsifiability of minimal necessary permissions'—any permission statement must be falsifiable through construction of an explicit rejection case; otherwise, logically, that permission equals unrestricted access. DAOs provide the strictest empirical arena for this: claiming 'Address X has mint() permission' necessitates existence of a call reverting due to `!hasRole(MINTER_ROLE, msg.sender)`, with the failed transaction hash publicly verifiable on Etherscan. This rejection instance is not an anomaly—it is the necessary evidence of permission’s existence, demarcating a clear boundary proving the system actively enforces constraints. If all mint() calls succeed regardless of address, then 'mint permission' is merely hollow rhetoric—actual behavior is open minting.

In enterprise scenarios, falsifiability manifests as controlled rejection experiments. Constructing a log showing 'Sales Director access to competitor customer data blocked' in a test environment is not just technical validation—it fulfills a governance commitment: proving permission policies are not paper exercises, but functioning guardrails. ISO 27001 mandates 'regular review' of permissions, whose core is verifying falsifiability—if no rejection instances surface during review, permissions are overly permissive and require calibration; if rejection instances occur frequently without valid business justification, permissions are overly restrictive and demand world model optimization. The one-person company applies equally: the statement 'Legal Representative may sign electronic contracts' must accompany the explicit error code `ERR_CERT_DATE_INVALID` when the CA certificate expires. This error is not a system defect—it is an active declaration of the permission boundary, informing users: signing authority depends on certificate validity, and terminates immediately upon expiration. If the system silently accepts expired certificates, 'signing authority' effectively degrades into 'unconditional signing authority'.

Critics object: 'User read access to their own data is never denied by the system—does this mean such permission is unfalsifiable?' This objection conflates 'permission' with 'capability'. Operating systems grant users read access to their home directory as a default capability rooted in ownership models—not a permission actively conferred; true permission governance targets high-risk access behaviors potentially subject to abuse: DAO minting rights, enterprise salary data access, one-person company bank large-transfer authority. These permissions must be deniable—otherwise, they lose their meaning as governance instruments. A transferable insight is: falsifiability is the 'immune detection mechanism' of permission systems. It enables organizations to proactively expose weaknesses—through red-team/blue-team exercises, penetration testing, sandbox drills—deliberately generating rejection instances to uncover world model deviations (e.g., unforeseen attack surfaces), calibrate judgment (e.g., AI fraud-detection models misclassifying legitimate transactions), and strengthen feedback loops (e.g., automatically triggering permission review tickets from rejection logs). When an organization can openly demonstrate 'how we reject', it gains the confidence to assert 'why we allow'.