Draft — pending legal review. Not yet binding.
This document was written by the Pronoia engineering team to describe honestly what the product actually does today. It has not been reviewed by a lawyer, and it is not a contract. Items shown in brackets and marked TBD are still unresolved.
Privacy Policy
Last updated July 28, 2026
This explains what Pronoia collects, how connected-account credentials are actually stored, who else touches your data, and how to get it out or deleted. We have tried to describe the real system rather than an idealized one, including the parts that are not finished.
1. Scope
This policy covers pronoid.ai and the Pronoia product, operated by [LEGAL ENTITY NAME — TBD] at [COMPANY ADDRESS — TBD]. It applies to account holders, people invited into a workspace, and visitors to our site.
2. What we collect
Most of what Pronoia holds is business data about your products and your sales, not personal data. But some personal data is unavoidable, and connected-account credentials are the most sensitive thing we touch.
- Sales and distribution data pulled from the accounts you connect — units, dollars, locations, time periods, and similar facts about how your products are selling.
- Files you upload, and files that arrive as email attachments.
- Email sent to your workspace ingestion address, including the sender, subject, body, and attachments. We keep the original message as it arrived.
- Credentials for the sources you connect, plus the record of your authorization to use them.
- Account details: your email address, name, and workspace membership.
- Messages and knowledge you or your teammates put into the product.
- Usage and diagnostic data: pages viewed, actions taken, approximate location from IP address, browser type, and automatically captured browser errors.
3. How connected-account credentials are stored
This is the part most people want to know about, so here is the actual design rather than a summary.
- Credentials are encrypted with AES-256-GCM, with a unique random nonce and an authentication tag for every stored record.
- The vault database holds only encrypted values. There is no column that stores a credential in the clear.
- The encryption key is held by the server through environment configuration. It is never stored in the database alongside the data it protects.
- Reading or changing a credential requires a short-lived, workspace-scoped token, and the requester's owner or admin status is re-checked on every single request. Removing someone's access takes effect immediately.
- Software agents never receive a credential value. They receive a reference — an identifier only. When a login is needed, the server retrieves the value and enters it into the page directly. The value is not returned to the agent and never enters the AI model's context.
- Every create, rotate, assign, revoke, delivery, reveal, and deletion is written to an audit table with the action, the actor, the result, and the timestamp.
4. The limits of that — what we are not claiming
We would rather tell you the edges than let you assume something stronger.
- One encryption key protects all stored credentials. There is not a separate key per customer, so the separation between customers is enforced by the application, not by cryptography.
- If you attach a credential to an agent's environment, or have us deliver it to a server or repository you run, the value exists in plain form in that destination. That is the point of delivering it, but it means the vault is no longer the only copy.
- When you delete a credential, we remove it from our vault and make a best-effort attempt to remove it from anywhere we delivered it. We cannot guarantee removal from a system we do not operate. Rotate the credential at the source if that matters to you.
- During an automated login the credential is entered into a browser session. When that browser runs on a third-party provider (see section 8), the value reaches that provider's infrastructure. It bypasses the AI model, not the provider.
- We do not hold a SOC 2 report, and we are not claiming GDPR, CCPA, HIPAA, or PCI compliance. [COMPLIANCE POSTURE — TBD]
5. Email we receive
Mail sent to your workspace address is stored exactly as it arrived, before we decide what to do with it. That includes messages we end up rejecting or holding — for example mail that failed sender authentication, or mail from a sender you have not approved.
We do this so that a message is never silently lost and so we can show you what actually arrived. It does mean we hold third-party email content, including from senders you never approved.
Automatic deletion of these stored messages is not implemented yet. Nothing expires them on a schedule today. See section 9.
6. Your workspace is walled off from every other customer
One customer's data is never exposed to another. Every query is scoped to a single workspace. Access tokens are issued for one workspace, expire quickly, and are re-checked against your current membership on each request. A request carrying one workspace's token cannot read another workspace's data, and there is no parameter a caller can set to change which workspace it is asking about.
Your data is not pooled with another customer's, and we do not build cross-customer benchmarks out of it.
7. How we use what we collect
To run the product for you: retrieve and organize your data, let agents work on it, authenticate you, send login codes and service notices, and support you when you ask.
To keep it working and safe: diagnose failures, investigate abuse, and measure whether features are usable.
We do not sell your personal information.
8. Companies that process data for us
Running Pronoia means some of your data passes through other companies. These are the ones we can confirm from our own code. This list is not final and will be reviewed before it is relied on. [SUBPROCESSOR LIST — PENDING REVIEW / TBD]
- AI model providers — run the agents and generate the text embeddings that make your data searchable. Content you give an agent is sent to the model provider configured for your workspace. Pronoia Cloud currently runs Anthropic's Claude for agent work and OpenAI for embeddings and small utility tasks. [MODEL PROVIDER DATA-USE AND RETENTION TERMS — TBD]
- Browserbase — runs the remote browser used for automated portal logins, when that backend is enabled.
- Decodo — a residential network proxy, used only when a request is explicitly marked to route through it.
- Nango — holds the OAuth tokens for connected apps and proxies calls to those providers.
- Pipedream — powers connections to third-party business apps.
- Resend — sends our outbound email and receives the inbound mail sent to your ingestion address.
- PostHog — product analytics and automatic capture of browser errors.
- Amazon Web Services — file storage and delivery, where configured.
- Vultr — hosts the servers and the database. The database is run by us on that infrastructure, not by a managed database vendor.
- Google — sign-in, if you use it, and reading a Google Sheet if you connect one.
- fal.ai and Google — image generation, if you use the brand image features.
9. How long we keep things
Honest answer: there is no automatic deletion yet. We do not currently expire stored data on a schedule, and that includes the original copies of email sent to your ingestion address.
Setting real retention periods is outstanding work, and it needs to be settled before this policy is final. [RETENTION PERIODS — TBD]
What does exist today: you can delete content and credentials yourself, and we will delete a workspace and its data when you ask us to.
10. Getting your data out, or deleted
Write to [PRIVACY CONTACT EMAIL — TBD] to ask for a copy of your data or to have it deleted. We may need to confirm who you are first.
Today both are handled by a person rather than a self-serve button. [EXPORT AND DELETION PROCESS AND TIMELINE — TBD]
Depending on where you live you may have further rights over your personal information — to see it, correct it, or object to how it is used. [APPLICABLE PRIVACY LAWS AND RIGHTS — TBD]
11. Security
Beyond the credential handling in section 3, we scope access by workspace, expire access tokens quickly, re-check permissions on every request, and restrict where our automated browser is allowed to connect so it cannot be pointed at internal systems.
No system is perfectly secure. If you think something is wrong, tell us at [SECURITY CONTACT EMAIL — TBD]. Our process and timeline for notifying you about a breach is not settled. [BREACH NOTIFICATION PROCESS — TBD]
12. Where data is processed
Your data is processed in the United States and anywhere our providers in section 8 operate. [INTERNATIONAL TRANSFER MECHANISM — TBD]
13. Children
Pronoia is a business product and is not intended for children. We do not knowingly collect personal information from anyone under 16.
14. Changes
We will post updates here with a new date. While this document is marked as a draft, expect it to change.
15. Contact
Privacy questions or requests: [PRIVACY CONTACT EMAIL — TBD].
Related: Terms of Service · Privacy Policy