Security and isolation
Understand how Shiplet separates the artifact, review layer, reviewer identity, and agent access.
Shiplet owns the trusted review host. It authenticates reviewers, checks access, and records feedback outside the artifact being reviewed.
Browser separation
Artifact code runs in a sandboxed frame. A custom widget runs in its own sandboxed frame. Neither frame receives Shiplet cookies, browser storage, OAuth credentials, or organization API keys.
The review host accepts bounded messages from the expected frame and page session. It rejects malformed requests, replayed request IDs, mismatched Shiplets, and messages from another source window before an action can run.
Reviewer actions
Shiplet derives the actor from the signed-in session or authenticated agent credential. Artifact and widget code cannot claim a reviewer identity. Protected writes require the corresponding scope and trusted confirmation when specified.
Agent access
Interactive MCP uses browser OAuth. Claimed external agents use short-lived WorkOS access tokens that preserve a stable registration actor, a distinct delegated user, an exact organization, and recognized operation scopes. Shiplet verifies the token, rechecks current local membership, and stores no bearer or refresh material.
Only the service_auth claim ceremony is supported in this release. Anonymous registrations, durable WorkOS agent API keys, missing scopes, and cross-organization access fail closed. CI and unattended jobs continue to use narrowly scoped organization API keys.
Network and browser resources
Artifact frames use a restrictive browser policy. Custom widgets receive a typed channel to the trusted host. The widget sandbox does not impose a separate heap, CPU, or lifetime quota in the browser process, so reload or close a review if custom code makes the tab unresponsive.
Next: review Access control or connect through Code Mode MCP.