Platform Sandbox and Capability Permissions¶

Tool — instantiates Platform Core / Extension Design

Runs each extension inside an isolation boundary holding only the explicitly granted, revocable capabilities it needs — so a misbehaving or malicious extension is contained rather than able to reach the core or its neighbours.

Review can decide an extension looks safe and a manifest can declare what it wants, but neither actually stops a live extension from overreaching. Platform Sandbox and Capability Permissions is the runtime that does — it executes each extension inside an isolation boundary and hands it only the capabilities it was granted, each one scoped, revocable, and audited. Its defining move is enforcement at execution time: it turns "we trust this extension" into "we contain this extension," so that whatever an extension does, its blast radius is bounded to what it was permitted and the resources it was allotted. Default-deny, least privilege, contained failure.

Example¶

A browser-based collaborative design tool lets third parties ship plugins. An "export to SVG" plugin runs inside an isolated worker with exactly one grant: read access to the current document. It has no network, no filesystem, and no visibility into the user's other open files — so even a compromised build of it cannot exfiltrate anything it was never handed. When a different plugin needs to call an external font API, that network capability is a separate, explicit grant the user sees at the moment it's requested and can revoke afterward. And when a buggy plugin spins into an infinite loop, its CPU quota kills the worker without freezing the editor. Isolation, an explicit scoped grant, revocation, and contained failure are all doing their job.

How it works¶

What distinguishes the enforcement layer from the declaration and the judgment:

Default-deny isolation — the extension starts with nothing and runs behind the strongest boundary the substrate offers (separate process, sandbox, worker, resource quota, network segmentation).
Capabilities, not trust — every power is an explicit grant, bound to a purpose and an owner, revocable, and logged, so access is auditable and can be pulled without redeploying.
Bounded resources — CPU, memory, network, and time ceilings with defined behavior at the ceiling (throttle or kill), so one extension can't starve the core or its neighbours.
A controlled escalation path — requesting more capability is an explicit, approvable event, not a silent default.

Tuning parameters¶

Isolation strength — a soft in-process boundary versus a separate process, VM, or hardened sandbox. Stronger contains more but costs latency, throughput, and integration richness.
Capability granularity — coarse buckets versus fine per-resource scopes. Finer tightens least privilege but multiplies prompts and complexity.
Grant timing — install-time consent versus runtime, just-in-time prompts; static grants versus revocable ones.
Resource quotas — where the CPU / memory / network / time ceilings sit and whether hitting them throttles or terminates.
Escalation friction — how hard it is for an extension to request more, and who must approve it.

When it helps, and when it misleads¶

Its strength is that it makes trust unnecessary for containment: a plugin that was never granted the network simply cannot reach it, no matter who wrote it or what slipped past review. It is the mechanism that keeps one extension's failure, compromise, or resource hunger from becoming the platform's.

Its failure modes come from erosion. Over-broad grants — users reflexively clicking "allow all," or a platform bundling powers for convenience — quietly re-open the risk the sandbox was meant to close. Strong isolation has a real performance and integration cost, tempting teams to weaken it until it is nominal. And the subtle trap is the confused deputy: a low-privilege extension induces a more-privileged core component to act on its behalf, so the boundary holds on paper while the harm flows through. The discipline is the principle of least privilege^[1] — grant the minimum, bind each grant to purpose, owner, audit, and revocation, and treat every capability as attack surface rather than a feature.

How it implements the components¶

modularity_and_isolation_boundary — it provides the actual runtime containment (process, sandbox, quota, network boundary) that keeps an extension's failure, resource use, and security local.
platform_dependency_and_permission_model — it enforces least privilege: only declared, scoped, revocable, audited capabilities and data access, with prohibited interactions blocked at runtime.

It does not declare those permissions — the builder does, in Platform Extension Manifest — nor judge whether the requested set is acceptable ([Platform Extension Review and Certification]). It contains harm but does not detect ecosystem-wide patterns of it; that is Platform Extension Health and Dependency Dashboard.

Instantiates: Platform Core / Extension Design — the sandbox is the runtime containment that makes open extension safe.
Consumes: Platform Extension Manifest supplies the declared permission set the sandbox enforces.
Sibling mechanisms: Platform Extension Review and Certification · Platform Extension Manifest · Platform Plugin and Extension Registry · Platform API and SDK · Platform Architecture Blueprint · Platform Capability Catalog and Portal · Platform Conformance Test Suite · Platform Ecosystem Change Council · Platform Extension Health and Dependency Dashboard · Platform Reference Implementation · Platform Semantic Versioning and Release Train · Platform Migration and Deprecation Tooling

Notes¶

The sandbox enforces the declared permission set, so it is only as protective as the manifest is honest and the review is strict. Manifest → review → sandbox form a declare-judge-enforce chain: the sandbox is the last and least bypassable link, but it cannot compensate for a permission the platform chose to grant in the first place.

References¶

[1] The principle of least privilege — Saltzer and Schroeder's design rule that every component operate with the minimum privilege sufficient for its task — is the standard corrective to over-granting and the reason each capability carries an owner, an audit trail, and a revocation path. ↩