Permission Mapping

Overview

PCP’s permission model maps every action to a confirmation requirement based on two dimensions: the action’s side effect severity and the privilege domain it operates in. The mapping is deterministic. Given an action class and a domain, the permission engine returns exactly one decision: allow, require confirmation, or deny.

This page covers the complete mapping, the three trust levels, the confirmation modalities, and the escalation rules that govern cross-domain actions.

The Three-Domain Privilege Model

PCP divides the system into three privilege domains, separated by hard boundaries:

graph TD
    subgraph System Domain
        direction LR
        S["HIGH PRIVILEGE<br/>TL3 + explicit auth"]
    end
    subgraph Compositor Domain
        direction LR
        C["MID PRIVILEGE<br/>TL2 confirm"]
    end
    subgraph App Domain
        direction LR
        A["LOW PRIVILEGE<br/>TL1 auto / TL2 confirm"]
    end
    A ---|Hard Wall| C
    C ---|Hard Wall| S

App domain. Covers actions within a single application: reading content, navigating, clicking buttons, typing text. Most user-facing actions live here. Auto-approved for trust level 1 actions; confirmation required for trust level 2.

Compositor domain. Covers actions that affect window management, workspaces, and display configuration. These are riskier because they alter the user’s spatial environment. Confirmation required by default.

System domain. Covers actions that touch hardware, system services, or credentials. These are the highest-risk actions and always require explicit authentication in addition to confirmation.

Cross-domain escalation is blocked at the permission-check layer. An intent classified in the app domain cannot execute against a system-domain target without an explicit escalation step. The pipeline enforces this through a domain boundary check before action resolution.

Trust Levels

PCP defines four authentication levels that determine how much access an action request carries:

Level	Name	Description
0	Public	Unauthenticated. Read-only access to non-sensitive desktop state.
1	User	Authenticated as the desktop user. Standard operational level.
2	Privileged	Elevated access granted through explicit user action (password, biometric, hardware key).
3	System	Compositor-internal. Reserved for the supervisor and recovery mechanisms.

SI operates at trust level 1 by default. It does not have blanket system access. When an action requires trust level 2, SI must prompt the user for elevated authentication before proceeding.

Action Classes

PCP classifies actions into six severity categories. The classification determines the default confirmation requirement:

Action Class	Side Effects	Default Policy	Undo Window
Read / Navigate / Activate	None	Allow	None
Input Text	Low (user can observe and undo)	Allow	5 seconds
Delete	High (irreversible data loss)	Confirm	5 seconds
Send	High (irreversible external action)	Confirm	15 seconds
Close App	Medium (loss of unsaved state)	Confirm	3 seconds
System Settings	High (affects system behavior)	Confirm	None
Hardware Control	High (affects physical devices)	Confirm	None

The undo window defines how long after execution the user has to reverse the action. Read and navigate actions have no undo window because they produce no side effects. Send actions have a 15-second undo window because the external delivery may not be instantaneous. System settings and hardware control have no undo window because the action’s effects propagate outside the compositor’s control.

Full Permission Matrix

The complete mapping crosses action class with authentication level to produce a confirmation modality:

Action Class	TL0 (Public)	TL1 (User)	TL2 (Privileged)	TL3 (System)
Read / Navigate / Activate	Allow	Allow	Allow	Allow
Input Text	Deny	Allow	Allow	Allow
Delete	Deny	Confirm	Allow	Allow
Send	Deny	Confirm	Allow	Allow
Close App	Deny	Confirm	Allow	Allow
System Settings	Deny	Confirm	Confirm	Allow
Hardware Control	Deny	Deny	Confirm	Allow

Reading the table: a TL1 (user) delete action requires confirmation. A TL2 (privileged) delete action is allowed without confirmation. A TL0 (public) delete action is denied outright.

Confirmation Modalities

When an action requires confirmation, the system presents it through multiple channels simultaneously:

Voice. SI describes the action using a warmer, slightly slower tone with upward inflection (a question cadence). The user can respond by voice.

Visual. A compositor overlay appears near the focused surface with the action summary, accept and reject buttons, and a countdown timer. The overlay does not block the entire screen. Keyboard shortcuts: Enter to confirm, Escape to cancel.

Haptic. When the Spaceboard is connected, a distinct double-pulse pattern signals a pending confirmation. The user taps to accept or double-taps to dismiss.

The confirmation flow follows four steps: describe the action, wait for a response, execute or cancel, and provide feedback. If the timer expires without a response, the action is cancelled and SI informs the user.

Confirmation timeouts vary by action class. Destructive actions (delete, send) get longer windows because the stakes are higher and the user may need a moment to evaluate. Navigation and read actions that happen to require confirmation (unusual contexts) get shorter windows.

Rate Limiting and Anomaly Detection

The permission engine monitors action patterns for abuse. Three conditions trigger throttling or additional confirmation requirements:

• Action loops. More than 10 identical actions within 5 seconds. This catches runaway automation or a stuck intent.
• Destructive bursts. More than 3 destructive actions within 10 seconds. This catches accidental mass deletion.
• Unusual patterns. Actions outside the user’s normal behavior profile, or actions at unusual times. This is a softer signal that raises the confirmation requirement without blocking.

Audit Trail

Every permission decision is recorded in the audit log, including the action, the target, the trust level, the decision (allow, confirm, deny), and whether the user confirmed or denied. Audit files are append-only, tamper-evident (HMAC chain), and retained for 90 days. Separate audit files exist for each privilege domain: audit-app.jsonl, audit-compositor.jsonl, and audit-system.jsonl.

The audit trail is the single source of truth for what happened on the system. It is not optional, not bypassable, and not deletable by SI or any user-space process.