> ## Documentation Index > Fetch the complete documentation index at: https://docs.screenpipe.com/llms.txt > Use this file to discover all available pages before exploring further. # privacy filter - strip personal info before AI sees it > Strip names, emails, phone numbers, addresses, and secrets from screenpipe data before AI sees it, using local redaction or a confidential enclave. {/* https://screenpi.pe */} the privacy filter removes personal info from your screen data before the AI you're chatting with sees it. names, emails, phone numbers, addresses, account numbers, and secrets are replaced with placeholders like `[PERSON]`, `[EMAIL]`, `[PHONE]`, or `[SECRET]`. for the full local/cloud data-flow model, see [privacy data flow](/privacy-data-flow). ## redaction is on by default you don't have to switch anything on: screenpipe redacts the values you type into form fields — passwords, card numbers, secrets — locally, before they're ever stored or sent. each redaction is labeled in plain language so you can see what was scrubbed. before and after on-device redaction of a form want to see exactly what screenpipe reads? hover a capture setting and it highlights the regions of the screen it looks at. ## choose a privacy mode | mode | best for | what happens | | ------------------------ | ---------------------------------------------------------- | --------------------------------------------------------------------------------- | | local text redaction | keeping text processing on-device | a local PII model redacts text before selected AI workflows use it | | local image redaction | protecting screenshots before image workflows | a local image model redacts visual secrets when image PII is enabled | | confidential enclave | high-accuracy redaction without trusting a normal cloud VM | text is sent to an attested Tinfoil enclave with no disk and no request-body logs | | cloud media analysis off | strict local-only media handling | cloud audio, video, and image analysis calls are blocked | the shield in chat uses the configured privacy filter path for AI searches. local modes keep processing on your machine; enclave mode processes inside confidential compute. ## how enclave mode works in the chat composer, click the shield icon above the send button. the toggle is saved between sessions. when the AI asks for screen data (accessibility text, OCR fallback text, audio transcripts, etc.), screenpipe-server on your computer sends selected text to the privacy filter enclave. a token-classification model reads the text and replaces personal info with tagged placeholders. the enclave has no disk, no logs, and encrypted memory — nothing persists past the request. the filtered text comes back with names/emails/etc replaced. that's what reaches your AI chat — the AI never sees your personal info. ## what gets removed people names in any context — "Louis", "Mr. Beaumont", "louis.b\@..." email addresses in any format phone numbers including international formats physical addresses and postal codes SSNs, credit card numbers, bank accounts, IDs API keys and tokens that look like secrets URLs that look personal dates that look personal (birthdates etc) example: ``` Before: "email louis@screenpi.pe about the invoice, call me at 555-1234" After: "email [EMAIL] about the invoice, call me at [PHONE]" ``` ## why not just a regex most "PII scrubbers" are pattern matches: find anything with an `@` + a domain, replace it. that catches obvious stuff and misses everything else — names with no context, addresses with no zip code, account numbers formatted oddly, dates. our filter uses [`openai/privacy-filter`](https://huggingface.co/openai/privacy-filter), a 1.5B-parameter token-classification model fine-tuned specifically for this. it reads the whole sentence and decides, token by token, what is and isn't personal. ## why it's confidential we run the filter inside a **confidential-compute enclave** hosted by [Tinfoil](https://tinfoil.sh). confidential compute uses CPU features (AMD SEV-SNP / Intel TDX) to encrypt the virtual machine's memory at the hardware level. even the cloud provider running the physical hardware can't read the memory. what that gives you: the enclave publishes a signed hash of the container image it's running. you (or your client) can fetch the hash and check it against [the open-source code](https://github.com/screenpipe/privacy-filter). if the hashes don't match, the enclave is compromised and the client refuses to talk to it. the enclave has no persistent storage. nothing written during a request survives past the request — by design, not policy. the [server code](https://github.com/screenpipe/privacy-filter/blob/main/server.py) doesn't log request bodies. anyone can audit it. HTTPS from your machine to the enclave. TLS termination happens inside the attested boundary, so the decrypted text only exists in enclave memory. ## who sees what * **you**: you flip the toggle, you see the original data on your own screen. * **screenpipe-server (local)**: sends raw text to the enclave, gets redacted text back. runs on your computer. * **the enclave**: decrypts the text, runs the model, returns the redacted version. destroys the memory immediately. * **screenpipe cloud**: *not in the path.* our backend can't see the raw text — we built it this way deliberately. * **the AI (claude, gpt, gemini, your local llama, whichever)**: only ever sees the redacted version. in local mode, the enclave is not in the path: redaction happens on your machine before selected context reaches the AI workflow. ## where it applies toggle the shield icon in the chat composer. the app adds `filter_pii=1` to every search the AI runs on your screen data. persists across sessions. set `privacy_filter: true` in a pipe's front-matter (`pipe.md`). the pipe agent's screen searches get the flag automatically. append `?filter_pii=1` to any `/search` request against your local screenpipe-server (`http://localhost:3030/search?q=foo&filter_pii=1`). ## limits * **latency.** adds \~1-2 seconds per search on first hit. responses are cached by content hash for 1 hour so repeated data (same email thread, same IDE file) is nearly free. * **model imperfection.** >99% on common categories in our tests, but not perfect. don't rely on it as your only line of defense for critical secrets — combine with the "ignored windows" filter and don't record password managers. * **text and images.** the enclave filter operates on text already extracted from the accessibility tree or OCR fallback. separately, a local image-redaction model can redact screenshots on-device when image PII removal is enabled. raw image frames aren't uploaded to the enclave. if you enable cloud archive that uploads frames, those are separate and encrypted end-to-end by your own key. * **available on paid plans.** the shield icon is available on paid plans. compute inside a confidential enclave isn't free. users on the free plan see the shield with an upgrade link. * **fail closed.** if the enclave is unreachable, your search call fails with a clear error rather than silently returning unredacted text. you never get redaction that didn't happen. ## open source all three layers are auditable: * **filter service, Dockerfile, Tinfoil config:** [github.com/screenpipe/privacy-filter](https://github.com/screenpipe/privacy-filter) * **client integration in screenpipe-server:** [crates/screenpipe-engine/src/privacy\_filter.rs](https://github.com/screenpipe/screenpipe/blob/main/crates/screenpipe-engine/src/privacy_filter.rs) * **Tinfoil attestation SDK** for independently verifying the running enclave: [docs.tinfoil.sh](https://docs.tinfoil.sh) if you find a way to make the filter leak data, [please tell us](mailto:louis@screenpi.pe) — we take this one seriously.