Security & Trust
Profusia hosts documents that businesses send to their clients. This page describes how they are protected, and — just as deliberately — what we do not yet claim.
Running a security review? The forwardable packet answers the standard questionnaire in one printable document — subprocessors, data flow, retention, and the AI-use disclosure.
What we do
Every customer's data is isolated at the query layer
All database access runs through a single scoped choke point that binds every statement to one workspace. A query that forgets to scope itself isn't a bug we watch for — it can't be written. An automated test proves it: two separately-authenticated workspaces, one handed the other's real file identifier, and the request correctly fails.
Documents are private until you share them
Nothing you publish is reachable without a credential. Share links carry a high-entropy secret, can expire, and can be revoked individually or all at once. Every credential we issue — share links, embed links, sign-in sessions, access keys, OAuth tokens — is stored only as a hash, so reading our database yields nothing you could present back to us. There is exactly one deliberate exception, and naming it is the point of this page: if you upload a company logo, it is served from your own subdomain without a credential, because it appears on pages you have shared with people outside your organization. Nothing else is. A picture inside a written document is worth spelling out, because a browser fetches it as a separate request that carries none of your share link: the page signs a short-lived ticket for its own images as it is delivered, good for that one document's pictures for six hours and for nothing else. It is not your share link, so an image address copied out of a page hands nobody the document — and un-sharing a document stops its pictures at once, not when the ticket runs out. One kind of address works differently, and honesty about it belongs here: a live page's small data table is read at an address with no sign-in on it — that is how a shared page stays current — so anyone holding that address can read the table's rows. Keep anything private out of the table itself; the address is unguessable, it can be rotated (every page re-pointed in the same act, the old address dead immediately), and a table generated from a plan is gated — its feed answers only the page it backs and signed-in members, never the bare address.
Accounts, roles, and groups
People sign in as themselves, with owner / admin / member / viewer roles governing what they can do. A document can be narrowed further to a named group, so 'the finance team' means the finance team. Removing someone's membership ends their live sessions immediately — the membership is the authority, not the cookie.
A link per recipient, revocable one at a time
A share link can carry the name you gave it — the client, the person, the deal — so withdrawing one recipient's access doesn't mean cutting off everyone else and re-sending. Opens are counted against that individual link. What we still don't record is who: no IP address, no browser fingerprint, no per-visitor identifier. And a share link is a bearer link, so an open tells you the link was used, never that a particular person used it — we say so in the product rather than letting the label imply otherwise.
Portals: named visitors, not verified identities
A portal shares part of a site — one space, or the whole site — with an outside audience, read-only and live. Its named door asks each visitor their name once and gives them their own revocable session, so you can see readers separately and remove them separately. We say plainly what that is and is not: the visitor typed their own name, nothing verified it, and anyone the link is forwarded to can claim a session of their own. A portal link, like every outward link here, is a bearer link. Opens are counted per portal and per named visitor — a day, a count, a last-seen; never an IP address or a browser fingerprint.
Who may hand a document to an outsider is its own permission
Being able to write a document and being able to publish it outside your organization are separate rights here. A workspace can let people author freely while limiting share links and embeds to admins and owners. Activity views obey the same rules as the documents themselves: a timeline or an analytics view never shows a document — or even its title — to someone who could not open it.
Your content never executes on our servers
Published pages are static files served under a strict Content Security Policy. A page may run its own code in the visitor's browser and may reach exactly one network destination — its own dataset — and nothing else. We never execute customer content server-side, so there is no sandbox to escape.
Actions are recorded, and you can export the record
Publishing, sharing, revoking, permission changes, and sign-ins are written to an append-only audit trail, retained for 400 days and exportable as CSV by your administrators. Administrators can also see every share link currently live across the workspace and revoke any of them in one click.
Encryption, and where your files live
Everything is served over TLS, and every page tells your browser to refuse plain HTTP to us from then on (HSTS). Files are stored in Cloudflare R2 and metadata in Cloudflare D1, both encrypted at rest by the platform. Profusia never asks for, receives, or holds your passwords — to Google, Microsoft, or anything else. The one credential of yours we can hold is optional and narrow: if you switch on Google Docs/Sheets sync, we store the authorization Google gives us, encrypted, under a key kept outside the database. It is scoped so that we can only see and change the documents Profusia itself creates in your Drive — the rest of your Drive stays invisible to us, enforced by Google rather than by our own code. You can disconnect it at any time, and the documents already in your Drive are yours and stay exactly as they are.
When AI features are used, document text reaches an AI provider
The optional ask-a-question and discussion features send the relevant document or plan text to an external AI model to produce the answer — only when someone uses them, only the content in question, and only to the providers named on our privacy page. No conversation is stored, the models hold no tools and cannot act on your workspace, and the whole capability is off unless the deployment has a provider configured. The privacy page carries the current provider list and the details.
What we don't claim
A security page that lists only strengths tells you nothing, because every security page lists only strengths. Here is the other half.
No SOC 2, ISO 27001, or HIPAA attestation
None are in progress. This is a deliberate scoping choice for a product at this stage, not an oversight: the technical controls above are built and real, and formal certification follows a business reason to hold it rather than preceding one. If your procurement process requires a report, tell us — that is exactly the business reason.
No formal third-party penetration test
We publish a security contact and welcome reports from researchers, but we have not commissioned an independent pentest and do not claim one.
Isolation is logical, not physical
Customers share infrastructure, separated in software — the same model used by most multi-tenant SaaS. A small number of regulated industries specifically require physically separate infrastructure per customer; we do not offer that today.
No dedicated security officer or formal incident-response plan
The organizational process side of a compliance program does not exist yet, as distinct from the technical controls above, which do.
Reporting something
If you believe you have found a vulnerability, please tell us — we would much rather hear it from you. Contact details are published at /.well-known/security.txt per RFC 9116. We do not currently run a paid bounty program, and we will not pursue researchers who report in good faith.