Trust and security
Every table carries a tenant id, resolved from the authenticated principal and never from the request. A key or invitation session maps to one workspace. Isolation is the partition key, so no role widens it.
None by default. Reaching your workspace takes a grant: named capabilities, a required expiry, a written reason, and an audit row before we look. Revoke any of them from your access screen. Re-identification is a separate capability.
No. The audit row is written before the text is returned; if it cannot be written, the read fails with a 503. Applies to Petrarch staff and to your own people alike.
Yes. The Activity screen shows your people's actions and anything we did inside your workspace, our rows carrying the grant and the reason. It needs the audit.read capability, held by admins and reviewers.
Yes. A configuration write records which entity types moved and in which direction, which confidence floors changed, and which allow-list phrases or custom types changed.
Uploaded document text is deleted 7 days after upload. The database stamps the clock on insert; no caller can change it. If the sweep runs late, expired text is hidden on read. Names and page counts outlive the text. A Workbench run's de-identified output is not on that clock: it is kept while the workspace is active, and closing the workspace deletes it.
An uploaded file is parsed in memory and not kept: only the extracted text is stored, in the database. A linked source is the exception - its material is written to our own encrypted object store, under a prefix per workspace, and deleted when the link is removed. Nothing is written to local disk in either case.
Yes - finding personal data in free text takes machine learning. Hosted, the engine calls Anthropic's API in the United States under zero-retention terms: prompts and completions are not stored and no model is trained on them. Document text does leave our own infrastructure on that path. Amazon Bedrock is also used and keeps the text inside it, but Bedrock is not the whole picture today. Both are on the subprocessor list. Self-hosted, the models run in your cloud and reach no vendor.
HTTPS to the application and to the API, TLS 1.3, with HSTS set for a year including subdomains. Checked against the live host.
Yes. Documents and database content are encrypted at rest with AES-256, and in transit with TLS 1.3.
We are currently in our SOC 2 Type II audit. GDPR processor terms are available on request.
The hosted deployment stores uploaded document text in managed Postgres in the United States, linked-source material in an encrypted object store, and each workspace’s de-identified output in that workspace’s own bucket, in the region the workspace is pinned to - EU or US, chosen at creation. Signed in, the Workspace page states where each part runs.
Third parties in the path are named on the subprocessors page, with region and transfer mechanism per party. The three ways to run this are compared on Where it runs.
Send it to founders@petrarch.co for an answer in writing from one of the founders, including “we have not built that”.
Reporting a vulnerability has its own route: what to send and what to expect. For a data processing agreement, see what Petrarch will sign.