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.
About this page. It describes, in plain words, how Profusia works on the date at its foot. It is a description, not a contract or a warranty. Our Terms of Service and, where it applies, our Data Processing Addendum set out our commitments to customers and govern if anything here conflicts with them. When the way we work changes, we update this page promptly and its date moves.
Running a security review? The forwardable packet answers the standard questionnaire in one printable document — subprocessors, data flow, retention, and the AI-use disclosure.
New workspaces are set up by a person for now. Before you start — which assistant to connect, how large a workspace is comfortable, and what is not switched on yet.
Seen a Profusia page used for phishing, malware or anything else the Acceptable Use Policy forbids? Report it to legal@profusia.ai with the address — we can take one document down or suspend a whole workspace.
Legal documents, in force since 12 November 2026: Terms · Privacy Policy · DPA · Acceptable use · Refund Policy
What we do
Every customer's data is isolated at the query layer
Most reads and writes of customer data go through a single layer that ties every statement to one workspace, so a query written through it cannot forget its workspace. Some paths query the database directly instead — delivering pages, uploads, billing and AI metering, sign-up and sign-in, rate limits, the nightly jobs and our operator tools; they are designed to work only from identifiers already checked against the workspace, and the automated cross-tenant tests exercise them too. An automated test, run before every release, proves the boundary: two separately-authenticated workspaces, one handed the other's real file identifier, and the request correctly fails. Each workspace is also served from its own subdomain, so the browser keeps customers apart as well.
Documents are private until you share them
Nothing you publish is reachable without a link or sign-in, with two deliberate exceptions — and naming them is the point of this page. First, your workspace's name and colours, and its logo if you upload one, are shown without a credential, on your own subdomain's front page and on pages you have shared with people outside your organization; the logo is served from your own subdomain for that reason. Second, 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 project is gated — its feed answers only the page it backs and signed-in members, never the bare address. Share links carry a high-entropy secret and can be revoked individually or all at once. A share link works until it expires or you revoke it — no expiry is set unless you choose one — and, like any link, if it is posted publicly, search engines may find it. Every credential we issue — share links, embed links, sign-in sessions, access keys, OAuth tokens — is stored only as a one-way hash, so the stored value cannot be presented back to us as the credential itself (the cookie that keeps a password-protected link open after its password is answered is worked out from that stored value, and opens nothing without the link itself). The one exception is the live data table's address described above, which is itself the key that reads the table; rotating the table revokes it. 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. Revoking a document's share link stops its pictures at once; a picture already opened through a site page or an embed can be fetched for up to six hours.
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 and disconnects their assistants immediately — the membership is the authority, not the cookie. An assistant a person connects with their own sign-in acts as that person, with that person's role and only what they can see, checked again on every request. An assistant connected with a workspace access key acts for the whole workspace and is not limited by roles. Either way, everything it does, including acts prompted by instructions it read in a document, comment, page or dataset, is the customer's act under our Terms of Service, and what Profusia returns to it leaves Profusia and is held by that assistant's vendor under the customer's own terms with it. Sign-in is by password: a sign-in lasts 30 days, and there is no two-step sign-in yet. Narrowing a document or a space to a named group needs a team or business plan (see below).
Security features on every plan
The security features on every plan, the Free plan included, are: each workspace's isolation, on its own subdomain; documents private until they are shared; the credentials we issue stored only as one-way hashes (apart from a live table's address, described above); the owner, admin, member and viewer roles; share links that can be labelled, password-protected, given an expiry and revoked, and embeds that can be revoked; ending a removed person's sessions and connected assistants; the switch that lets only admins and owners share outside the workspace; the audit trail and its export; encryption in transit and at rest; and the export of your library. Narrowing a document or a space to a named group needs a team or business plan, because a one-person workspace has nobody to separate. Customer portals, live data tables, your own logo and Google Drive sync are not part of the Free plan, and in-app AI is described below.
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. A visitor can write one thing, and only where an owner or admin has switched it on for a named door: a plain-text comment on a document in the portal, rate-limited, labelled as from a visitor whose name is not verified, and removable by any member who can edit. An open door never comments. 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. View counts are counts: how often a document was opened, by which door, never by whom — except that a link labelled for one recipient, and a portal visitor who typed a name, show the sender whether and when that link or visitor opened it, as described above. Apart from those, the main record of who opened what is each member's own trail of what they looked at — kept for that member alone for ninety days and clearable by them; no screen shows it to anyone else. A project also remembers, for each person only, when they last looked at it; the AI usage record, kept for ninety days, names who asked about which document or card; and the workspace's audit trail records each question asked of the in-app AI — who asked, about which document, project or other item, and which model answered, never the words — for its 400 days, which owners and admins can export.
Your content never executes on our servers
Published pages are static files, and we never run customer content on our servers. A page may run its own code in the visitor's browser, and the security policy we send with it limits that code's data requests to the page's own data table, if it has one, and the script files it can load to the workspace's own address — although, like any web page, it can still open links and new windows. We never change the file you stored; when we deliver it, we add a few tags of our own (a title for link previews, the address of its live data) and, for a new workspace nobody has verified yet, a notice for readers. Our host, Cloudflare, also adds a small analytics tag to pages it serves for us; our security settings block it from running, so it collects nothing, and we are switching it off. Except on a new self-serve workspace that has not been paid for, whose pages run in an isolated sandbox, a page's code runs on the same address as your signed-in Profusia pages, so a page can do anything the person viewing it could do. Publish interactive pages only from people and assistants you trust — the same care you would give a macro in a shared spreadsheet. A page's code cannot read another customer's workspace: each workspace is served from its own address.
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; we add no encryption of our own to content or backups, so your content is not encrypted from us (see below). 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 (and the folder you choose for them), plus the Google account's email address, which we keep so you can see which account is connected — 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.
Backups, and what they do not cover
Every night we copy the whole database, verify the copy by reading it back, and keep the last fourteen nights; our host also keeps a point-in-time recovery history of the database for up to 30 days, depending on our hosting plan. The copies do not include the files themselves: file contents are stored once, with no second copy, so a purged or lost file cannot be recovered. Keep your own copy of anything you cannot afford to lose — the export in Workspace settings is free on every plan.
AI: never on a tier that trains on your content
Customer content is never sent to an AI provider tier that may train on it. The in-app AI features that read workspace content — asking about a document; discussing a site, space, project or card; the Navigator's ask; drafting a project and breaking a card down; Say what you did; filing proposals; proposing a turn; Set this page; the two plan checks; and Build — run in a workspace only where its plan includes in-app AI (a Free trial does, on our lower-cost models only; the Free plan does not), and send a customer workspace's content only to the providers the Privacy Policy names, none of which trains on it: Anthropic's Claude, which answers; Cloudflare Workers AI, which is listed too and receives nothing until we connect it; and Amazon Bedrock, which never answers by default and receives a workspace's content only where someone picks one of its models or we place one in a feature's order. Amazon Bedrock processes a request in the United States; for the others we do not pin the country in which a provider processes a request, and each processes it on its own infrastructure. Each person may have one in-app AI request in progress at a time. Every request that carries a workspace's content leaves out each provider tier that may train on what it is sent unless the workspace is Profusia's own, and is refused if no other provider can answer, never sent to one that trains to get around that (filing proposals and Set this page then use counted rules with no model) — and spoken questions are not offered in a customer workspace, because neither provider can hear one. Profusia's own workspace keeps the free tiers accepted for its own documents, and every screen there says so. Each feature sends only what it needs, only when someone uses it, to one provider at a time (the next in our configured order if the first fails), and the models hold no tools and cannot act on a workspace. One AI feature is open to everyone and reads no workspace content: Profusia's help assistant. What you type into it may go to a provider tier that keeps and trains on inputs, so type nothing confidential there. A member's conversations with the in-app assistant are kept for that member until ninety days after the last exchange and can be deleted by them; a workspace's owner can switch the keeping off. No screen in the product shows them to other members or administrators, and we open them only at that member's request or on the other grounds set out under “Who at Profusia can see your data” below. We have no zero-data-retention agreement with any AI provider. The privacy page lists the providers that receive workspace content, and we add another only after notice.
Who at Profusia can see your data
Profusia is run by one person, the company’s operator, who holds administrative access to the production database, file storage and backups and can read them, as the administrator of any hosting service can. Your content is not encrypted from us. The operator console shows each workspace; its members’ names and email addresses, their roles, and when each joined and last signed in; the plan and billing status, including any refunds and chargebacks; usage and each member’s AI spend; the AI usage record, which names the documents asked about; the names of documents we have taken down, with the reasons; the addresses on pending invitations and reset links; and our notes about the workspace. It is not built to show the content of documents, comments or conversations. We open customer content only (a) when the customer asks us to, or when one of its users asks us, for support, to look at something that user can already see; (b) to investigate a security incident or a reported breach of our Acceptable Use Policy; (c) where the law requires it, or where it is needed to respond to legal process, to establish, exercise or defend a legal claim, or to prevent death or serious physical injury; or (d) to keep the service running or restore it from a backup, where that cannot be done without opening it. A person’s kept assistant conversations we open only at that person’s request, or under (b), (c) or (d). The operator can suspend a workspace, take down a single document (its members are shown the reason), make a password-reset link for any account (whoever uses it sets that account’s password and is signed in to it; the account holder is normally emailed when the password is changed with it), make an invitation that makes whoever accepts it an owner of a workspace (to set up its first owner, or to restore control to an owner whose identity we have verified), rotate a workspace’s access key, disconnect its assistants, place or release a legal hold (which keeps our erasure jobs off a workspace, and while it stands the trash purges and person erasures asked for inside the workspace wait too; it changes nothing else, so what members delete still leaves their view, a kept assistant conversation a member deletes is still deleted, and records that expire by age still go), mark a suspended workspace for erasure once its agreement has been terminated and the 30-day export window has passed (or withdraw that mark) and download a backup. A reset link, an owner invitation and a newly rotated key each give us, until they are handed on or used, a credential that could open the workspace; we make them only to pass on. Every one of these acts is recorded in the operator’s own log, and, where it concerns one workspace, in that workspace’s own audit trail as well — except a legal hold, which is recorded only in our own log and audit trail, because we tell an owner about a hold only where that is lawful and safe. A backup download is also recorded in our own audit trail, naming who downloaded which night. Viewing what the console shows, reading or changing the database or storage directly with our host’s own tools (its dashboard, command-line tools or programming interface), and a restore carried out with those tools, are not recorded. Our company’s internal operations console, Evadaroo HQ, can take the same recorded acts, except downloading a backup, releasing a legal hold, marking a workspace for erasure, reinstating a suspended workspace while anything in it is waiting to be erased, or making anything that could give someone access to our operator console, such as an owner invitation that names nobody or one of our own addresses. We build Profusia with AI coding tools (Anthropic’s Claude Code), which run on Anthropic’s systems. The credential they deploy with can also read production data. A written rule forbids them to read customer content; that is a policy control, not a technical one. Beyond this, no screen, listing or export shows your data to anyone at Profusia, and we do not read it.
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. Where Cloudflare stores our data was chosen by Cloudflare when our database and storage were set up, and is not pinned to a region.
No two-step sign-in, anywhere
Sign-in is by password alone for everyone, and our own operator console is protected by a password too. Single sign-on is built but not offered.
No dedicated security officer, and a written incident-response plan that has never been exercised
The written policies a security review asks for exist as of 2026-09-19 — access review, incident response (including how affected customers are told), change management, data classification and retention, vendor management — and each states its own gaps; they are being brought up to date with this page, and where one differs from it, this page and /privacy describe the product as it is. What does not exist: a dedicated security officer, an on-call rotation, external alerting, or a single tabletop exercise of the incident plan. One operator answers, and the policies say so rather than describing a team that is not there.
No uptime guarantee or status page
We do not offer a service-level agreement or a status page yet. Profusia is run by one operator, who answers support@profusia.ai directly.
Reporting something
A security vulnerability in Profusia
If you believe you have found a vulnerability, please tell us at security@profusia.ai — we would much rather hear it from you. Contact details are also published at /.well-known/security.txt per RFC 9116. We do not run a paid bounty program.
Good-faith security research. Section 4.3 of our Acceptable Use Policy is our vulnerability disclosure policy, and governs where this paragraph says less. The rules: test only against a workspace you own or have written permission to test, never another customer’s; do not access, copy, change, delete or keep data that is not yours, and if you come across any, stop, tell us at once, and do not keep or share it; if you are unsure whether a test is allowed, ask security@ first; do not degrade the service (no denial-of-service, load or spam testing), and do not attempt social engineering of our customers or of us, or physical testing; report what you find promptly and give us a reasonable time to fix it (we suggest 90 days) before you disclose it; and do not ask for payment as a condition of telling us. Research that follows those rules is authorized by us, and we will not bring a legal claim against you for it. That authorization is ours alone: it cannot bind a customer whose data you reach, a law-enforcement authority, or the services we depend on (Cloudflare, Paddle, Resend, the AI providers), whose own policies apply.
Abuse, and taking a document down
Report phishing, malware, copyright infringement or anything else the Acceptable Use Policy forbids to legal@profusia.ai, with the address of the page; security@ is for vulnerabilities in Profusia itself. We can take one document down without touching the rest of its workspace: every share link, embed, site page and portal stops serving it. Unless the law, someone’s safety or the integrity of an investigation requires otherwise, the workspace’s members are shown why and can reply to legal@profusia.ai to contest it; we look again and tell them, and the person who reported it, what we decided. A takedown deletes nothing — lifting it puts the document back as it was. Where the law requires us to report material — for example apparent child sexual abuse material, which we report to the National Center for Missing & Exploited Children — we report it and preserve it, and we do not restore it. A workspace we must preserve is held: it is not erased, even if its owner asked for it to be deleted, until the hold ends. We do not monitor what customers publish and are not obliged to, and acting on one report does not mean we have reviewed anything else.
Copyright complaints (DMCA)
Profusia hosts files its customers publish. If you believe something hosted here infringes your copyright, send a notice to legal@profusia.ai, with the subject line “DMCA notice” and the address (URL) of the material on Profusia. What a notice must contain (the elements in 17 U.S.C. § 512(c)(3)), how to send a counter-notice if your own material was removed (the elements in 17 U.S.C. § 512(g)(3)), and how we treat repeat infringers are set out in Section 9A of our Acceptable Use Policy; we handle notices and counter-notices that way. When a notice meets those requirements, we disable access to the material and tell the workspace that published it, and in appropriate circumstances we suspend, and may terminate, the workspaces of repeat infringers. A knowingly false notice or counter-notice can make you liable for damages (17 U.S.C. § 512(f)).