Trust center
Shared context with explicit boundaries.
Handover keeps human and agent work attributable, scoped to one organization, and private until an authorized actor deliberately shares or publishes it.
Core controls
The security model at a glance
Organization isolation
Reads, writes, search, collaboration, imports, exports, and storage lookups are scoped to the authenticated organization.
Verified human identity
Web access uses Google SSO through Cloudflare Access, then resolves membership, invitation, or approved-domain policy.
Named agent identity
Agents use revocable credentials tied to a named service identity and explicit read or write scopes.
Deliberate sharing
Context remains inside its access boundary unless an authorized person explicitly grants access or publishes it.
Identity
Every action comes from an authenticated actor.
People sign in with Google through Cloudflare Access. Handover then maps the verified email to an existing membership, an invitation, or an approved company-domain join policy. Unattended agents use a named service identity so activity is not attributed to a shared anonymous key.
- Human authorship comes from the signed-in identity.
- Agent credentials are named, scoped, revocable, and displayed only when created.
- Generic MCP clients use service credentials today; configured clients such as Gatana can preserve per-user Google identity.
Data and history
Canonical records and file bodies have distinct roles.
Handover uses Cloudflare infrastructure. Canonical identity, access, revision, and collaboration records are stored in D1. Artifact bodies are stored in R2 and addressed by their content digest. Revisions are immutable; new work creates a new attributable revision instead of rewriting prior evidence.
Sharing and publishing
Public access is an explicit product action.
Creating a handover does not publish it. Mentions, assignments, folder placement, and exports do not silently widen access. An authorized actor must deliberately grant access or create a public publication, which can later be removed without altering the canonical revision.
Privacy-safe measurement
Acquisition analytics exclude private context.
First-party acquisition events may contain an opaque browser identifier, public page path, referring hostname, campaign labels, and opaque actor or organization identifiers after sign-in. They do not contain search queries, handover titles, filenames, comments, annotations, or artifact contents.
Read the complete privacy policyQuestions
Security questions, answered directly
Can one company search another company's context?
No. Organization identity is derived from the authenticated principal and server-side membership, not from an organization identifier supplied by the client.
Does mentioning someone grant access?
No. A mention creates a notification for an already-authorized identity. It never changes the handover's access policy.
Can a read-only agent create or delete context?
No. Agent operations are checked against the credential's scopes. Read access does not imply revision, collaboration, or administrative write access.
Is a handover public when it is created?
No. Public availability requires an explicit publication action. Folder placement, mentions, assignments, and provider exports do not make a handover public.
Inspect the interfaces
Connect with the access model intact.
Use the documented MCP and service-identity setup so every handover remains attributable.