# Patricia security and compliance

Machine-readable version of https://www.patricia.app/security. Patricia is an AI coworker
that works inside a company's Slack workspace and acts in the tools that
workspace connects, so the questions below are the ones that decide whether
she is allowed near a customer account.

## Compliance

| Standard | Status |
| --- | --- |
| SOC 2 | Type II, audited |
| GDPR | Compliant |
| ISO 27001 | Certified |

Reports and audit documentation live in the BetterGroup Trust Center,
https://trust.bettergroup.io/ . BetterGroup is Patricia's parent company and runs
compliance for every product in the group.

## The short version

- **What she can see.** Only the channels you add her to and the tools you connect. Each client account is walled off in the data layer, so nothing she learns on one can surface on another.
- **Who can reach it.** Your team, under the role you give them. On our side, a small number of authorized staff on a need-to-know basis, bound by confidentiality, and every time it happens it is written to a log that cannot be edited.
- **What she can do alone.** Reading and drafting. Anything that leaves the building, changes a setting, deletes data, or spends money waits for a named yes from someone you have allowed to give it.

## Controls

| Area | Control | How it works |
| --- | --- | --- |
| 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. |

## What runs on its own, and what waits for a person

Every action Patricia can take carries a risk tier. The low tiers run on their
own; the rest stop and wait for a person you have chosen. An approval request
posts in the channel the work lives in, and you decide which roles can approve
which tier.

| Risk tier | Example action | Approval required |
| --- | --- | --- |
| 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 |

## Roles

| 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 |

## Data residency and encryption

| Item | Value |
| --- | --- |
| Primary storage region | United States, US East (Virginia) |
| EU, UK, and Swiss transfers | Covered by Standard Contractual Clauses in the DPA |
| In transit | TLS, with HSTS |
| At rest | Infrastructure encryption at rest |
| Credentials and connected-tool secrets | AES-256-GCM at the application layer |
| Model training on your data | Never, contractually, in section 2.4 of the DPA |
| Subprocessor change notice | At least 14 days, and you can object |
| Breach notification | 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. |

## Retention and deletion

| Data | Retention |
| --- | --- |
| 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. EU and UK representatives are appointed and named there. A request about personal data inside your own workspace is different: there you are the controller and we are the processor, so the request goes to you. If a data subject writes to us instead, we refer them to you or forward the request, and we help you answer it. That split is section 5.1 of the DPA.

## What we have not built yet

A vendor that shows you only the audited list is showing you half of it. These
are not shipped today:

- **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, say so. It changes the conversation,
not the answer.

## Responsible disclosure

Email ricardo@patricia.app with what you found and how to reproduce it.
Acknowledgement within two business days, then updates until it is fixed.
Most interesting to us: 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.

## Paperwork

- Terms of Service: https://www.patricia.app/legal/terms
- Security commitments, the same posture in the legal register: https://www.patricia.app/legal/security
- Data Processing Agreement: https://www.patricia.app/legal/dpa (countersigned copy: access@patricia.app)
- Privacy Policy: https://www.patricia.app/legal/privacy
- Subprocessors: https://www.patricia.app/legal/subprocessors
- Trust Center, for the SOC 2 Type II report: https://trust.bettergroup.io/

## Security FAQ

### 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.

## Other machine-readable pages

Every page below also answers in markdown at its normal URL when you send
`Accept: text/markdown`.

- What Patricia is, and when to use her: https://www.patricia.app/index.md
- Pricing, plans, and worked examples: https://www.patricia.app/pricing.md
- Patricia for marketing agencies: https://www.patricia.app/for-agencies.md
- Connected tools and integrations: https://www.patricia.app/integrations.md
- What teams ask her to do: https://www.patricia.app/use-cases.md
- Who is behind Patricia: https://www.patricia.app/about.md
- MCP server, REST API, and the OpenAPI document: https://www.patricia.app/developers.md
- Agent front door: https://www.patricia.app/llms.txt
- Full product context: https://www.patricia.app/llms-full.txt
- Agent skill: https://www.patricia.app/.well-known/agent-skills/patricia/SKILL.md
- Recovery document for a missing page: https://www.patricia.app/404.md