Security

Pensieve builds a living context layer from the tools your team already uses. That only works if you trust it with your data — so here, in plain terms, is exactly what Pensieve does with it, and what it never does.

Isolation

Every context is strictly isolated. Your data is never pooled, blended, or co-mingled with another company's.

• A dedicated graph database per context. The context layer itself — the map — lives in its own database, created when the context is and destroyed when it's deleted.
• Row-level isolation everywhere else. Documents, files and metadata are partitioned by context and enforced with database-level row security, so every read is scoped before any application code runs.
• No shared model of "everyone". Pensieve does not build a cross-customer picture. Your map is yours alone.

Read-only by design

Pensieve's syncing is read-only. It reads what you connect in order to build your context layer — it never writes back to your tools.

• Connecting Notion, Google Drive, or another source lets Pensieve read the items you share. It does not create, edit, move, or delete anything in those tools.
• You share a chosen scope — specific pages, folders, repositories, channels, or CRM object types — not your whole account. Anything outside the scope stays invisible to Pensieve.
• Syncing is one-directional: source tools in, context layer out. Your systems of record are never modified.

If you enable it, the git mirror publishes your context layer to a GitHub repository you nominate. It's a separate grant from the connector that reads your code, it writes only to its own branch, and it never touches a source system. Off by default; disconnect and it stops. Local sync can also keep an editable Markdown folder on your computer; it is separate from source connectors.

Managed inference

Pensieve uses AI models to read your selected sources and build the context layer. Pensieve owns and operates the provider credentials; customers never need to paste or fund an OpenRouter key.

Provider credentials are not exposed to context members. Models explains the managed model policy; Plans explains what your allowance covers.

The managed model powers your Context alone — its chat, background curation and ingestion — and nothing else.

Never used to train models

Your data is never used to train AI models. It is used to build your context layer, and for nothing else.

• We do not train, fine-tune, or improve any model on your content.
• We do not sell, share, or repurpose your data.
• Your information exists to power your map of your company — full stop.

Disconnect & erasure

You stay in control of your data for its whole life, not just at sign-up.

• Disconnect a source at any time — a whole connector, one person's credential, or a single repository or website address. Future syncs stop immediately, and you choose whether to keep what it contributed or delete it; deletion is confirmed a second time. Kept data stays an ordinary source you can delete whenever you like.
• Delete a whole context at any time, and its content goes with it — the context layer, the stored documents and files, and the context's graph database.
• Keep your own copy. The git mirror publishes the map within its configured content permissions as Markdown into a repository you own, so leaving is never gated on an export request.
• Deletion is real deletion of your content, not archival. What survives is what you'd expect from an accountable vendor: an audit record that the deletion happened, and billing history — never the content itself.

Traceable to source

Pensieve doesn't ask you to take its word for anything. Every fact in your context layer traces back to a source you can check.

• Pages carry their provenance: the claims Pensieve writes cite the document or message they came from.
• When the AI you've connected answers a question using Pensieve, it can point you straight back to the original material, so you can verify it yourself.
• Nothing is a black box: if you want to know why Pensieve believes something, you can follow it back to where it was said.

Members & roles

Access is scoped to context membership. See Members & roles for invitations, editing rights and administration.

Content permissions

Active buckets enforce automatically. Owners and admins describe sensitive topics, such as payroll or fundraising, in Data → Permissions and choose who can read them. Every member can inspect bucket definitions and assignments. Manage membership with a bucket's people picker in Permissions, or a person's bucket picker in Settings → Members.

A reader needs every active bucket that matches an item. Being an owner or admin does not grant access to its content; full access is a separate, explicit grant. With no active buckets, content is unrestricted.

Pensieve classifies each chunk independently, then combines its matches for the whole item: a Page, source, decision, correction or individual transcript turn. Missing any required bucket hides that item's content. Neighbouring turns, parent Pages and cited sources keep their own classifications. Titles are classified independently, so a title may remain visible while the content shows [RESTRICTED: …].

Content is visible until classified. Classification follows uploads and edits, and known matches restrict content as results arrive. It is probabilistic and does not guarantee protection before someone first sees new content.

Limits. Classification reads text: images, and file bytes Pensieve has not converted to text, are not inspected. The titles of activity runs and changes are not classified. Where an item sits in the tree, and a title left visible, can reveal that something exists even when its content is hidden. Hiding an item recalls nothing already out: downloaded copies, shared file URLs and commits the Git mirror has published stay as they were. Being probabilistic, classification can also miss a match or restrict something harmless, so treat buckets as a strong default rather than a guarantee.

Editing a bucket keeps its ID, members and mirror grants. Each edit retains a version of its definition. A changed description triggers classification of current content and every retained Page/Data version; old document text stays unchanged. Only the current definition restricts access. While it is being classified, content is visible unless another current bucket restricts it. A name-only edit reuses the existing classifications.

Earlier definitions and classification evidence remain internal audit records; they do not enforce old rules. Deleting a bucket archives it and ends its restrictions.

The Git mirror has its own bucket grants, configured on the Git mirror page. It waits for complete classification before publishing; changing grants cannot retract earlier Git commits.

Working with your security team

Everything on this page — per-context isolation, read-only syncing, no training on your data, deletion on your terms, and traceable sources — describes how the product is built, not an aspiration. Formal certification is on our roadmap as we grow into larger deployments.

If your team runs a security review or has specific compliance requirements, talk to us — we'll walk through exactly how Pensieve handles your data and answer your questionnaire directly with the founders.