Security

Access model

Turret connects through your existing email provider with read-only access that your administrator authorizes and can revoke at any time. It cannot send, modify, delete, or forward any email. Neither grant below contains a scope that permits writing.

• Google Workspace: Domain-Wide Delegation with a service account your Super Admin authorizes, holding read-only scopes gmail.readonly and admin.directory.user.readonly. Revoke any time from your Google Admin Console.
• Microsoft 365: an admin-consented Microsoft Graph application holding read-only permissions Mail.Read and User.Read.All. Revoke any time from your Microsoft 365 admin center.

What Turret captures, and what it surveils

Turret archives sent and received mail, and runs compliance patterns on outbound mail only. Capture reaches the whole mailbox minus drafts, chats and spam, which are not records: a message filed away, archived out of the inbox or deleted is still captured, because the record does not follow where the user moved it.

Inbound mail is retained as a Rule 204-2(a)(7) record and is never pattern-matched, on either provider. That is a documented scope decision, not a gap — a supervision program under Rule 206(4)-7 is responsible for the firm's own representations.

On Microsoft 365, three limits, named. Capture and surveillance cover the user's primary mailbox, Deleted Items included, but not the separate online-archive mailbox that an archiving policy moves older mail into, and not hard-deleted mail, which Exchange keeps in a Recoverable Items folder that Turret does not read. A message still waiting in the Outbox has not been sent; it is captured once it has.

Surveillance depth and archive depth are different numbers, deliberately. The archive is built to the full 7-year retention window; historical pattern-matching covers the most recent year, and outbound mail recovered later by a change in capture scope is archived but not retroactively scanned. A supervision program reviews current communications, and a backlog of unworked alerts on years-old mail is worse in an examination than none.

Attachment text extraction is off in production on both providers, so language appearing only inside a PDF or DOCX is archived but not matched. The filename, media type and size are inside the hashed record.

Encryption

Any credential Turret stores in its own database is encrypted with AES-256-GCM at the application layer, using a key held outside the database, with a fresh random initialization vector and an authentication tag that detects tampering. Turret's shared mail-provider credentials — its Google service-account key and its Microsoft Graph client secret — are not kept in the database; they are held in a dedicated secret store, described below. All customer data is encrypted at rest by the database platform, and all traffic is encrypted in transit with TLS.

Domain-Wide Delegation runs on a short-lived signed assertion rather than stored per-user credentials, so Turret holds no password or token for any individual mailbox. The links Turret emails — invitation, setup, confirmation and signup-resume links — are stored only as a SHA-256 hash. A link that may need to be sent again is re-derived with a key held outside the database, never read back from it, so a copy of the database yields no usable link.

Authentication and access control

Sign-in is handled by Clerk, a dedicated authentication provider, on a verified custom domain, with Google, Microsoft, or email and password. Anyone can create a login, but a login on its own opens nothing: a firm's users see its data only through a membership in that firm. Turret creates the first membership for the firm's admin when the firm is set up; everyone else gets one only by accepting an invitation, which requires a verified email address. Turret staff access is described under Staff access below.

Turret has four roles, and one of them deliberately cannot see client mail. Admin adds user management and settings; Reviewer is the day-to-day compliance role; Viewer sees everything read-only, which is the role for an outside CCO or consultant; Employee reaches the marketing-review module only — never alerts, never archived mail, because those hold client communications. The same rule is applied again at send time, so neither an Employee nor a Viewer receives escalation email or the weekly digest. Gates are enforced server-side, and a test in the suite builds the application with authentication switched on, so a gate removed by accident is caught rather than shipping quietly.

Production fails closed on configuration: six settings must be explicitly and unambiguously set or the service refuses to start.

Tenant isolation

Every database record is scoped to a tenant ID. Application-layer queries always filter by tenantId. One firm's data is never accessible to another firm, even on the same infrastructure.

The tenant is derived from the authenticated session, never from user-supplied input, and direct-object lookups are guarded so that guessing an identifier reaches nothing. A regression test in the suite covers cross-tenant reads specifically.

PII handling

Social Security and card numbers are removed from an alert before it is written to the database, and the match is deliberately aggressive: SSNs in bare nine-digit form, card numbers checksum-gated. Both the matched snippet and the alert subject are redacted before any write, which is also what keeps that text out of the AI triage prompt. Labelled placeholders replace blanks, so the compliance signal survives redaction.

The archived message stays raw — it is the Rule 204-2 system of record and must preserve the original exactly. Names and email addresses are deliberately not redacted: they are far lower sensitivity than an SSN, and they are the signal a reviewer needs to judge context and off-channel contact. Tenant isolation, encryption and access control protect them instead.

How archived mail is displayed

An archived message body never renders inside the reviewer's authenticated page. It is served from a separate endpoint into a sandboxed frame with no scripts, no forms and no top-level navigation, under an enforcing Content-Security-Policy of default-src 'none'. Two independent barriers must fail before markup written by the sender could execute, and neither depends on the HTML sanitizer being correct.

Remote images are blocked by default and auto-load only for mail the firm itself sent from its own domain, so opening an inbound message returns no read receipt to its sender.

Secrets management

Turret's high-value secrets — the encryption key, the authentication secret, and the API and mail-provider credentials — are managed in a dedicated secret store, Google Secret Manager, accessed at startup through a single least-privilege accessor identity. The loader fails closed and never logs a value. Continuous integration scans the code of every pull request for a committed credential, and the full git history weekly.

