Pairing as permission

@@ -7,10 +7,10 @@ type: topic
content_type: topic
quality: complete
index_group: sovereignty-and-infrastructure-patterns
short_description: "PairingAsPermission is the Object Capability access-control model in Totebox Orchestration: a cryptographic pairing is the permission; its absence means no pathway."
short_description: "The Object Capability access-control principle — a cryptographic pairing is the permission, and its absence means no pathway exists to ask for one — as embodied in the platform's machine-based node admission."
status: active
bcsc_class: no-disclosure-implication
last_edited: 2026-05-25
last_edited: 2026-08-22
editor: pointsav-engineering
cites: []
references:
@@ -26,91 +26,42 @@ references:
paired_with: pairing-as-permission.es.md
---

PairingAsPermission is the access-control model used in [[totebox-orchestration|Totebox Orchestration]]: a cryptographic pairing between two nodes is the permission, and the absence of a pairing makes the connection structurally impossible — not access-denied, but no pathway. There is no central access-control list, no permission lookup at request time, and no role table. The model is the formally proven Object Capability pattern, deployed in production at Fuchsia OS, seL4, and WireGuard. PairingAsPermission is canonical in the workspace; synonyms RBAC, ACL, and PermissionSystem are explicitly rejected.

This article describes the principle, the topology in Totebox Orchestration, the engineering risks, and the production reference implementations.

**Correction (2026-08-02, updated 2026-08-06):** `pairings.yaml` is real, but it's `/srv/foundry/pairings.yaml`, the Foundry *workspace's own* cluster-manifest index maintained by the Command Session — not a PointSav customer-deployment mechanism. `app-orchestration-command` is real and substantial on canonical (invite/pairing, fleet visibility, personnel/permission tiers, GPU brokering — see [[personnel-permissions]]), but does not implement the specific "Command"/"os-orchestration hub" topology described throughout this article, including the `SYS-CONTRACTS-01` claim further down. The general Object Capability / cryptographic-pairing principle this article argues for is a real, legitimate design pattern (well-cited, accurately describing Fuchsia/seL4/WireGuard precedent), but its "production reference implementation" claims for PointSav's own topology describe tooling that doesn't exist yet. **Flagged, not resolved.**
Pairing as permission is the access-control principle behind the platform's [[machine-based-auth|machine-based node admission]]: a cryptographic pairing between two nodes is the permission, and the absence of a pairing makes the connection structurally impossible — not access-denied, but no pathway to even ask. There is no central access-control list checked at request time, and no role lookup on the connection path. **A node that has never completed a pairing ceremony cannot be instructed by anything, because nothing has a way to reach it.** That safety property holds even if every other layer of the system has a bug. The model is the formally proven Object Capability pattern, deployed in production at Fuchsia OS, seL4, and WireGuard.

## The core principle

In most access-control systems, a request arrives, the system looks up whether the requester has permission, and either allows or rejects the request. The lookup requires a central authority: a database, a role-policy store, a permission table.

PairingAsPermission eliminates the lookup. Two nodes communicate only if a cryptographic pairing has been established between them. If no pairing exists, no connection exists and no request is made. The question "does this node have permission to reach that node?" has a structural answer: check whether a pairing exists. If not, no pathway exists to ask in the first place.

This is the Object Capability Model — a formally proven security pattern first described by Mark S. Miller in *Capability Myths Demolished* (2003). [^1] The central axiom: **connectivity begets connectivity.** Object A can send a message to B only if A holds a reference to B. The reference is the capability. Without the reference, the connection is structurally impossible — not access-denied, but no pathway.

## The topology in Totebox Orchestration

The Totebox Orchestration topology is:
In most access-control systems, a request arrives, the system looks up whether the requester has permission, and either allows or rejects it. The lookup requires a central authority — a database, a role-policy store, a permission table.

- **Command** (the os-orchestration hub) is paired to: every Totebox Archive, both os-mediakit nodes, and both os-privategit nodes. The Command's pairing list is the de-facto topology map.
- **Per-project os-orchestration** instances are paired to: their own Totebox Archives only. One project-scoped orchestration cannot reach a different project's orchestration — no pairing exists.
- **Cross-project coordination** flows through the Command: a project-scoped orchestration sends a message to the Command; the Command, paired to both, fetches data or routes the request. No direct lateral connection is created between per-project orchestrations.
Pairing as permission eliminates the lookup. Two nodes communicate only if a cryptographic pairing has already been established between them. If no pairing exists, no connection exists and no request is made. The question "does this node have permission to reach that node?" has a structural answer: check whether a pairing exists. If not, no pathway exists to ask in the first place.

