Security, privacy, and data lifecycle

Security in Usable begins with workspace boundaries and least privilege. Privacy and retention obligations depend on the content, organization policy, applicable law, and the current Usable legal terms.

This page is operational guidance, not a substitute for the current policies at https://usable.dev/privacy and https://usable.dev/terms.

Classify before storing

Decide whether content is:

• public documentation;
• internal team knowledge;
• confidential customer or organization data;
• personal data;
• credential or security material that should not be stored as a fragment.

Use separate workspaces for materially different audiences or confidentiality requirements. Do not use tags as an access-control system.

Protect accounts and sessions

• Use your own account and approved sign-in method.
• Keep recovery and multi-factor controls current where available.
• Sign out of shared devices.
• Review unexpected invitations and sessions.
• Report unauthorized access promptly.
• Never share session cookies, CSRF values, or bearer tokens.

Browser sessions, OAuth grants, personal access tokens, application secrets, and webhook receiver credentials have different lifecycles. Manage each through its intended surface.

Apply least privilege

Grant the lowest role and token permission that supports the task. Separate read clients from write clients. Use one credential per integration so it can be rotated or revoked independently.

Review privileged access after role changes, incidents, workspace publication, or integration ownership changes.

A public workspace subscription is read-style access; it does not authorize changes.

Handle secrets correctly

Do not store credentials in:

• memory fragments;
• frontmatter, tags, or summaries;
• screenshots and attached files;
• source control;
• logs or analytics labels;
• webhook query strings;
• support threads.

Use a secret manager. If a secret is exposed, remove the content, rotate the secret, revoke affected sessions or tokens, inspect downstream copies, and document the incident without repeating the secret.

Protect public and shared content

Review titles, body, metadata, files, screenshots, collections, links, symlinks, webhooks, and application permissions. Public does not mean unrestricted authoring, and “internal” does not make customer or personal data automatically appropriate.

Avoid publishing private hostnames, infrastructure diagrams, tickets, email lists, raw event payloads, or unreleased plans.

Integrations extend the boundary

A webhook can transmit fragment content to an external receiver. An application can receive consented permissions. An MCP or REST credential can expose every workspace granted to it.

Before connecting:

• approve the destination;
• minimize scope and events;
• validate receiver authentication;
• define retention and deletion;
• redact logs;
• confirm the provider's privacy terms;
• assign an owner;
• define disconnection and incident procedures.

Deleting the Usable-side configuration does not erase data already copied downstream.

Understand AI processing

Usable uses content to provide features such as semantic retrieval and AI-assisted processing. Verify important AI-generated answers and metadata. Do not assume model output is authoritative or appropriate for publication.

The current privacy policy is the authority for how data is processed and whether content is used for model training. Recheck it when legal or product behavior changes.

Export, archive, and delete

Before account, workspace, or content deletion:

1. identify ownership and legal/organization requirements;
2. export data where the current product and policy allow it;
3. remove or transfer integrations;
4. review files, collections, and symlinks;
5. archive when historical context is required;
6. delete only with authorization;
7. account for backups, audit records, and downstream copies under current policy.

Do not promise immediate permanent erasure when the published retention policy specifies a backup or legal-retention period.

Hosted Zone data boundaries

Hosted Zones place selected private workspace data on a Leaf data plane while Cloud retains control-plane metadata. There is no silent Cloud fallback for private Leaf data.

Hosted Zone keys are shown once during registration or regeneration. Store them immediately in the approved secret manager. Hosted Zone V1 does not support file payload workflows.

Privacy requests

Use the contact and process in the current privacy policy for access, correction, erasure, portability, restriction, objection, or other data-subject requests. Do not process a privacy request through an ordinary public fragment or support discussion containing personal details.

Incident checklist

1. Stop further disclosure or access.
2. Preserve non-sensitive evidence.
3. Rotate/revoke affected credentials.
4. Restrict or remove exposed content.
5. Identify workspaces, integrations, files, and downstream receivers affected.
6. Notify the responsible security/privacy owner.
7. Follow legal and organizational notification requirements.
8. Verify remediation and update unsafe guidance.

Related pages

• Publish and share knowledge safely
• Personal access tokens
• Configure permissions, access, and token security
• Build a secure and reliable webhook receiver
• Operate Hosted Zones and Leaf workspaces