Viewport daemon, relay, and hosted runtime are available in alpha. Surfaces may change.
VIEWPORT
Security explained

Security

The launch-safe security model for hosted Viewport plus self-hosted vpd workers.

Viewport's current launch posture is simple:

vpd executes. The paired server authorizes.

vpd is open source and can connect to compatible servers. Hosted Viewport does not rely on a local daemon to decide hosted policy. The hosted server admits claims, issues leases, checks tenant boundaries, grants credentials/actions, and stores receipts.

Boundaries

BoundarySource of truth
Workspace, team, membership, workflow publicationHosted server
Worker pairing and identityHosted server plus local vpd profile
Run claim and leaseHosted server
Repo checkout, local tools, agent processSelf-hosted worker
Slack/GitHub side effectsConfigured provider grants and approvals
Run receipts and audit packetHosted server
Customer-local model keysCustomer runner environment

For v1, customer-local/BYOK model usage is the default. Token and cost metadata from the daemon is useful for insight and audit, but daemon-reported USD is not treated as an authoritative billing source.

Worker Identity

A worker is paired to a workspace and profile. Requests from worker runtime paths must be bound to the worker identity and the server-issued claim or lease. Hosted endpoints must reject mismatched workspace, team, run, lease, or workflow version data, even if the daemon sends plausible IDs.

Practical implications:

  • a worker paired to workspace A must not claim or sync workspace B work;
  • a stale or revoked runner must not receive new leases;
  • a lease must expire server-side even if the worker disappears;
  • final cleanup receipts may be accepted after suspension when they are tied to an already-issued lease;
  • worker-supplied billing or plan metadata is evidence, not authority.

Credentials And Side Effects

Provider side effects should use named grants, not broad agent-held tokens.

Examples:

  • GitHub App grant for branch/PR creation on selected repos;
  • Slack grant for a configured channel or response target;
  • context update target that creates a proposal instead of writing directly;
  • local runner secret for customer-owned model keys.

The agent should propose work. Viewport and the configured provider grant decide whether the side effect executes and record the receipt.

Data Capture

The early-partner default should be conservative:

  • metadata and run receipts by default;
  • transcript excerpts when needed for review;
  • artifact references unless a workflow explicitly captures bodies;
  • no raw lease tokens, worker private keys, bootstrap tokens, or provider secrets in proof files or support bundles.

If a page or UI surface implies stronger guarantees, treat that as a bug in the copy until the corresponding proof exists.

For a team/admin review checklist, use Early-partner security review. For a suspected bad run, wrong route, provider issue, or exposed credential, use Incident response for early partners.

What Is Not Claimed

The launch path does not claim:

  • managed ephemeral runners;
  • automated billing enforcement;
  • full SOC 2 evidence export;
  • full on-prem control plane availability;
  • blanket tamper-proof audit guarantees;
  • Slack-side approval as the only review surface.

Those may be future work. They are not prerequisites for the current hosted early-partner path.

On this page