Logging

Email addresses are not written to Turret's logs; a stable hash replaces them, and free text is scrubbed because provider errors routinely embed the mailbox address. A test in the suite fails on a new offender.

One residual, stated rather than omitted: when a mailbox cannot be read, the provider's error text is stored verbatim in that job's operational record — scrubbed in the log line, not in the database row. It is tenant-scoped and behind authentication, and it is not redacted.

Staff access

Turret staff do not access email content as part of normal operations. Support access is to operational metadata, such as job status, error logs and scan counts. Our administrators can technically open a firm’s archive, for example to build an export you ask for, so we don’t claim that no one ever can.

Audit logging and tamper evidence

Every archived message carries a SHA-256 hash of its canonical content in an activity log that is append-only at the application layer; every reviewer action is written to a second one. The first of the two, the archive log, holds no foreign key to the message it describes, so its entry outlives that message's retention purge; that property is the archive log's alone.

Integrity is re-verified across the whole archive and exported as a PDF attestation. The latest Archive Integrity Verification Report is downloadable from Reports. The mechanism, and what it does not establish, is set out at /security/architecture.

AI processing

For each email alert, Turret sends the subject, the sender and recipient addresses, the matched text and snippets your reviewers previously dismissed for the same pattern to Anthropic's Claude for a score and a written reason; Social Security and card numbers are redacted first. For the Marketing pre-screen, the submitted piece, its title and the submitter's notes are sent to Claude unredacted. When a reviewer uses "Run through AI" on a marked area, the whole page image, the text the reviewer selected, their note and the document's extracted text are also sent to Claude. The AI never approves marketing, and it closes an email alert only if you have turned on auto-clear. A firm admin can switch the Marketing AI pre-screen off in Settings; nothing from your marketing submissions is then sent to Claude, and the built-in phrase checks still run.

Names and email addresses are not redacted, because they are the context a reviewer needs.

Marketing review

Marketing pieces your team submits (the file, its extracted text and rendered page images) are stored in your firm’s tenant, alongside the review record. The pre-screen drafts findings only; it cannot approve, reject or block a piece. The Employee role that submits marketing cannot open alerts, the archive or reports.

Website archiving

Turret captures the public pages of your firm’s own website on a schedule, as a screenshot and the page’s HTML, and records a SHA-256 hash of each capture. It fetches only publicly visible pages. Archiving a domain other than your firm’s own is not self-serve: a Turret administrator reviews each request first.

Web application hardening

• Output encoding at every rendering sink is the primary defence against cross-site scripting, including for content Turret does not control — inbound mail surfaced in a search result, for instance.
• State-changing requests are checked against their Origin and Referer.
• HSTS, X-Frame-Options, X-Content-Type-Options and a strict Referrer-Policy are set by Helmet.
• Session cookies are marked Secure in production.
• Rate limiting is keyed on the real client IP rather than a header a caller can write.
• Captured attachments are always served as a generic download under a locked content type — never the sender-declared type, never inline.
• Dependencies are pinned by a committed lockfile, so every build installs the tree that was tested, and continuous integration fails on a critical advisory.

Said plainly, two limits. The site-wide Content-Security-Policy is report-only today; moving it to enforcing is on the roadmap below, and the archived-mail endpoint above is the exception, already enforcing. And three third-party scripts on signed-in pages — the Tailwind CDN, Clerk and Termly — cannot carry subresource-integrity pinning, so they load into the same document that renders archived client mail. A test in the suite refuses a new static script tag that is neither integrity-pinned nor served from our own origin; it reads templates, so a script injected at runtime — as Clerk's is — is outside what it can see. Replacing the largest of the three with a build step is the fix, and it is on the roadmap.

Compliance posture

• A SOC 2 Type 1 readiness assessment and CASA Tier 2 are planned; neither is held. We’ll say when either is done, not before.
• A data processing addendum is available on request.

A failed payment pauses access; it does not delete anything, and what stops is capture — mail not archived from that day cannot be collected retrospectively. If the balance stays unpaid for 90 days from the first missed payment, the firm's records may be deleted through the same reviewed step, so the firm should request an export before then. After a subscription is cancelled, the firm's archive is kept for 60 days. During that time the firm can request a full export by emailing support; after 60 days Turret deletes the records, through a reviewed manual step by a named person, never an automatic job, and recorded in an audit trail that outlives the firm. Turret can place a firm-wide legal hold on request: it stops scheduled retention deletion and blocks deletion of the firm’s account. The firm remains responsible for retaining its records under SEC Rule 204-2, which is why the export is offered.

Roadmap — planned, not shipped:

• Site-wide Content-Security-Policy moved from report-only to enforcing.
• A Tailwind build step, removing the largest of the three third-party scripts that cannot be integrity-pinned.
• A published standard DPA template and a documented incident-response plan.
• A legal hold on individual messages.

Common questions

Can Turret read or send my firm's email?

Turret can read it and can do nothing else: both provider grants are read-only, so no scope in the connection permits sending, modifying, deleting or forwarding a message, and your administrator can revoke the grant from your own admin console at any time.

Does Turret monitor inbound email?

Turret archives inbound email and does not pattern-match it — inbound is retained as a Rule 204-2(a)(7) record, while compliance patterns and alerts run on outbound mail only, on both Google Workspace and Microsoft 365.