The permission map is the architecture diagram. There is no separate access-control document — the live pairing topology is the authoritative record.
This is the Object Capability Model — a formally proven security pattern first described by Mark S. Miller in *Capability Myths Demolished* (2003).[^1] The central axiom: **connectivity begets connectivity.** Object A can send a message to B only if A holds a reference to B. The reference is the capability. Without the reference, the connection is structurally impossible.

## No central registry
## Node admission by pairing ceremony

There is no central registry recording who is paired to whom. This is deliberate.
The platform's real embodiment of this principle is machine-based node admission: a new node completes a pairing ceremony against an approval service before it can join the network at all, rather than joining first and being granted or denied specific permissions afterward. Until that ceremony completes and is approved, the node has no pathway into the network to request anything — there is nothing to deny, because there is no connection to deny it on.

The pairing state is distributed: it exists between the nodes themselves. Each node holds the public keys of its paired peers. The Command maintains `pairings.yaml` — a record of its active connections (endpoint, public key, module identifier, pairing date) — but this is the Command's operational record, not a central authority. If the Command loses its pairing list, the pairings can be re-established because each peer still holds the Command's public key and the Command still holds each peer's public key. The truth is distributed.

This mirrors Bitcoin's ownership model: there is no central bank recording who owns which coins. The ownership state is the blockchain — distributed, verifiable, requiring no authority. In PairingAsPermission, the pairing state is the topology. A new Totebox Archive declares itself via its `MANIFEST.md` (instance identity plus public key); the Command adds it to its active connections. The connection is the authorisation. No external authority approves or records it.

The design enables true distributed deployment: a Totebox Archive can reside on any cloud provider, any data centre, or a minimal compute node. The Command needs only the archive's endpoint and public key to establish a pairing.
This is a narrower, concrete instance of the general principle above, not the whole of it — the platform does not yet implement capability-based access control at every layer described by the formal Object Capability literature. What exists today is pairing-gated network admission at the node level; broader per-resource capability delegation, of the kind Fuchsia or seL4 implement throughout their respective systems, is a design direction this principle points toward, not a claim about what is built everywhere already.

## Why this is stronger than role tables

Role-based and access-list systems share a structural vulnerability: the **confused deputy problem**. A trusted intermediary — a process holding elevated permissions — can be tricked into performing an action on behalf of a less-trusted caller. The intermediary uses its own permissions to do something the caller could not do directly. The vulnerability is structural; it is present in any system where authority is looked up from a table at request time.
Role-based and access-list systems share a structural vulnerability: the **confused deputy problem**. A trusted intermediary — a process holding elevated permissions — can be tricked into performing an action on behalf of a less-trusted caller, using its own permissions to do something the caller could not do directly. The vulnerability is structural: it is present in any system where authority is looked up from a table at request time, regardless of how carefully that table is maintained.

In the Object Capability Model, this vulnerability is an architectural invariant. A holder cannot use what it was never given a reference to. A per-project orchestration cannot instruct the Command to act on its behalf for a cross-project operation unless the per-project orchestration already holds the cross-project capability — which it does not. The Command validates per-caller scope on every request before acting. The validation is not an optional security layer; it is the definition of what the Command does.
In the Object Capability Model, this vulnerability is an architectural invariant rather than a bug to guard against. A holder cannot use what it was never given a reference to — there is no lookup step for a bug to corrupt.

## Production implementations

This is not a theoretical model. It is deployed at scale in production systems.

**Fuchsia OS** (Google) implements PairingAsPermission at the operating-system level. Every component must have capabilities explicitly routed to it through the component topology. A component that has not been given a capability route is structurally unreachable from the resource — not access-denied, but no pathway. Fuchsia runs on every Google Nest Hub model. [^2]

**seL4 microkernel** has a machine-checked formal proof of capability confinement: a process cannot access a resource it was not explicitly given a capability for. The proof covers integrity (data cannot be modified without authority) and authority confinement (authority cannot exceed what was delegated). seL4 is the gold standard for formally verified security models. [^3]

**WireGuard** implements the same pattern at the network layer. The `AllowedIPs` table is the capability table. A node with no entry for a destination cannot send packets to it. Access control is structural to the routing, not a check at transmission time.
This is not a theoretical model. It is deployed at scale in production systems outside this platform.

## Three engineering risks and their defences
**Fuchsia OS** (Google) implements capability-based access control at the operating-system level. Every component must have capabilities explicitly routed to it through the component topology. A component that has not been given a capability route is structurally unreachable — not access-denied, but no pathway. Fuchsia runs on every Google Nest Hub model.[^2]

