Security
Your data stays yours.
Connecting Patricia to your clients' accounts is a real decision, and it deserves a real answer. Here is exactly what she can see, who at our end can reach it, and what she is allowed to do without asking you first.
Reports and audit documentation live in the BetterGroup Trust Center. BetterGroup is Patricia's parent company, and it runs compliance for every product in the group.
The short version
Three questions, answered before you ask them.
An agency runs ten clients out of one workspace. That makes the security question concrete rather than theoretical, so these are the three answers that matter.
What she can see
Who can reach it
What she can do alone
Isolation and storage
One client cannot bleed into another.
Isolation is not a setting you switch on. It is how the data layer is built, and it fails closed.
Every query is bound to one account
Stored in the US, encrypted throughout
Her memory is per-account too
Untrusted code runs in a sandbox
Access
Who can reach your data, on both sides.
On your side, roles you control. On ours, need-to-know and a log that cannot be rewritten.
| Role | What it can do |
|---|---|
| Owner | Everything, including billing, spend caps, and the team |
| Admin | Runs, integrations, settings, audit log. Approves high-risk work |
| Member | Runs and memory. Approves medium-risk work |
| Viewer | Read only. Cannot change or approve anything |
The honest answer about our own access
A small number of authorized Patricia staff can reach customer data on a need-to-know basis, to run and support the service. That is what makes it possible to debug the run you told us broke. They are bound by confidentiality obligations, the access is scoped to the job at hand, and it lands in the audit log like everything else. Any vendor telling you that nobody on their side can ever see your data is either doing client-side encryption, which Patricia is not, or is not being straight with you.
Security-relevant events, hers and ours, are written to an append-only audit log enforced at the database layer. It cannot be edited or deleted through the application. Who, what, when, and on whose approval.
Approvals
She cannot act on anything that matters without a named yes.
Every action she can take carries a risk tier. The low tiers run on their own. The rest stop and wait for a person you have chosen.
| Tier | For example | What happens |
|---|---|---|
| Read only | List a channel, open a file, pull yesterday's ad spend | Runs on her own |
| Low | Reply in the thread she was asked in, draft a doc | Runs on her own |
| Medium | Send an external email, post to a client-visible channel | Waits for approval |
| High | Change an integration, delete data | Waits for an admin or owner |
| Critical | Spend past your cap, change billing | Waits for the owner, and cannot be waived |
An approval is bound to one exact action
Approval sits where the work does
Connected tools
She borrows the keys. She never holds them.
Connecting Google Ads or a CRM hands Patricia an OAuth grant. Here is what happens to it.
Credentials never reach the model
Scoped to what you granted
Logged, and cut off in one click
Every provider that processes data on your behalf, what it does, and where it runs is listed on the subprocessors page. We give at least 14 days' notice before adding or replacing one, and you can object.
AI and your data
Your work does not become someone else's model.
No training on your data
What she learns, she learns for you
The model providers are named on the subprocessors page, and the commitment is contractual rather than a promise on a marketing page: it is written into section 2.4 of the DPA.
Retention and deletion
It leaves when you leave.
The full windows are in the Privacy Policy. The short version:
| Cached conversations and quality records | Deleted on the window you pick in the dashboard: 90 days, 1 year (where you start), or unlimited. A scheduled maintenance job enforces it, with no promised interval between runs; anything past your window is deleted on request if it is not running. Quality records are capped at 1 year even on unlimited |
| Briefs, files, and work she produces for you | Kept while your account is open, so you can pull up past work. Deleted on request, at any time |
| Brand memory | For as long as the account is active |
| Account data | Deleted or returned within 30 days of a deletion request, keeping only what the law requires us to keep |
| On cancellation | Deleted or returned within 30 days. The audit log stays as an integrity record: who did what, not your content |
Deletion, access, and other requests about the data we hold as controller, meaning your account, billing, and website data, go to privacy@patricia.app and are handled by our team within the windows in the Privacy Policy. We have appointed EU and UK representatives, and both are named there. A request about personal data inside your own workspace goes to you, because there you are the controller and we are the processor. If a data subject writes to us instead, we refer them to you or forward the request, and we help you answer it, as set out in section 5.1 of the DPA.
Compliance
Audited, and honest about the rest.
Two lists: what has been independently checked, and what we have not built yet. A vendor that only shows you the first one is showing you half of it.
What we have not built yet
Row-level security in the database
Isolation is enforced today in the data-access layer, where every query is bound to one account and an unscoped one fails closed rather than returning data. Database-level policies are a second wall behind that, and they are on the roadmap.
SSO, SAML, and SCIM provisioning
Roles are managed in the dashboard today. Enterprise single sign-on is planned.
Self-service export and bulk erasure
Deletion and data-subject requests are handled by our team, on request, within the windows in the Privacy Policy. There is no self-service button for it yet.
Automatic cleanup for every data type
You can already pick your retention window in the dashboard, under Settings, then Data & Privacy: 90 days, 1 year, or unlimited, and a scheduled maintenance job enforces it. We do not promise a fixed interval between its runs, and if it is not running, anything past your window is deleted on request instead. Today that setting covers cached conversations and quality records. Briefs, deliverables, and brand memory are kept while the account is open and deleted on request, by hand. Bringing the rest under the same setting is on the roadmap.
If one of these is a hard requirement for your agency or for your client, tell us. It changes the conversation, not the answer.
Responsible disclosure
Found something? Tell us first.
Email ricardo@patricia.app with what you found and how to reproduce it. We acknowledge reports within two business days and keep you posted until it is fixed. We are most interested in isolation bypasses, authentication and authorization flaws, and anything that exposes a credential.
We do not run a paid bounty today, and we will credit you if you want the credit. Please do not touch another customer's data while testing. Report it, and we will take it from there.
FAQ
The questions security teams actually send.
Can Patricia read everything in our Slack?
No. She sees the channels you add her to and the messages directed at her. She is not a workspace-wide crawler, and you choose exactly which channels she can read.
Can one client's data reach another client's work?
No. Every record carries the account it belongs to, and every query she runs is bound to a single account in the data-access layer. A query that is not correctly scoped returns nothing rather than the wrong account's data, and tests that run two accounts side by side guard it on every change.
Can anyone at Patricia read our data?
A small number of authorized staff can, on a need-to-know basis, and only to run and support the service, for example to debug a failed run you have reported. They are bound by confidentiality obligations, and the access is written to the same append-only audit log as everything else. Any vendor telling you nobody on their side can ever reach your data is either running client-side encryption or is not being straight with you.
Do you train AI models on our data?
No. We use our model providers on API terms under which inputs and outputs are not used to train their models, and we never use your data to train or improve any model served to another customer. What Patricia learns from your feedback stays inside your account and is never pooled across customers. The commitment is in section 2.4 of the DPA, not just on a marketing page.
Where is our data stored?
Primary storage is in the United States, in the US East (Virginia) region, alongside the model providers named on the subprocessors page. Everything is encrypted in transit and at rest, and EU, UK, and Swiss transfers are covered by the Standard Contractual Clauses in the DPA. Stored is not the same as processed, and the subprocessors page states both for every provider: our monitoring runs and stores in the European Union, and image and video generation runs on GPU nodes in the United States and sometimes in the European Union. What those providers produce comes back and is stored in the United States with the rest of your data.
What happens if one of our OAuth tokens leaks?
Credentials are encrypted with AES-256-GCM and held server-side. Patricia asks the integration gateway to act; the raw token is never placed in a prompt, so it cannot be leaked back out through one. Every use is in the audit log, so an unexpected action is visible, and disconnecting the integration in the dashboard cuts off her access.
Can she post to a client-visible channel on her own?
No. That is a medium-risk action, so it waits for a named yes from someone on your team whose role allows it. The approval is bound to that exact action, so it cannot be reused for a different one.
What is your breach process?
For data we process on your behalf, notice goes to you, not a regulator: without undue delay after we become aware of a breach affecting your data, with what we know, what we are doing about it, and what you need for your own filing. Under GDPR Article 33 the 72-hour clock to a supervisory authority belongs to the controller, which for workspace data is you. For data we hold as controller, our own account and website data, we make that 72-hour filing ourselves where the breach is reportable. The commitments are in the DPA and the Privacy Policy. Section 9 of the Privacy Policy states our filing obligation more broadly than this split does, and it is the one that governs: nothing here narrows it.
Can we get a DPA and a SOC 2 report?
Yes to both. The DPA is published in full and covers the EU Standard Contractual Clauses, the UK Addendum, and Swiss FADP terms; email access@patricia.app for a countersigned copy. The SOC 2 Type II report and the rest of the audit documentation are available through the BetterGroup Trust Center.
What happens to our data if we cancel?
It leaves with you. We delete or return your data, account records included, within 30 days of the request, keeping only what the law requires us to keep. Our team does this on request; there is no self-service button for it yet. The append-only audit log is kept as an integrity record; it holds who did what and when, not the substance of your content.
Bring your security questions.
The hard ones are the ones we like. Book a demo and we will walk your team, or your client's team, through any of this.