Security & AI-use packet
The forwardable version of /trust and /privacy, written for the person running your security review. It describes the product as it is on the date at its foot; where the honest answer is “not yet”, it says not yet.
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.
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. Apart from an optional Google Drive sync, no integration holds credentials of yours. Your AI 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. Where Cloudflare stores the data was chosen by Cloudflare when our database and storage were set up; it is not pinned to a region, and we do not offer a regional-pinning guarantee.
Is data encrypted in transit and at rest?
Yes. All traffic is TLS; R2 and D1 encrypt at rest as platform defaults. We add no encryption of our own to content or backups, so content is not encrypted from us (see “Who at Profusia can see our data?”). The one third-party credential we can hold, the optional Google Drive authorization, is encrypted under a key kept outside the database.
How are customers isolated from each other?
Two independent layers. In software: most reads and writes of customer data go through a single layer that ties every statement to one 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), designed to work only from identifiers already checked against the workspace; and an automated cross-tenant test suite, which exercises those paths too, 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 share link, sign-in or assistant connection presented at another customer's address is refused; an access key works from any address but only ever reaches its own workspace.
How is authentication handled?
Named accounts with owner / admin / member / viewer roles; registration by invitation, or — where a deployment has opened it — self-serve sign-up confirmed by an emailed single-use link, rate-limited per network and per mailbox under a daily ceiling; and sessions bound to membership — removing a member ends their sessions and disconnects their assistants at once. A sign-in lasts 30 days, and sign-in attempts are limited per account and per network. Machine access (AI connectors) uses per-workspace keys or OAuth 2.1: 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 and ended when they leave or reset their password; 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. A connected assistant and a workspace access key keep working until they are disconnected or rotated. Every one of these credentials is stored only as a hash. A person can change their own sign-in email, but only where the deployment can send email (and, for someone whose only workspaces were opened through self-serve sign-up and are not yet paid for, only once one is paid for), and never on a password alone: it takes the current password and a single-use link opened at the NEW address, the old address is told when it is asked and again when it is done (with a link that undoes it for seven days), every other session is signed out, and the old address cannot be claimed by anyone else for 30 days. Single sign-on (OIDC) is built but not offered; SAML and multi-factor authentication are not available — for anyone, including our own operator console, which is protected by a password — and we say so rather than imply otherwise.
Can we give our own customers a live view of our data, outside our organization?
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. The one thing a visitor can ever write is a plain-text comment, and only through a named door on which an owner or admin has switched comments on (off by default): it is rate-limited, capped in size, labelled as from a visitor whose name is not verified, shown to that visitor alone and to the workspace's members, and removable by any member who can edit. 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 authorization 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 authorization uses Google's per-file scope: it permits access only to 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; 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 whole database — document records, version history, projects, datasets, comments and settings, but not the files themselves — is written to the same Cloudflare R2 bucket as customer files, under a separate prefix that no file's key can collide with. Each one is verified by re-reading and re-hashing before it is recorded as good, and fourteen nights are kept. Our operator can also take a copy of the whole database by hand — a night downloaded through the operator console (recorded in our operator log and our own audit trail), or an export made with our host's own tools before a restore (not recorded); such a copy is kept only on a device or in an account under our control and deleted once that recovery or test is complete, within 30 days of being taken, unless we keep it for a legal reason such as a legal hold, for as long as that reason requires. Items emptied from the trash are permanently erased only after that night's backup has verified. The restore is rehearsed automatically, on test data, in every release test run, and was performed once, on 18 August 2026, from an export of the production database. Cloudflare's own point-in-time recovery also covers the database, for up to 30 days depending on our hosting plan. File contents are stored once, in Cloudflare R2, with no second copy and no object versioning: a purged or lost file cannot be recovered. What protects them is that nothing in the product deletes a file's bytes without a window to undo it — emptying the trash takes effect about three days later, unless the workspace's access key explicitly asks for it to happen at once, and deleting a workspace can be reversed for 30 days. We do not promise to recover lost data. Keep your own copy of anything you cannot afford to lose — the export (Workspace settings › Library › Export) is free on every plan and runs in your browser.
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; some entries name a person by email address, and they stay for their 400 days even if that person is erased. Opens are counted per day for each document, each share link and each named portal visitor, and kept for two years, and Profusia's own public pages (the marketing site, guides, help topics, templates, and the trust and legal pages) are counted as a number per day, per page, and per referring site reduced to one word from a short fixed list, such as a search engine or an AI assistant. No IP address, browser detail, cookie or query string is stored with either count, and the public-page count never includes a page on a customer's own workspace address; a link labelled for one recipient, or a named portal visitor, does show the sender whether and when it was opened. IP addresses are held for about two days inside rate-limit counters, only to slow down abuse; a self-serve sign-up request keeps the network address it came from for about 35 days (90 if we suspend it for abuse), as /privacy describes. The same counters hold, until shortly after each month ends, the workspace's and each person's count of assistant calls that month, and the workspace's count of live-table updates, to apply the plan's allowances; a person sees their own count in Plan & billing.
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; copies of the database remain in our 14-night backups and the platform's recovery history until they age out, and a few records of our own (our operations and billing-notice logs, the plan, trial and limits the workspace had, with nothing about any person, a record of the erasure and of any legal hold in our own audit trail for 400 days, a hold on the workspace's address, and the do-not-send list) stay afterwards. Cancelling a paid plan moves a workspace to the Free plan and deletes nothing. A workspace nobody pays for and nobody uses is scheduled for deletion after a stated period — a self-serve workspace that never paid, once nobody has used it for 90 days since its trial ended; any Free workspace, once nobody has used it for 12 months since it moved onto the Free plan — after notices to its owners 60, 30 and 7 days ahead of that date, and using it keeps it and starts the period again (a member signing in there or in any of their other workspaces, or using it while signed in, or an assistant connected to it acting in it or renewing its access, counts; visits to its published pages do not). From that date it is unreachable, exactly as if an owner had deleted it, an owner can restore it for 30 days (and a member signing in during that time puts it back), and it is then erased — so at the earliest about 120 days after a lapsed trial, or 13 months after last use. Neither is ever scheduled for a workspace with a live subscription, one for which we have recorded a deal of its own (which is how we record an order signed by both parties), one with a free window we opened or features we granted by hand, or one we set up ourselves and never put on a plan. Suspending a workspace deletes nothing, and a workspace we have suspended, or must preserve for an investigation or legal process, is held: none of our erasures runs on it — not a deletion its owner asked for, not the deletion or erasure of an unused workspace, not items emptied from its trash — and nobody can be erased from it, until the suspension or hold ends. The exceptions are the erasure that follows a termination of our agreement, which runs while the workspace is still suspended and is delayed only by a legal hold, and a self-serve sign-up request that was never confirmed and that we suspended, whose details are still deleted 90 days after the suspension unless it is under a legal hold. When a suspension or hold ends, normal retention resumes, each erasure it held waiting its own period again from that day (30 days for a deleted workspace, a few days for its trash, and, after a legal hold ends, 30 days for one being erased after termination). While a hold or suspension stands, trash purges and person erasures asked for inside the workspace wait too; otherwise a hold changes nothing: what members delete still leaves their view, a kept assistant conversation a member deletes is still deleted, and records with their own retention periods go on expiring unless we keep a copy. The full inventory, with a retention period per data type, is published at /privacy.
What do you hold about the people in our workspace?
A sign-in email, an optional name, a salted password hash, and a role and membership. Only if a person adds them: a profile picture and a timezone. And what the product records as they use it: their sign-ins (with the browser's user-agent string, which names the browser, its version, the operating system and the type of device), their actions in the audit log, their notifications, pins and preferences, the record of each time they accepted our terms (kept with the workspace until it is erased), a private list of what they opened (90 days) and, where kept, their assistant conversations (until 90 days after the last exchange). A picture is shown only to signed-in people in the workspaces that person belongs to — never on a share link, a portal or a read-only project link — and replacing or removing it deletes every stored copy. A confirmed change of sign-in email is kept as history for as long as the account exists, so an address given up cannot be claimed by someone else and the person's earlier activity stays theirs. An owner can erase anyone from the workspace except its last owner, and an admin can erase members and viewers (except while the workspace is suspended or held, or in the few days after that ends, when they can still be removed): their account goes unless they belong to another workspace, and what was theirs alone in the workspace goes with it, but names typed into text (such as a card's Owner) are not changed, audit entries stay for their 400 days, and backups age out on their own schedule. The full inventory, with where each item lives and how long it is kept, is at /privacy.
Who at Profusia can see our 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.
Does customer content execute on your servers?
Never. 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, 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 link-preview title, the address of its live data) and, for a new unverified workspace, a notice for readers. 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 the workspace's 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. A page's code cannot read another customer's workspace: each workspace is served from its own address.
Is there an uptime commitment or a status page?
No. We do not offer a service-level agreement or a status page yet. Our automated checks run in Chromium. Profusia is run by one operator, who answers support@profusia.ai directly.
How do we report a vulnerability?
Write to security@profusia.ai; the contact is also published at /.well-known/security.txt (RFC 9116). Reports are answered directly by the operator. We do not pay bounties. Section 4.3 of the Acceptable Use Policy (/legal/acceptable-use) is our vulnerability disclosure policy, and governs where the rules here and on /trust say 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; do not degrade the service, and do not attempt social engineering or physical testing; report promptly and give us a reasonable time to fix it (we suggest 90 days) before disclosing; 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 over it; that authorization binds only us.
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 — apart from your workspace’s name, colours and logo, and the address of a live page’s data table, both described on /trust. Every credential is stored hashed, except that data table’s address, which is itself the key that reads the table and is revoked by rotating it.
- 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 by us.
- To an assistant you connect: what Profusia returns to it leaves Profusia and is held by that assistant’s vendor under your own terms with it.
- To your Google Drive — only if an owner connects sync: each night, copies of the chosen projects and documents are written into the folder the owner chose, including each card’s recent comments with their authors and who last changed it (and, if chosen, a daily brief: a dated journal of the last two weeks’ changes and comments, naming who made each one, and what is waiting on the workspace’s owner).
- By email, through Resend: a notification only where an administrator has turned email on and the person has not turned it off (its title, up to 240 characters of the message, a link and the workspace’s name); and, whenever one is needed, the account, invitation, password-reset, sign-up confirmation, renewal-reminder and unused-workspace warning messages listed below.
- To Paddle — only when a customer buys a plan: the workspace’s address, an internal reference and the number of seats; the buyer gives their billing, payment and tax details to Paddle directly.
- To Uiia — on profusia.ai/help only: a visitor’s IP address and browser details when the page loads, and any question typed into its help assistant; Profusia sends it no workspace content.
- To AI providers — only if used: when a signed-in member uses an in-app AI feature, what that feature needs is sent to an AI model; nothing runs on its own schedule. In a customer workspace, on a plan that includes in-app AI, that model is Anthropic’s Claude, which does not train on what it is sent (Cloudflare Workers AI is listed too, and receives nothing until we connect it; Amazon Bedrock is listed too, and receives a workspace’s content only where someone picks one of its models or we place one in a feature’s order). Details below.
AI-use disclosure
The provider table below lists the AI providers that receive customer workspace content; its tiers, training terms and models come from the same model registry the product routes on.
When does customer content reach an AI model?
Customer content is never sent to an AI provider tier that may train on it. The in-app AI features that read workspace content are: Ask a document; Discuss a site, space, project or card; the Navigator’s ask; Draft (a project from a brief) and Break it down; Say what you did; filing proposals (where documents belong); Propose a turn; Set this page; the two plan checks; and Build. On profusia.ai they 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 a customer workspace’s content goes by default only to Anthropic’s Claude (paid API), which does not train on what it is sent (Cloudflare Workers AI is listed too, and receives nothing until we connect it; Amazon Bedrock is listed too, 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 — its models run inside Amazon Web Services in the United States, and the company that made a model does not receive the request); the routing leaves every provider we do not list out of the request, and, Amazon Bedrock apart, we do not pin the country in which a provider processes a request: each processes it on its own infrastructure. Each person may have one in-app AI request in progress at a time, so one person’s burst of requests cannot all pass the same spending check. Every request that carries a workspace’s content passes a check on each provider: the routing leaves out each provider tier that may train on what it is sent unless the workspace is Profusia’s own, and refuses the request if no other provider can answer, never sending it to a tier that trains to get around that (filing proposals and Set this page then use counted rules with no model, and Propose a turn leaves its manual form). Neither provider can hear a spoken question, so spoken questions are not offered in a customer workspace. Profusia’s own workspace keeps the free tiers accepted for its own documents, where every affected screen says so; no customer workspace is opted in to a tier that trains (which workspace is covered is a setting in our own configuration that only our operator can change), and a customer has no way to opt itself in. Each feature sends only the content it needs, to one provider at a time, and if that provider fails the request goes to the next in our configured order. One AI feature reads no workspace content: Profusia’s help assistant (the question box on /help at a workspace’s address, the “Ask about Profusia” assistant in Workspace settings and on All sites, and Uiia on profusia.ai/help). It answers anyone, but only from Profusia’s own published help, and what you type there — your question and the conversation so far — may go to a provider tier that keeps it and uses it to improve its models, so do not type anything confidential into it.
What is stored about AI use?
Where the in-app features run, a member’s own conversations with the assistant are kept for that member until 90 days after the last exchange, so they can pick one up again; the member can delete any of them at any time, and a workspace’s owner can switch the keeping off. No screen in the product shows them to anyone else, and Profusia opens them only at that member’s request or on the other grounds given under “Who at Profusia can see our data?” above. No recording of a spoken question is kept; where conversations are kept, the words the assistant heard are kept as the question. A per-call ledger is kept for billing honesty: who asked, which document or card, which model answered, token counts and cost — retained 90 days; it never holds the question or the answer. The workspace’s audit trail also records each request (who asked, about what, which model answered, and whether the question was spoken — never the words), kept for its 400 days and exportable by the workspace’s owners and admins. We have no zero-data-retention agreement with any AI provider; each keeps what it receives under its own terms.
Can the models act on our workspace?
Profusia’s own in-app models, no: they hold no tools. They read the content they are handed and return text, so a document containing hostile instructions cannot make them act. It can still influence what they write, so read an answer, and anything Build proposes, before you rely on it or accept it. An assistant you connect (Claude, ChatGPT) is different by design: it acts through Profusia’s tools with the access you approved, so it can publish, share and organise. Each person can connect their own assistant; it acts as that person — their role, what they may see and the workspace’s sharing switch — checked again on every request, and removing the person disconnects it. A workspace access key, which an owner issues, connects as the whole workspace and is not limited by roles, as does a connection approved by pasting that key. Either way, what it does is the customer’s act under our Terms of Service, including acts prompted by instructions it read in a document, comment, page or dataset. Profusia’s operator also holds a platform key, which opens the operator console as the operator’s own sign-in does; its acts there are recorded as the operator’s own are (see “Who at Profusia can see our data?”).
Can we turn it off, or control what it costs?
Yes. AI is an entitlement per workspace — a deployment can leave it off entirely, an owner or admin can switch off every model for the workspace (and, on plans with groups, for a group or a person), and every workspace's spend is hard-capped per day on top of request-rate limits; when an allowance is spent, AI stops rather than bills. We do not offer bring-your-own-key: Profusia never asks for or stores your AI provider's key. If you want AI work to run under your own agreement with a provider, connect your own assistant (Claude, ChatGPT) over MCP instead — it works through Profusia's tools with the access you approve, your content reaches that provider under your account with them, and Profusia holds no credential of theirs.
| Provider | Catalogued models | Tier | When it answers a customer workspace | May it train on what it is sent? | Where |
|---|---|---|---|---|---|
| Anthropic (Claude) | Claude Haiku 5.5, Claude Sonnet 5.5, Claude Opus 5.5, Claude Fable 5.1 | Paid API | By default, whenever someone in a workspace whose plan includes in-app AI uses a feature that reads its content | No, under its published terms (we rely on those terms; we cannot check them ourselves) | Not pinned to one country: Anthropic processes a request on its own infrastructure |
| Cloudflare Workers AI | Llama 3.1 8B | Free allowance, then paid | Not connected today, so it receives nothing. Once we connect it: only when someone picks one of its models, or when we place it in the order a feature uses | No, under its published terms (we rely on those terms; we cannot check them ourselves) | Not pinned to one country: Cloudflare's global network |
| Amazon Bedrock | Mistral Large 3, DeepSeek V3.2, Qwen3 Coder Next, Kimi K3.1 Pro | Paid API | Never by default. Only when someone picks one of its models, or when we place one in the order a feature uses; until then it receives nothing. Its models were made by other companies and run inside Amazon Web Services: the company that made a model does not receive the request | No, under its published terms (we rely on those terms; we cannot check them ourselves) | United States: we call it in Amazon Web Services' US Regions |
Which of these answers, and in what order, is set by our operator; we send customer workspace content to no other AI provider, and before another one begins to receive it we list it here and on /privacy and email workspace owners at least 30 days ahead. Other AI providers, including free tiers that may train on what they are sent, answer the public help assistant and our company’s own internal workspace; none of them receives customer workspace content. The same list is on /privacy.
Subprocessors and other outside services (last changed 2026-11-11)
These are all the outside services that receive personal data from Profusia itself, together with our own systems that do, and whether each receives workspace content today. Our own two, Uiia and Evadaroo HQ, run on outside hosting of their own (and, for Uiia, outside AI model providers); we name those providers on request. The AI providers are in the table above.
| Who | Role | What for, and what it receives | Where | Workspace content today? | Its terms |
|---|---|---|---|---|---|
| Cloudflare, Inc. | Sub-processor | All hosting: the application, file storage, the database and its backups, DNS and delivery. It sees everything stored in Profusia and the IP address of every request. At self-serve sign-up we also ask its public DNS service whether an email address’s domain can receive mail (the domain only, never the address). It also adds the analytics tag described below. | US company; global network; storage locations chosen by Cloudflare and not pinned to a region | Yes | Terms |
| Resend (Plus Five Five, Inc.) | Sub-processor | Delivers the email Profusia sends: a notification that somebody mentioned you or named you a card’s owner (the address, the title, up to 240 characters of the message, and a link); the messages a change of sign-in email or a password reset needs; an invitation a person makes (the address, the workspace’s name, the role and the link); a warning to a workspace’s owners before an unused workspace is erased; a reminder to a workspace’s owners before a yearly plan renews (the workspace’s name, the plan, the date and time it renews, the amount Paddle will charge where Paddle states it, otherwise the price in force for the plan and seats, and how to cancel); a notice to the owners of a workspace that is already paying when the price of its plan is going up (the workspace’s name, the plan, the price now and the new price, the date it reaches the subscription, and how to cancel); a notice to the owners of a workspace that is already paying when a feature is taken off its plan (the workspace’s name, the plan, the features it keeps and the date it keeps them until); and — where self-serve sign-up is open — the one confirmation link a new workspace needs, carrying no words the requester typed (at most 15 a day and 250 a month). | US | A small part: the title and up to 240 characters of a message, in a notification | Terms |
| Google LLC — Google Workspace | Sub-processor | Our company email (legal@, support@, billing@, security@ and hello@profusia.ai, and notifications@profusia.ai, the address the Service’s email comes from): what you send us, including any reply to an email the Service sent you, and our replies. | US | Only what someone chooses to email us | Terms |
| Paddle (Paddle.com Market Limited and its affiliates) | Independent controller; our reseller and Merchant of Record | Payment for paid plans, which are not on sale yet. You give your billing contact, payment and tax details to Paddle on its own checkout; payment details go to Paddle, never to us. We tell Paddle which workspace a purchase is for (its address and an internal reference) and how many seats. | UK and US | No | Terms |
| Uiia (uiia.app) | A separate product of our own company; not a sub-processor of workspace data | The help assistant on profusia.ai/help. Its script loads with that page, so Uiia receives your IP address and browser details when you open it, and any question you type there. It answers with outside AI model providers, some of which may keep what they are sent and use it to improve their models. It never loads on a workspace’s own address. We have not yet published how long Uiia keeps what it receives; ask legal@profusia.ai. | Run by our company, on outside hosting of its own | No | — |
| Evadaroo HQ | Our company’s own internal operations console | Reads the account, plan and usage records the operator console shows (workspaces, members’ names and email addresses, roles and usage), and can take the same recorded operator 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. | Run by our company, on outside hosting of its own | No document content | — |
| Anthropic, PBC — Claude Code | Development tool | The AI coding tool we build and deploy Profusia with, running on Anthropic’s systems. The credential it deploys with can also read production data; a written rule forbids it to read workspace content. | US | Not permitted (a written rule, not a technical block) | Terms |
| Clerk, Inc. | Sub-processor, if switched on | Would handle sign-up, email verification, invitation email and password reset, seeing your email address and sign-in details. Not switched on; it receives nothing. | US | No | Terms |
There is no error-tracking service and no advertising or analytics vendor of ours; our host, Cloudflare, 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. We add a new subprocessor here, with the date, at least 30 days before it starts handling workspace content, and we email workspace owners when we do — except where an urgent replacement is needed to keep the service secure or running, when we tell you as soon as we can. The AI providers above are engaged when members use AI features where those run; the public help assistant is answered usually by other AI providers, free tiers among them, which receive only what is typed into it. Paddle (Paddle.com Market Limited and its affiliates) is our reseller and Merchant of Record for paid plans, engaged only when a customer buys a plan — live selling is not yet switched on. It processes billing contact, payment and tax details as an independent controller under its own privacy notice; payment details go to Paddle, never to us, and it receives no workspace content, only the workspace’s address, an internal reference and the number of seats. The help assistant on profusia.ai/help is Uiia, a separate product of the same company, which receives each visitor’s IP address and browser details when the page loads, and any question typed there (both named at /privacy). Email delivery was added on 2026-09-18 and is the only way the product sends messages to people: a notification is emailed only where the workspace’s administrator has turned email on and the person has not turned it off, and its notifications are of two kinds (that somebody mentioned you, or named you a card's owner). The only other messages are the account messages a change of sign-in email needs (a confirmation link to the new address, a notice to the old address when the change is asked for, and another, with a link to undo it for seven days, when it is done), an invitation to join a workspace, sent once to the address it was made for and only when a person (not an assistant) made it (fixed wording around the workspace's name and the role, at most fifteen a day across the deployment and twelve from any one workspace), a password reset link someone asked for on the sign-in page, sent only to the address an account already signs in with (at most five a day across the deployment), followed by a notice when the password is changed, and — only where a deployment has opened self-serve sign-up — the one confirmation a new workspace needs, sent to the address it was asked for: one link and no words the requester typed, at most 15 a day and 250 a month across the deployment, inside the room account, invitation and reset mail share. Before a yearly plan renews, a workspace’s owners are emailed one reminder each (the workspace’s name, the plan, the date and time it renews, the amount Paddle will charge where Paddle states it, otherwise the price in force for the plan and seats, and how to cancel), normally between 45 and 15 days before and never later than 7 days before, at most 5 a day across the deployment, counted inside the invitations’ fifteen. When the price of a plan is going up, the owners of each workspace already paying on it are emailed a notice (the workspace’s name, the plan, the price now and the new price, the date it reaches the subscription and how to cancel), and when a feature is taken off a plan, the owners of each workspace already paying on it are emailed one notice listing what it keeps and until when (the workspace’s name, the plan, the features and the date) — the two kinds of plan change notice share five a day, counted in the same fifteen. Where we can send it, a workspace’s owners are also emailed a warning before an unused workspace is erased. A new version of a document you follow is shown in the app and is not emailed. Nothing is pushed to a device, and there is no marketing mail.
Incident response, and the DPA question
Incident response
What exists: a published security contact (RFC 9116), an append-only audit trail, a written incident-response policy (severities, the containment acts the product already has — revoke one link, lock a whole site, rotate a key, disconnect an assistant, make a workspace dormant — the evidence to preserve, and how affected customers are told), and an operator who answers directly. If we confirm a security breach affecting your data, we tell the workspace’s owners by email, with what we know at the time and updates as we learn more. Our Data Processing Addendum’s Section 3.7 is the binding commitment, including its timing. This page restates no deadline of its own. What does not exist yet: a tabletop exercise of that plan, an on-call rotation, or external alerting — one operator answers, so nothing alerts automatically and problems are found through the operator’s own checks and reports.
Data processing agreement
A standard DPA is published at /legal/dpa — GDPR Article 28 terms, the EU Standard Contractual Clauses and UK Addendum by reference, California service-provider terms, a security annex, a dated subprocessor annex, and breach notice. It has been in force since 12 November 2026 as part of the agreement a customer accepts with our Terms of Service, so the Terms’ limitation of liability applies to it; ask us if you need a copy signed by both of us. We do not sign other parties’ data-processing forms without legal review.
Why there is no SOC 2 report
None is in progress — deliberately. The technical controls above are built, real, and tested on every release; 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.