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

Context quality and review

How Viewport prevents agent-written context from polluting a shared vault.

Agents can suggest context updates, but suggestions are not trusted entries.

The core idea is simple: candidate first, reviewed entry second.

Rendering diagram...

What prevents pollution

The platform does not promote a candidate just because an agent wrote it. Approval requires a reviewer decision. The decision is signed by the control plane and verified by the trusted edge before the candidate becomes an approved encrypted entry.

This matters because the platform does not have the plaintext candidate body. It can route the review, store metadata, and record the decision, but the trusted edge is the component that can turn the locally cached plaintext candidate into a real encrypted event.

What reviewers should check

Reviewers should approve context only when it is:

  • durable enough to help future sessions
  • specific enough to avoid broad misleading advice
  • attached to the right vault and repo
  • free of transient debugging output
  • not a secret that should live somewhere else
  • not duplicating a better existing entry

How large vaults stay useful

Large vaults need curation. Viewport provides the mechanical gates, but the team needs operational hygiene:

RiskControl
Stale knowledgereview old/high-use entries during incidents or releases
Duplicate entriesuse digests and review search before approving
Overbroad advicerequire source/rationale in candidates
Wrong audiencesplit vaults by repo, team, or resource where needed
Prompt bloatuse bounded bundle profiles and max item limits
Silent driftreview candidate volume and approval rate in the inbox

Does every run load everything?

No. The daemon asks for a resolved context bundle, not a full plaintext dump of the vault. The bundle is scoped to the repo, provider, profile, query, and max item limit.

The practical target is:

  1. stable profile-pinned context for the repo
  2. a small number of relevant search-selected entries
  3. a manifest that says what was included
  4. reviewable candidates for anything the agent thinks should be added later

That is the difference between governed team memory and prompt sludge.

On this page