# Security and your data

Who can read what, what leaves the machine, and what deletion actually removes.

## Isolation

Every workspace-scoped table in the database carries a row-level security policy, forced even for the account the application connects as. The policies fail closed: a query that does not establish which workspace it is acting for returns zero rows rather than somebody else’s.

Which workspace a request acts in comes from your credential, never from the request body or a query parameter. Naming a workspace you are not a member of returns nothing.

## Credentials

- Tokens are shown once, at creation, and stored only as a hash.
- Tokens always expire. There is no non-expiring agent credential.
- A token’s prefix is greppable and self-identifying, so a leak is easy to recognize. Settings → Agents & tokens lists every live token by label, scopes and last use, and revokes it there.
- Revoking a token revokes every token delegated from it, and every outstanding write handle it minted.
- A delegated token can only ever narrow its parent.

`fp login` uses the device authorization flow, so a terminal never holds your password. Approval happens in a browser, and the workspace comes from the approving session rather than from the device asking.

## Secrets in your notes

Developers keep credentials in notes. Fastpad detects them with deterministic rules — the same rules a secret scanner uses — and masks them on the way out, never in the document.

Two parts of that matter. It is never a model deciding: a probabilistic safety property is not a safety property. And it never edits your note: redaction happens when content leaves, so your own note keeps saying what you wrote.

A false positive becomes a visible placeholder you can expand, never silent loss.

## What leaves the machine

Outbound access is denied by default. A tool returning a link from your notes hands back a neutralized reference rather than a live URL unless the token carries an explicit host allowlist.

Note content is treated as data everywhere it reaches a model — fenced, quoted, and never as instructions. That is the premise behind the whole proposal model: a note can say anything, including “ignore your instructions”, and it is text either way.

## Publishing

A published note is readable by anyone with the link, and nothing else in the workspace is. Only a signed-in person can publish — an agent that could publish could exfiltrate a workspace by making it public and reading it back.

To an anonymous caller, a note that is unpublished, a note that was deleted and a note that never existed are indistinguishable. The public route cannot be used to find out which identifiers are real.

## Deletion and erasure

Trash is reversible and keeps everything. Purging removes the rows after the retention window. Those two are what “delete” normally means.

Erasure is a stronger claim and a different mechanism: each note’s content is encrypted under its own key, so erasing means destroying that key. It is the only way to make the copy on a laptop that has been offline for a year unreadable — and it is why deletion and erasure are named separately here rather than treated as the same act.

Your notes leave whole, at any time, as Markdown you can read with anything: [the mirror](/en/docs/markdown), the export, or the API.
