Security and isolation
Verify Shiplet's trusted-kernel, sandbox, capability, state, and ownership boundaries.
Shiplet treats every package as untrusted application code. The kernel alone owns authentication, authorization, capability issuance, actor attribution, immutable audit, activation, rollback, orchestration, secrets, limits, cross-Shiplet routing, and the global event index.
No ambient browser credentials
Artifact and widget JavaScript receive no review bearer, OAuth token, platform session, claim credential, or broad capability. The former window.__SHIPLET_REVIEW__ credential global is not published.
The trusted document puts artifact and widget content in separate sandboxed frames with opaque origins. Typed requests bind the expected source window, opaque origin, page-lifetime channel nonce, Shiplet, revision, operation, bounded payload, and unique request ID. The host keeps a request ID replay set for the page lifetime. The production widget request has no per-message sequence or expiry field; session and capability expiry are enforced separately. A wrong origin, wrong source window, replayed request, malformed or oversized payload, Shiplet scope mismatch, or revision mismatch fails closed.
Human-attributed writes require a trusted top-level confirmation. Child code cannot supply actor identity or invent approval.
The current browser-widget iframe has no Shiplet-enforced per-widget heap, CPU, or lifetime ceiling. Sandboxing confines origin and authority but is not a hard browser resource quota. If hostile widget code makes a review tab unresponsive, reload or close the review and repair the widget through a new draft; do not weaken the sandbox or add credentials to recover it.
Authority matrix
| Boundary | Receives | Never receives from Shiplet |
|---|---|---|
| Artifact or widget frame | Exact files, public scope, typed request channel | Platform cookies, OAuth or claim material, raw grants, shared bindings |
| Custom MCP handler | Exact input and narrow per-call handles | Kernel tools, undeclared capabilities, ambient egress, secrets |
| WordPress installation | One exact-origin revocable installation | Organization key in page source or WorkOS credentials |
| Customer Worker | Its customer-owned target resources | WorkOS credentials, OAuth vault, shared D1/R2/DO, sibling state |
| Temporary claim | Static preview and one trusted backend handoff | Claim material in package or public API projections |
| Portable export | Exact authored code, schema, instructions, validation, provenance | Kernel-owned state, credentials, grants, sessions, deployments, claims, audit history |
Capabilities, state, and egress
Capabilities are actor-, Shiplet-, revision-, action-, resource-, effect-, request-, expiry-, and revocation-bound. Sibling ID or storage-key guesses do not change the namespace. State stays outside drafts and exports; rollback does not rewind it.
Custom MCP state is limited to 32 KiB per value, 128 keys, and 256 KiB per revision namespace. The isolated-runtime policy limits one call to 1 second, the platform-enforced 128 MiB isolate ceiling, and four subrequests or capability calls, with hard termination and no ambient bindings.
Custom MCP has deny-by-default egress: its Dynamic Worker has no global outbound network and receives only an invocation-local capability broker. Handlers run only when the Dynamic Workers contract, Workers Paid entitlement, Worker Loader binding, and exact support-release attestation are all present; otherwise they return runtime_unavailable rather than relaxing limits. The authenticated deployment-status API and Ownership & deployment view are authoritative for live readiness. Customer-owned code changed outside Shiplet is customer-controlled and untrusted; package metadata cannot constrain it.
Audit and failure safety
Security-sensitive effects create kernel-owned immutable audit records or durable journals. Validation alone never activates. A denied capability, stale promotion, or failed deployment leaves the prior active revision unchanged.
A project-authorized agent credential with shiplets:write may promote or roll back with explicit approval; the kernel attributes and audits the agent effect. Customer-owned deployment requires a trusted browser-authorized human session.
Export boundary
Shiplet never adds kernel-owned credentials, grants, sessions, state, deployments, claims, or audit history to exports. Validation rejects forbidden authority fields and roots, but it does not secret-scan arbitrary package file contents. Authors must remove secrets placed inside source or artifacts before sharing them.
Next: inspect extension authority, ownership and revocation, or human and agent policy.