Privilege Domains

Overview

PCP partitions every capability into one of three privilege domains. The boundaries between these domains are enforced by the execution pipeline itself, not by application-level checks or runtime policy files. An adapter operating in the app domain cannot emit an intent that targets compositor or system capabilities. A compositor-domain adapter cannot reach system-domain operations. The isolation is structural.

This design serves a specific containment goal. If an application is compromised, the attacker gains control over that application’s declared capabilities and nothing else. The compromised adapter cannot escalate to window management, workspace switching, hardware control, or any capability outside its assigned domain. The pipeline rejects the intent at the permission-check step before it reaches execution.

Each domain maintains its own audit trail. App-domain actions log to the application audit trail. Compositor-domain actions log to the compositor trail. System-domain actions log to the system trail. A security review of application-level activity never requires parsing system-level entries, and vice versa.

Domain Hierarchy

The three domains form a strict hierarchy. Privilege increases from app to compositor to system. Communication flows downward through the pipeline, never upward across domain boundaries.

graph TD
    subgraph SD["System Domain — High Privilege"]
        SC["audio.volume, network.wifi.toggle,\npower.shutdown, packages.install,\nstorage.info, notifications.send"]
    end

    subgraph CD["Compositor Domain — Mid Privilege"]
        CC["surface.move, surface.resize,\nworkspace.switch, clipboard.read,\nclipboard.write, screenshot.capture,\nlayout.focus_mode, layout.split_view"]
    end

    subgraph AD["App Domain — Low Privilege"]
        AC["browser.navigate, mail.compose,\neditor.edit, text.set,\nelement.activate"]
    end

    AD -->|"HARD WALL"| CD
    CD -->|"HARD WALL"| SD

    AC -.->|"Scope: individual app windows and elements"| AD
    CC -.->|"Scope: windows, workspaces, displays, clipboard"| CD
    SC -.->|"Scope: system-wide hardware and services"| SD

The hard walls are not configurable. There is no override, no escape hatch, no administrator flag that grants an app-domain adapter access to compositor capabilities. The pipeline architecture makes cross-domain escalation structurally impossible. An intent that declares a compositor capability from an app-domain adapter fails at the permission-check step and is logged as a denial.

App Domain

The app domain is the lowest privilege layer. Capabilities in this domain are scoped to individual application windows and the elements within them. An app-domain adapter can navigate a browser, compose an email, edit a document, set text in a field, or activate a UI element. It cannot move, resize, or close the window itself. It cannot switch workspaces, read the clipboard, or interact with hardware.

Typical app-domain capabilities include browser.navigate, mail.compose, editor.edit, text.set, and element.activate. These capabilities map directly to the operations an application exposes through its capability manifest (Tier 1) or its accessibility tree (Tier 2). The scope is deliberately narrow: each capability acts on a specific application’s data, not on the desktop environment that contains it.

Enforcement is straightforward. When the pipeline resolves an intent to an app-domain capability, it checks the requesting adapter’s domain registration. If the adapter is registered in the app domain, the intent proceeds to action resolution and execution. If the adapter attempts to invoke a compositor or system capability, the permission check rejects it immediately.

Compositor Domain

The compositor domain covers spatial operations: window management, workspace switching, clipboard access, screen capture, and layout presets. This is the layer that makes a spatial operating system distinct from a traditional desktop. Capabilities like surface.move, surface.resize, surface.minimize, workspace.switch, clipboard.read, clipboard.write, screenshot.capture, layout.focus_mode, and layout.split_view all live here.

The compositor domain’s scope extends to windows, workspaces, display surfaces, and the clipboard. An adapter in this domain can arrange the user’s spatial environment, switch between workspaces, copy and paste across applications, and capture the contents of a surface. These operations affect how applications are presented and arranged, not what those applications do internally.

The compositor domain cannot reach system-domain capabilities. An adapter that manages windows cannot toggle Wi-Fi, adjust volume, install packages, or shut down the system. The hard wall between compositor and system domains prevents exactly this kind of escalation.

The compositor domain is where most user-facing spatial operations live. Voice commands like “move this window to the left,” “switch to workspace two,” or “split this view” resolve to compositor-domain capabilities. The System Intelligence layer issues intents in this domain frequently, which is why the default timeout for compositor operations is longer than for app-domain operations.

System Domain

The system domain is the highest privilege layer. Capabilities here control hardware, network state, power management, package installation, storage access, and system-wide notification delivery. Typical capabilities include audio.volume, audio.mute, network.wifi.toggle, power.shutdown, power.suspend, packages.install, storage.info, and notifications.send.

System-domain operations are inherently dangerous. Shutting down the system, installing packages, or modifying network configuration can affect every application and every user session. PCP treats all system-domain actions as high-severity by default. Every system-domain intent passes through multi-modal confirmation gates before execution, regardless of the user’s current trust level.

The system domain has no upward boundary because it is already at the top. System-domain adapters are the highest privilege entities in the PCP model. This is why system-domain adapter registration is restricted: only signed, verified adapters can operate in this domain, and their capability sets are audited more aggressively than those in lower domains.

Enforcement Model

Domain boundaries are enforced at the pipeline level, not at the application level. The execution pipeline’s permission-check step inspects every intent’s capability identifier against the requesting adapter’s registered domain. If the capability belongs to a different domain, the intent is rejected and the denial is logged. The rejection happens before action resolution, before execution, before any external code runs.

This approach means domain isolation does not depend on applications behaving correctly. A compromised app-domain adapter that attempts to forge a compositor-domain intent fails at the same permission check. The pipeline does not care about the intent’s source or the adapter’s internal state. It checks the domain mapping and rejects the mismatch.

Runtime revocation adds a second enforcement layer. Administrators can dynamically revoke an application’s capabilities through the revoke.app intent. Revocation removes all capabilities registered by the target application from the capability registry, terminates active adapter sessions, and logs the revocation event. The application remains running but loses all PCP integration until the revocation is lifted or the application restarts and re-registers.

Audit trail separation supports post-incident analysis. Because each domain logs to its own trail, investigators can review app-domain activity without filtering out system-domain noise. If an application is suspected of malicious behavior, its audit trail provides a complete record of every capability it attempted to invoke, including denied cross-domain attempts. The separate trails also support domain-specific retention policies: app-domain logs might rotate daily, while system-domain logs might be retained for months.

The net effect is a privilege model where compromise is contained by architecture, not by policy. No runtime check, no configuration file, and no administrator decision can open a cross-domain escalation path. The pipeline structure makes it impossible.