Legal
Security Commitments
Version 1.0 · Last updated on August 2, 2026
This page states the security posture behind Patricia as a set of commitments, for reviewers who need it in the same place as the Data Processing Agreement and the Privacy Policy. For the same posture explained in plain prose, with the reasoning and the questions security teams actually send, read patricia.app/security.
Every control below is one the product runs today. Work that is planned but not built is named in its own section rather than implied here. Where a commitment is contractual, it is in the DPA and this page points at it.
This page describes; the DPA governs. It is not incorporated into the Terms of Service, and where anything here reads differently from the DPA or the Privacy Policy, those documents win.
1. Certifications and audits
Patricia is operated by BETTERGROUP HOLDING INC. The group holds the following, and this page claims nothing beyond them:
The audit reports and the supporting documentation are available through the BetterGroup Trust Center. To request a copy or a countersigned DPA, email access@patricia.app.
2. The controls we run
Each entry is a control in production today. It is not the same list as Annex II of the DPA. Annex II is the shorter, contractual statement of our technical and organisational measures, and it carries measures this table does not, such as secrets management and secure development. Where the two read differently, Annex II governs.
| Area | Commitment | What it means |
|---|---|---|
| Isolation | Every query is bound to one account | Each record carries the account it belongs to, and the data-access layer scopes every read and write to a single account by construction. A query that is not correctly scoped returns nothing rather than someone else's data. Tests that run two accounts side by side guard it on every change. |
| Storage | Stored in the US, encrypted throughout | Primary storage is in the United States, US East (Virginia) region. Traffic is TLS-encrypted with HSTS. Credentials and connected-tool secrets are encrypted at the application layer with AES-256-GCM, on top of the encryption at rest the infrastructure already provides. |
| Memory | Her memory is per-account too | Patricia builds a working memory of a brand, its voice, and its standards. That memory belongs to that account, is encrypted at rest, and is never pooled with another customer's. |
| Code execution | Untrusted code runs in a sandbox | When a task needs to execute code, it runs in a per-run sandbox that is thrown away afterwards. It cannot reach the database or the secrets, and it cannot call out to the internet unless the task is allowed to. |
| Audit | An append-only log, enforced at the database | 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 | An approval is bound to one exact action | The request carries a fingerprint of the action it approves, who is allowed to approve it, and an expiry. Approve a draft and she sends that draft. The same yes cannot be replayed against a different action, reused after it expires, or accepted from someone whose role does not allow it. |
| Integrations | Credentials never reach the model | Tokens are held server-side and encrypted with AES-256-GCM. Patricia asks the integration gateway to perform an action; the raw credential is never placed in a prompt, so it cannot be leaked back out through one. |
| Integrations | Scoped to what you granted, and cut off in one click | She can only do what the grant allows. A read scope stays a read scope, and writing to a connected tool is gated behind an approval on top of that. Every use is in the audit log, and disconnecting the integration in the dashboard ends her access. |
| AI | No training on your data | We use our model providers on API terms under which inputs and outputs are not used to train their models. We do not use your data to train or improve any model served to another customer, and we do not sell it or share it. The commitment is written into section 2.4 of the DPA. |
| AI | What she learns, she learns for you | Patricia gets sharper on your accounts from your feedback and your corrections. That learning stays inside your account. It is never pooled into a shared model, so your standards do not end up improving a competitor's output. |
| Subprocessors | Named, with notice before they change | 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. |
| Our own access | Need-to-know, and logged like everything else | A small number of authorized Patricia staff can reach customer data on a need-to-know basis, to run and support the service. They are bound by confidentiality obligations, the access is scoped to the job at hand, and it lands in the audit log. 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. |
3. Where your data lives
Primary storage is in the United States, in the US East (Virginia) region. Traffic is encrypted in transit and data is encrypted at rest. Transfers from the EU, the UK, and Switzerland are covered by the Standard Contractual Clauses incorporated in the DPA, with the UK Addendum and the Swiss adaptation as applicable.
4. Retention and deletion
The full windows and their legal basis 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 |
Two kinds of request, two routes. A request about the data we hold as controller, meaning your account, billing, and website data, goes to privacy@patricia.app and is handled within the windows in the Privacy Policy. Our EU and UK representatives are named there.
A request about personal data inside a customer workspace is different. There the customer is the controller and we are the processor, so the request goes to them. If a data subject writes to us instead, we refer them to the customer or forward the request, and we help the customer answer it. That split is section 5.1 of the DPA, and this page does not change it.
5. Subprocessors
Every provider that processes personal data on your behalf, what it does, and where it runs is listed on the subprocessors page. Each is bound by a data processing agreement. We give at least 14 days' advance notice before adding or replacing one, and you can object on data-protection grounds. To subscribe to change notices, email access@patricia.app.
6. Incidents and breach notification
For data we process on your behalf, we notify you, not a regulator. We tell you without undue delay after becoming aware of a breach affecting your data, with what we know at the time and what we are doing about it, and we give you the information you need to make your own filing. Under GDPR Article 33 the 72-hour clock to a supervisory authority is the controller's, which for workspace data is you. That is section 7 of the DPA.
For data we hold as controller, meaning our own account and website data, we notify the competent supervisory authority within 72 hours where the breach is reportable. Section 9 of the Privacy Policy states that filing obligation in broader terms than the split above, and where the two read differently the Privacy Policy governs.
7. What you are responsible for
Security here is shared. We secure the Service; you control what it can reach. That means:
- Which channels you invite Patricia into, and which tools you connect.
- The scopes you grant a connected tool, and when you disconnect it.
- Who holds each role in your account, and therefore who can approve what.
- Keeping sign-in credentials safe, and telling us at access@patricia.app if you think an account has been reached without permission. That is the mailbox section 3 of the Termsgives, and it is a role address rather than one person's, so it survives a change of staff.
- Reviewing what Patricia produces before you publish it or send it to a client.
8. What we have not built yet
Named honestly, because a reviewer will ask either way. This is the same list /security and its machine-readable twin publish, rendered from the same source, so the three cannot disagree.
- 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.
9. Responsible disclosure
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.
No paid bounty today. 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.
10. Related documents
- Terms of Service, the agreement these commitments sit under.
- Data Processing Agreement, including Annex II, the contractual list of technical and organisational measures.
- Privacy Policy, including retention windows and data-subject rights.
- Subprocessors, the current list and the change notice.
- Security overview, the same posture explained in prose.