What Profusia is, in one paragraph
Profusia hosts documents that AI assistants publish for businesses — pages, dashboards, reports — at private, access-controlled URLs, with version history, sharing controls and optional live data. Each customer has a workspace, served from its own subdomain. Assistants connect over MCP (an open standard); people sign in with named accounts and roles. There are no third-party integrations holding your credentials — the assistant is the integration.
Questionnaire answers
Where is customer data hosted?
On Cloudflare's network: files in Cloudflare R2 object storage, metadata and datasets in Cloudflare D1. The application runs as a Cloudflare Worker. No servers of our own, no co-location, no second cloud.
Is data encrypted in transit and at rest?
Yes. All traffic is TLS; R2 and D1 encrypt at rest as platform defaults.
How are customers isolated from each other?
Two independent layers. In software: every database statement runs through a single choke point that binds it to one workspace, proven by an automated cross-tenant test suite that runs on every release. At the origin: each workspace is served from its own subdomain, so the browser's same-origin policy separates customers in addition to our checks — a valid credential presented at another customer's address is refused.
How is authentication handled?
Named accounts with owner / admin / member / viewer roles, invitation-only registration, and sessions bound to membership — removing a member ends their sessions at once. Machine access (AI connectors) uses per-workspace keys or OAuth 2.1. Every credential is stored only as a hash. Single sign-on (OIDC) is built and currently switched off; SAML and multi-factor authentication are not yet available, and we say so rather than imply otherwise.
Can we give our own customers a live view of our data, outside our organisation?
Yes — a portal shares one space, or a whole site, with a named outside audience: read-only, and live, so what they see updates as you publish. A named door asks each visitor for their name once and gives them their own revocable session, so readers can be seen and removed one at a time; an open door works like a share link — anyone holding it can view. Either way it is a bearer credential, and we say so plainly: a portal visitor's name is self-reported, never verified, and anyone the link is forwarded to can open it. Opens are counted per portal and per named visitor — never an IP address or a browser fingerprint.
Do you store our passwords or tokens for other services?
Almost none, and the exception is optional and narrow. Profusia never holds your passwords, and holds no service accounts. If you switch on Google Docs/Sheets sync, Profusia stores the authorisation Google issues for it — encrypted at rest under a key held outside the database, never readable through any API, console screen or export, and erased with your workspace. That authorisation uses Google's per-file scope: it permits access only to the documents Profusia itself creates in your Drive, and Google enforces that limit rather than our code, so the rest of your Drive is unreadable to us. Disconnecting revokes it. Every other credential in the system is one Profusia itself issues.
What are your backup and recovery arrangements?
A nightly logical backup of the entire database is written to separate storage, verified by re-reading and re-hashing before it is recorded as good, with fourteen nights retained. The restore procedure is rehearsed automatically as part of the release test suite and has been performed against the production database — not just designed. Point-in-time recovery over the last 30 days is additionally available at the platform layer (Cloudflare D1 Time Travel). Destructive actions in the product carry deliberate grace windows: emptying trash permanently takes effect after a multi-day window during which it can be cancelled, and deleting a workspace is reversible by its owner for 30 days.
What is logged, and can we get the logs?
Publishing, sharing, revoking, permission changes and sign-ins are written to an append-only audit trail retained for 400 days, exportable as CSV by your administrators. Page views are counted per document per day; visitors are never identified — no IP addresses or fingerprints are stored with views.
How long is data kept, and how does deletion work?
Documents and datasets are kept until you delete them; deletion is a reversible trash, and permanent erasure is an explicit, confirmed act with a grace window. A deleted workspace is unreachable immediately, reversible for 30 days, then permanently erased by a daily job — database rows and stored files both. The full inventory, with a retention period per data type, is published at /privacy.
Does customer content execute on your servers?
Never. 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 reach exactly one network destination — its own dataset. There is no server-side execution of customer content, so there is no sandbox to escape.
How do we report a vulnerability?
A security contact is published at /.well-known/security.txt (RFC 9116). Reports are answered directly by the operator. We do not pursue researchers who report in good faith.
Data flow
- In: your AI assistant (or a signed-in person) publishes a document over TLS to your workspace. The bytes land in R2, the metadata in D1, both scoped to your workspace at the query layer.
- At rest: private by default. Nothing is reachable without a credential your workspace issued — a membership, a share link, an access key. All credentials are stored hashed.
- Out: a share link serves the document from your workspace's own subdomain, under a strict Content Security Policy, with opens counted and visitors never identified.
- To AI providers — only if used: when a signed-in member asks a question of a document, plan or project, that content is sent to an external AI model to produce the answer. Nothing else triggers it, and nothing is sent from workspaces that do not use the feature. Details below.
AI-use disclosure
This section is generated from the same model registry the product routes on, so it cannot drift from what the software can actually do.
When does customer content reach an AI model?
Only when a signed-in member uses an ask-or-discuss feature (ask this document, ask this card, discuss this project, or the same question spoken aloud), and only the content in question — the document text, the card's own record, or the project's context. The public help assistant answers only from Profusia's own published help. AI never runs on an anonymous surface, and the whole capability is off unless the deployment has a provider configured — off is a supported permanent state.
What is stored about AI use?
No conversation is stored, no recording, and no transcript — a spoken question is processed in the same call as the answer and discarded. What is kept is a per-call ledger for billing honesty: who asked, which document or card, which model answered, token counts and cost — retained 90 days. Conversation history, where a surface shows one, lives in the member's own browser.
Can the models act on our workspace?
No. The models hold no tools. They read the content they are handed and return text — a document containing hostile instructions cannot make the model do anything, because there is nothing it can do.
Can we turn it off, or control what it costs?
Yes. AI is an entitlement per workspace — a deployment can leave it off entirely, and every workspace's spend is hard-capped per day on top of request-rate limits. Bring-your-own-key — your own provider account, so your content moves under your own agreement with the provider — is designed (encrypted at rest, write-only, unreadable even by our operator) but not yet built; we list it as a roadmap fact, not a feature.
| Provider | Catalogued models | Training on inputs |
|---|---|---|
| Google AI Studio | Gemini 3.1 Flash-Lite, Gemini 3.5 Flash, Gemini 2.5 Flash, Gemini 2.5 Flash-Lite | Its free tier reserves the right to read and train on inputs — so Profusia refuses to send customer documents to it unless the deployment asserts a no-training tier, or the workspace has explicitly accepted the trade (and every affected surface then says so to the person using it). |
| Groq | Llama 3.3 70B, Qwen3 32B, Llama 4 Scout, Llama 3.1 8B | Its free tier reserves the right to read and train on inputs — so Profusia refuses to send customer documents to it unless the deployment asserts a no-training tier, or the workspace has explicitly accepted the trade (and every affected surface then says so to the person using it). |
| Cerebras | Qwen3 32B, Llama 4 Scout, GPT-OSS 120B | Its free tier reserves the right to read and train on inputs — so Profusia refuses to send customer documents to it unless the deployment asserts a no-training tier, or the workspace has explicitly accepted the trade (and every affected surface then says so to the person using it). |
| OpenRouter | DeepSeek R1, DeepSeek V3, Llama 4 Scout | Its free tier reserves the right to read and train on inputs — so Profusia refuses to send customer documents to it unless the deployment asserts a no-training tier, or the workspace has explicitly accepted the trade (and every affected surface then says so to the person using it). |
| Mistral | Mistral Small, Mistral Nemo | Its free tier reserves the right to read and train on inputs — so Profusia refuses to send customer documents to it unless the deployment asserts a no-training tier, or the workspace has explicitly accepted the trade (and every affected surface then says so to the person using it). |
| Cloudflare Workers AI | Llama 3.1 8B | Does not train on API inputs. |
| Anthropic (Claude) | Claude Opus 5, Claude Sonnet 5, Claude Haiku 4.5 | Does not train on API inputs. |
| OpenAI | GPT-4o, GPT-4o mini | Does not train on API inputs. |
A deployment uses only the providers it holds keys for — typically one or two of these, not all — and the current live list is on /privacy.
Subprocessors (as of 2026-08-28)
| Subprocessor | Purpose | Engaged when |
|---|---|---|
| Cloudflare, Inc. | All hosting: application runtime, file storage, database, DNS, TLS | Always |
| The AI providers above | Producing answers on the ask-and-discuss surfaces | Only when a configured deployment's members use those features |
There is no analytics vendor, no error-tracking service, no email provider, and no payment processor in the product today — the absence is deliberate and this list changes only with a dated update to this page.
Incident response, and the DPA question
Incident response
What exists: a published security contact (RFC 9116), an append-only audit trail, and an operator who answers directly. What does not exist yet: a formal, documented incident-response plan with notification commitments. If your review requires committed notification terms, raise it in contracting — we would rather agree real terms with you than publish boilerplate we have not operationalised.
Data processing agreement
We do not yet publish a standard DPA. The facts a DPA operationalises — what is stored and where, retention per data type, the subprocessor list, erasure and export rights — are stated on this page and at /privacy, and each maps to something the product actually does. For a contracted engagement, DPA terms are agreed directly.
Why there is no SOC 2 report
None is in progress — deliberately. The technical controls above are built, real, and continuously tested; a formal attestation is an audit of process documentation as much as of controls, and we have chosen to build the controls first and buy the audit when a real customer's procurement requires it. If yours does, say so: that is exactly the business reason the decision is waiting for. What we will not do is imply a certification we do not hold.