**Risk 1 — Confused deputy at the Command (high)**
A per-project orchestration sends the Command a message asking it to perform a cross-project operation. If the Command relays without validating the requester's scope, the requester has executed a capability it does not hold, using the Command as deputy.
**seL4 microkernel** has a machine-checked formal proof of capability confinement: a process cannot access a resource it was not explicitly given a capability for. The proof covers both integrity (data cannot be modified without authority) and authority confinement (authority cannot exceed what was delegated). seL4 is the gold standard for formally verified security models.[^3]

Defence: the Command validates per-caller scope on every request. The planned `app-orchestration-command` implementation includes this check as the first operation in request handling. It is not optional.

**Risk 2 — Command as availability single point of failure (medium)**
If the Command is unavailable, cross-archive coordination is blocked.

Defence: per-project archives operate fully without the Command — they serve local resources and queue cross-archive requests for retry. No hard failure. Active-passive Command redundancy is a planned later-phase addition.

**Risk 3 — Multi-tenancy on shared physical nodes (medium)**
When multiple logical projects share a single Totebox Archive node, the Command holds capabilities for multiple tenants. If the Command uses the wrong capability token for a request, one tenant's data is accessible under another tenant's scope.

Defence: capability attenuation via separate module identifiers. The Command holds distinct `X-Module-ID` tokens per tenant. The shared archive enforces per-identifier partitions. The `service-slm` access-control gateway already implements this pattern — the Command must pass the correct module identifier for the requesting archive on every call, never its own.

## Implementation

The current implementation uses `system-mba-shim` — a transitional layer behind which conventional OAuth2 authentication sits. The `system-mba-shim` interface is the clean boundary: when the full PairingAsPermission cryptographic model (certificate-based peer-to-peer key exchange) replaces the OAuth2 layer, no calling code changes. The interface stays constant; the implementation behind it is upgraded in place.

The Six Orchestration Contracts include `pairing_attestation` as `SYS-CONTRACTS-01`, hardcoded into the operating-system kernel. It is not configurable. (Correction, 2026-08-02: this is not physically possible today — `os-totebox` is a plain Rust/tokio binary with zero seL4 dependency, confirmed via this repo's own `cleanup-log.md`; there is no kernel to hardcode a contract into. `SYS-CONTRACTS-01` appears in the real codebase only inside a planning artifact, `service-content/artifacts/FOUNDRY_MASTER_CONTEXT.md`, as a documentation-topic reference, not kernel code. Separately (**retracted, 2026-08-02**): this correction previously said `os-orchestration`/`app-orchestration-command` "is not a built crate at all" — that was checked against a stale local branch; both are real on canonical (`origin/main`), `app-orchestration-command` substantially so (see [[personnel-permissions]] for its real function). The seL4-kernel and `SYS-CONTRACTS-01` findings above are unaffected by this retraction. Flagged, not resolved.)

## The Trustworthy System

PairingAsPermission is one layer of the Trustworthy System pattern: the architecture's attestable trustworthiness compounds over time. Every pairing event is an immutable ledger entry — the history of who was connected to what is append-only. Trustworthy System Attestation produces quarterly signed reports that extend the attestation chain. Apex permissions are co-signed. The pairing topology at any point in time is auditable from the Command's `pairings.yaml` plus the distributed `MANIFEST.md` files held by every paired peer.

Pairing is the permission. Topology is the audit.
**WireGuard** implements the same pattern at the network layer. The `AllowedIPs` table is the capability table — a node with no entry for a destination cannot send packets to it. Access control is structural to the routing, not a check performed at transmission time.

## See also

- [[totebox-orchestration-development]] — Totebox Orchestration development architecture that applies this model
- [[doorman-protocol]] — the Doorman service that operates as the gateway in the capability topology
- [[machine-based-auth]] — machine-based authentication layer that operates alongside the pairing model
- [[compounding-substrate]] — the broader architecture within which this access model compounds
- [[three-ring-architecture]] — the ring boundary model that PairingAsPermission enforces structurally
- [[pair-a-new-device]] — step-by-step guide: register a device and assign a pairing tier

- [[machine-based-auth]] — the real pairing-ceremony mechanism that embodies this principle today
- [[personnel-permissions]] — the platform's separate, tier-based authorization model for personnel access, distinct from this node-level capability model
- [[compounding-substrate]] — the broader architecture this access model operates within
- [[three-ring-architecture]] — the ring boundary model this principle reinforces at the node level
- [[pair-a-new-device]] — step-by-step guide: register a device through the pairing ceremony