Security and trust boundaries
The first product version runs only owner-controlled plugins. Its qualified native process runtime is not a hostile-code sandbox. Separate processes provide lifecycle ownership and fault handling; they do not isolate code from the host user's files, network or credentials. See architecture, execution profiles and current qualification.
Current responsibilities
| Boundary | Platform responsibility | Application responsibility |
|---|---|---|
| Installation | Validate immutable artifacts, compatibility metadata and explicitly required publisher signatures | Own trusted publisher keys independently of upload credentials, protect release files and decide which artifacts may execute |
| Tenant binding | Preserve host-selected context and operation grants | Authenticate users and select their authorized installation |
| Callback | Route bounded calls with immutable binding context and cancellation | Check object ownership, argument shape, destinations and side effects |
| Protocol | Enforce envelope identity, UTF-8, byte/depth limits and reserved-field rules | Treat plugin results as domain input requiring validation |
| Lifecycle | Own worker leases and retain uncertain cleanup state | Preserve recovery evidence and reconcile external outcomes |
| Resource admission | Apply the selected execution profile and configured admission bounds | Measure deployment headroom and choose application limits |
Treat data intentionally sent to a plugin as disclosed to it. Configuration is not a credential vault. Prefer narrow host callbacks that select tenant-scoped credentials inside the application. A timeout does not establish that a side effect failed; retry only under explicit idempotency rules. See native operations and worker lifecycle.
Optional Docker adapter
Docker regression fixtures remain under tests/ and plugins/. Their restricted container profile and adversarial parser/callback scenarios cover a different execution surface. Ordinary containers share a kernel and do not establish arbitrary hostile-plugin production support. Docker measurements from the PoC are historical, not the current native package baseline.
Public third-party plugins, stronger sandboxes, a privileged lifecycle broker and cross-node security protocols require separate design and qualification. The earlier threat assessment and rejected alternatives remain retrievable through the history index; they are not current release requirements or implemented guarantees.
Publisher authentication
Current source supports required publisher signatures over exact sealed manifests. Multiple trusted publishers and key rotation are supported without changing manifest pins. Configuration belongs to the deployment authority, outside the installation API. Trust applies to every plugin admitted by a catalog and does not prove safe code, prevent rollback or add process isolation. Key withdrawal takes effect on verification under a replacement snapshot; existing bindings/workers require explicit host-owned disposal and re-resolution. Package publication is separate from source implementation.