Incident response for early partners

How to contain a suspected Viewport run, worker, route, or provider issue during the launch rollout.

Use this runbook when a governed run did something unexpected, a worker appears mispaired, a provider receipt looks wrong, or a team member suspects a credential or route has been exposed.

This is a practical launch runbook. It is not a SOC 2 incident program, legal notice policy, or enterprise breach process.

First Fifteen Minutes

Keep containment simple and reversible:

Pause the intake path that created the run.
Stop the affected worker.
Preserve the run id, provider receipts, and current .viewport/ commit SHA.
Do not delete the run, branch, Slack message, or PR until evidence is copied.
Rotate provider or model credentials if raw secret exposure is plausible.

For a self-hosted worker:

vpd worker stop
vpd worker doctor --json > /tmp/vpd-worker-doctor.json
vpd status --json > /tmp/vpd-status.json
vpd check . --json > /tmp/vpd-check.json

If vpd worker stop does not stop the process, use your process manager to stop the worker service and record the command you used.

Containment By Failure Type

Symptom	Immediate containment
Wrong Slack or GitHub event started a run	Disable or narrow the matching `.viewport/routes/*.yaml` route, commit the change, and sync.
Worker claims the wrong team or repo	Stop the worker and verify the active profile, server, workspace, runner pool, and workdir before restart.
Approval gate was skipped or wrong person approved	Stop the worker, keep the run blocked/failed, and inspect the approval policy plus reviewer tag membership.
GitHub PR touched the wrong files	Close the PR without merging, preserve the branch, and inspect the policy resource bounds before another run.
Slack completion posted in the wrong place	Preserve the message permalink and timestamp, then check source-thread context and fallback-channel config.
Token or credential appears in logs	Stop the worker, rotate the credential, and send only sanitized evidence to support.
Provider side effect repeated	Preserve both provider object URLs, then check idempotency and provider receipt rows before retrying.

Evidence To Preserve

Collect these identifiers before making destructive changes:

workspace and team;
route name and .viewport commit SHA;
workflow/run id and runtime run id;
worker name/id and profile path;
approval decision id, approver, and timestamp;
GitHub PR URL or branch name;
Slack permalink or channel timestamp;
provider receipt id;
relevant denial code or failure class.

Use Support packet for the exact collection format. Never share raw provider tokens, pairing codes, bootstrap tokens, claim tokens, lease tokens, worker private keys, cookies, or model API keys.

When To Restart

Restart only after the containment reason is understood.

Safe restart conditions:

the route or policy has been corrected and committed;
vpd check . passes on the exact repository/workdir;
vpd worker doctor --json shows the expected server, workspace, worker, transport, workdir, and capabilities;
provider grants are still scoped to the intended repos/channels;
a human reviewer is available for the next approval gate.

If any of those are false, leave the worker stopped and keep collecting evidence.

What Support Needs

Send:

sanitized doctor/status/check JSON;
run detail screenshot showing route, policy, worker, approval, receipts, and failure;
provider permalink/URL when safe to share;
the .viewport route and policy file paths;
a short timeline of what happened and what containment action was taken.

Do not send raw transcripts or source snippets unless your team has approved that data capture.

What This Does Not Cover Yet

These are enterprise hardening items, not launch claims:

formal breach notification workflow;
SSO/SCIM-driven emergency access review;
customer-managed data residency commitments;
tamper-evident audit export;
managed-runner isolation incident drills;
contractual retention/deletion SLAs.

Track those separately before enterprise onboarding.