GuideNotesiPhoneMacWebAI agents
Shared note privacy
Understand invited accounts, shared note content, and changes to access.
Inviting someone shares the note’s writing and accepted changes. Checklist connections, Keep as a list, authored link labels, table state and stable block identities remain part of the shared writing.
Keep your private details
When shared-note privacy protection is enabled, older source text, import details, private picture addresses and private page references stay with the owner. The owner retains a complete reading copy. Invited people receive the same shared writing used to accept edits and catch up with changes. An older app can still send saved private fields with an edit; Kept retains those details for the owner without adding them to the shared writing.
Protection is off by default until the matching service and database support is ready. Before it is enabled, older source text, import details and other information saved alongside the note can still accompany invited collaboration. Share notes whose saved content you are ready to share. Published links continue to use their narrower reading view. Neither a reference nor an invitation grants access to a separate task, picture or child page.
Open an invitation with the intended account
Restricted invitations bind to the verified invited email or an account the owner explicitly selected. Before you join, Kept checks that account. Pending invitations follow the same rule before Kept fetches a note title or inviter name. An account-bound invitation appears for the selected account; a different account that owns the delivery email does not receive it. A forwarded restricted link shows no note title or owner name on its landing page and cannot give another person access. If an invitation does not open, ask the owner to invite the email your Kept account uses. Sign in with Apple may use a private relay address. Kept does not automatically join those identities.
Older invitations retain their recorded bearer-link mode. The account that redeems that link can join, so keep it private. During a staged database update, invitations issued before identity binding is available also use this compatibility mode. Existing links are not silently invalidated. Cancel one and invite again after the update to use restricted access. A failed delivery does not change an invitation's intended identity; a failed resend keeps the earlier usable link unless it was canceled or accepted meanwhile.
Understand table views
A table's property definitions, values, saved views, row identities and default view belong to the shared note. Hiding a property or filtering rows changes what a view shows; it does not make those values private. Sharing a parent note does not share its child pages or the pages connected to table rows.
Change access while a request is running
Kept checks the current membership or published link before returning shared content or comments. During a staged service update, comments keep working with current-access checks before writes and before responses. Once the matching database update is available, comment writes and membership changes also share a transaction lock, so a removal or role change that takes effect first prevents a waiting write from using its former permission. The compatibility path uses separate access checks rather than that transaction lock. New comments check that their place in the note still exists; replies can stay with an existing conversation after its block is deleted. A recognized retry returns the same saved comment even after its block is deleted, provided you still have access.
Membership and published links are separate grants. Removing a person does not revoke an independently active published link. Revoking that link stops new reads through it, including another image fetch after a failed older-copy request. Access changes cannot recall words or pictures someone already received.
Connect an agent
Existing agent connections keep their metadata-only shared-note access. This update grants no new agent access to shared text or discussion.
Deleting a shared block and undoing that deletion keeps its retained private details with the owner. Kept checks that every edit in a batch can preserve those details. If it cannot, the batch stays unsaved so you can recover your writing. Changes to privacy protection refresh connected copies at a newer saved version.
While this protection is off, an unavailable private-detail store does not block opening, syncing or saving through the usual shared-note path.