Skip to content

Publish or share a note safely

KB-1 launch docs use “share” carefully. In the current public product story, sharing usually means authenticated organization access to a vault or note. Do not assume a note has an unauthenticated public URL unless your deployment shows a specific publishing control for that scope.

Audience Safer path
Yourself on the same machine Use the local daemon or the plain files.
A teammate Add the teammate to the organization, then send the authenticated note path.
An agent you operate Configure the agent through MCP with the minimum vault you intend it to use.
The public internet Export or publish only through an explicit reviewed publishing flow.
  1. Confirm the teammate already has a KB-1 Cloud account.
  2. Add them to the organization that owns the vault.
  3. Open the note in the Cloud app.
  4. Copy the authenticated app URL for the note.
  5. Send the link only after confirming the note does not include private material from another project, client, or organization.

The access check happens at the organization boundary. A non-member should not be able to enter the vault just because they received the URL.

Agents should not receive broad secrets by default. Prefer a local or controlled MCP configuration, then test with a scratch note before giving the agent real work.

A safe smoke test is:

  1. List vaults.
  2. Read one harmless note.
  3. Create a scratch note.
  4. Read the scratch note back.
  5. Delete the scratch note or move it to the team’s chosen archive/trash path.

If your deployment includes public publishing, review these before using it:

  • Is the link authenticated, unlisted, or public?
  • Does the page include backlinks, embeds, attachments, or note metadata?
  • Could an agent have recently written draft material into the note?
  • Which vault home owns the source content?
  • How will you revoke or update the published copy?