Security & Architecture Whitepaper

BarZero is a privacy-first AI contract review and creation product. It is architected so that the confidential content a lawyer puts in front of it — draft contracts, client matter notes — never lands in a BarZero database in plaintext, not even briefly. The sections below describe exactly how that works, what it does not protect against, and which claims are in place today versus aspirational. Section numbers are stable so you can cite them in a security questionnaire.

1. Architecture Overview

BarZero rests on three pillars: Zero Trust, Zero Knowledge, and Zero Retention. These are implementation properties, not slogans — each maps to a specific mechanism in the codebase.

1.1 Zero Trust

The BarZero server is designed so that a full server-side compromise of the production Postgres database would not expose any customer document or contract draft. That is enforced by storing only two kinds of state server-side: account metadata (users, organizations, memberships) and billing state (Stripe customer/subscription ids and page counters). There is no Matter table, no Contract table, no Chat table, and no prompt/response log. Reviewers can confirm this by reading prisma/schema.prisma.

1.2 Zero Knowledge

All user-generated workspace content — matters and contract reviews with clause-by-clause analysis — is persisted in the user's browser IndexedDB (via Dexie). The AES-256-GCM encryption key used to wrap that data is generated with crypto.subtle.generateKey as a non-extractable CryptoKey. The browser structured-clones the CryptoKey object into IndexedDB; the raw key bytes never exist as a JavaScript value. BarZero engineers cannot retrieve the key, XSS on the page cannot exfiltrate the key, and a subpoena served on BarZero cannot compel the key because BarZero does not have it.

1.3 Zero Retention

Every AI inference runs through Anthropic's Messages API under their Zero Data Retention(ZDR) program — always on, single code path. Anthropic does not persist, log, or train on prompts or responses routed through this path. The ZDR state is reported back on every request via the X-BarZero-ZDR response header.

2. Cryptographic Architecture

BarZero uses a symmetric cipher for local data at rest. The primitive is standard WebCrypto — no custom cryptography.

2.1 Local data encryption — AES-256-GCM

The device key is a 256-bit AES-GCM key created by window.crypto.subtle.generateKey with extractable: false. The returned CryptoKey is persisted in a dedicated IndexedDB database (bz_crypto) via structured clone, so it can be retrieved on later sessions and used for encrypt/decrypt operations, but the raw key bytes are never accessible to JavaScript. Every Dexie row is sealed with a fresh 96-bit random IV from crypto.getRandomValues.

This is a meaningful XSS hardening step. An attacker who lands JS execution on a BarZero page can call subtle.encrypt and subtle.decrypt with the key handle, but cannot export the key material to a remote server, cannot reuse it on another origin, and cannot exfiltrate it across a subsequent page load.

Honest caveat: the legacy localStorage key

Users who signed up before the non-extractable-key hardening shipped may still hold a legacy key stored as base64 in localStorage under the name bz_device_key. On first load after the upgrade, the client imports that legacy key as extractable: true so existing Dexie ciphertexts remain readable, and logs a one-time console warning. Full migration — re-encrypting every Dexie row under a fresh non-extractable key and deleting the legacy entry — is deferred work, tracked in src/lib/crypto.ts. New installs and users who have cleared their local data are on the hardened path today.

3. Data Flow

This section traces where user data physically lives for each product surface. “Server” below always means BarZero production infrastructure (Next.js app + Postgres); subprocessors are listed separately in §4.

3.1 Contract review

Document upload and text extraction happen entirely in the browser. The extracted text is persisted to IndexedDB under the Dexie contracts table, AES-256-GCM encrypted at rest. When the user requests an analysis, the text is posted to POST /api/chat with mode: "contract". The server:

• Authenticates the session and looks up the active organization.
• Re-derives the billable page count server-side from the document text — the client-supplied count is never trusted.
• Forwards the payload to Anthropic Claude with the ZDR code path. BarZero writes nothing about the document to Postgres, and nothing to a log or metrics pipeline beyond per-request error diagnostics that do not contain prompt text.
• Streams the model output back to the browser in plain text, where the client appends it to the Dexie row for the session.

The only strings about this contract that ever exist on BarZero servers are a metered page counter on the Organization and the normal Stripe billing telemetry for the metered scan.

3.2 Chat

Freeform chat messages follow the contract-review path: ZDR active, nothing stored server-side, and the conversation history lives only in the client.

3.3 What is stored server-side

For completeness, here is the full list of what the BarZero Postgres database actually holds, which you can audit directly in prisma/schema.prisma:

• User — id, name, email (from OAuth provider), profile hints captured in the welcome wizard (display role, firm name, practice areas, jurisdiction).
• Account / Session / VerificationToken — standard Auth.js tables backing OAuth login.
• Organization — billing entity, Stripe customer id, plan, page quota counters, billing cycle.
• Membership / Invitation — who belongs to which organization, in what role.
• Ticket — support/contact form submissions.
• ProcessedStripeEvent — dedupe table for Stripe webhook replay protection.

Not present, by design: Matter, Contract, ContractSession, Chat, Message, Document, File. Content is a client concern, not a server concern.

4. Subprocessors

The following third parties process customer data on BarZero's behalf. The list corresponds to code paths that a reviewer can locate in the repository.

Anthropic is reached from src/lib/claude.tsfor every AI request. All contract and chat traffic moves through Anthropic's ZDR code path.

Stripe handles checkout, recurring billing, and metered usage reporting for contract scans; see src/app/api/stripe/webhook/route.ts. Card data never touches BarZero infrastructure — Stripe's hosted checkout collects and tokenizes it.

Resend sends transactional email (team invites). It is only active when RESEND_API_KEY is set; in dev the email is logged and not sent. Product notification emails are kept to a minimum.

Google and GitHubare the only identity providers. BarZero never sees a user's password — see §7.

This list can drift over time. If you need the canonical current list for procurement, ask via the contact page and BarZero will provide it. The DPA (/dpa) commits to 30-day advance notice before adding or replacing a subprocessor.

5. Zero Data Retention, In Detail

Anthropic offers a Zero Data Retention program for organizations whose data cannot be retained for abuse review. When a request is routed through this path, Anthropic commits that prompts and responses are held only in the volatile memory needed to serve the request — they are not written to durable storage, not used to train models, and not available to Anthropic trust-and-safety tooling for retrospective review.

BarZero takes advantage of ZDR by default on a single code path. The /api/chat route attaches two response headers on every AI response so both the client UI and any security-conscious reviewer can see the retention posture of that specific request:

• X-BarZero-ZDR: active — the Anthropic ZDR code path was used.
• X-BarZero-Storage: none — nothing about this request is persisted on BarZero servers.

The trust footer in the app shell shows the current ZDR status live as you work (see src/components/trust-footer.tsx).

6. Authentication & Access Control

BarZero does not store passwords. Sign-in is OAuth-only via Google or GitHub, handled by Auth.js v5 with the Prisma adapter. The rationale, written on the sign-in page:

• No password database to breach. There is no BarZero credential store to steal, rotate, or subpoena.
• Real authentication happens at the identity provider. Two-factor authentication, hardware-key enforcement, password reset, anomaly detection, and session revocation live at Google or GitHub, with thousands of engineers hardening them.
• Zero phishing surface.There is no BarZero login form to spoof. An attacker cannot send a fake “reset your BarZero password” email because BarZero does not have passwords to reset.

Sessions use the JWT strategy (session.strategy: "jwt"). Session tokens are delivered as HttpOnly, Secure, SameSite=Lax cookies so they cannot be read from JavaScript. The JWT carries only the fields needed to render the UI (user id, plan, org type, admin flag, onboarding state); the authoritative source for billing and onboarding checks is still the database, re-read on each protected request.

Admin surfaces (ticket inbox, user search, operational tooling) are gated by an environment-allowlisted list of admin emails, applied to the authoritative database email — never the client-supplied session claim. The admin allowlist is also how unlimited / comped accounts are identified for quota-free access.

Enterprise SSO: firms that require SAML, OIDC, or Microsoft Entra ID federation for client-matter work can request a custom deployment on the Orbit tier; reach out via the contact page.

7. Threat Model

Every security claim implies a threat model. BarZero's is written down honestly here: there are things the architecture defends against cleanly, and things it does not — and BarZero does not want a customer to deploy it under the wrong assumption about which is which.

7.1 What BarZero defends against

• Server-side compromise.A full breach of BarZero's Postgres database would expose user accounts and org/billing state. It would not expose a single contract draft or chat message — because none of that lives on the server.
• BarZero staff insider threat to content.No BarZero employee, contractor, or operations tool can read customer matters, because nothing in the staff-accessible systems contains them. Staff can see account email and plan — nothing else.
• XSS against the device key. The per-device AES-256-GCM key is non-extractable. XSS on a BarZero page can call encrypt/decrypt operations while the attacker is present, but cannot exfiltrate the key for later use or cross-origin reuse. (See §2.1 for the legacy localStorage-key caveat.)
• Vendor trust. All Anthropic requests run under ZDR on a single code path.
• Subpoena-at-BarZero.Content that does not exist cannot be produced. A subpoena served on BarZero for the contents of a matter would return billing and account metadata and nothing else. The user's device is the correct target for a content subpoena.
• Credential theft at the password layer. There are no passwords to steal (§6).

7.2 What BarZero does not defend against

• Malicious browser extensions. Any extension with permission to run on a BarZero page has the same access to the rendered DOM and to the CryptoKeyhandle as the page's own JavaScript. It can read plaintext out of the UI and call encrypt/decrypt operations, even though the raw key bytes remain unreadable.
• Physical device compromise.If an attacker has physical control of the unlocked device, they have the IndexedDB data and the CryptoKey in usable form. BarZero's local encryption is a defense against offline data theft and XSS, not against an attacker sitting at the keyboard.
• Client-side keyloggers and memory scrapers. Malware running on the host OS can capture anything the user types or sees. No browser primitive can prevent this.
• Social engineering. An attacker who convinces a user to paste a document into a different tool, hand over an OAuth session, or install a malicious browser extension cannot be stopped by cryptography.
• Compromise at a subprocessor.A breach at Anthropic, Stripe, Google, GitHub, or Resend is governed by that vendor's own security posture. BarZero's ZDR advertising (§5) is conditional on Anthropic honoring their ZDR contract.
• Browser implementation bugs.The non-extractable CryptoKey guarantee rests on the browser vendor's WebCrypto implementation being correct. A browser bug that allowed extraction of a key flagged extractable: false would defeat the XSS hardening.

7.3 Batch and folder review

Batch folder review (a queue of contracts processed with one playbook) runs in one of two modes. Tab-open mode — the only mode shipping in this release — preserves every property in §7.1 by construction: the browser iterates the user's folder via the File System Access API, extracts text on-device, and sends each contract through the same ZDR-protected inference path as a single-document review.

Background mode is an opt-in alternative that lets a batch continue after the user closes the tab. A QStash (Upstash) work queue hands each item to a server-side worker that fetches the file from the source (cloud drive or CLI-staged upload), runs the same orchestrator as single-doc review, discards the bytes when the response finishes, and writes the result to the configured delivery sink. The trust-model difference compared to tab-open:

• Document bytes transit server memory.They are not written to disk, not logged, and not included in any Postgres table. Once the worker's response completes the holding references drop and the buffer is reclaimed by the Node runtime. Reviewers can confirm the absence of persistence by reading src/app/api/batch/worker/route.ts and the Postgres schema.
• Consent is explicit and audited. Before the first background batch, the user acknowledges the distinction via a modal that records a MemberAuditLog entry with action="batch_background_opt_in". The audit row is tied to the org and viewable by admins.
• New subprocessor. Upstash (QStash) joins the subprocessor list (§4) as the queue that fans out messages to the worker. QStash sees the message body, which includes document text in transit; we rely on its own security posture for that leg and do not retain any message after the worker acknowledges it. Customers targeting the strongest confidentiality posture should continue to use tab-open mode.

8. Compliance Posture

This section covers BarZero's own compliance state — what certifications BarZero holds as a vendor.

8.1 BarZero's own certifications

BarZero is currently working toward SOC 2 Type II and ISO 27001. Neither certification has been issued as of the effective date of this page. BarZero does not claim either certification and will not do so until the audit is complete and the report is available. If your procurement process requires a current SOC 2 report or ISO 27001 certificate, please contact the team and we will share the current stage of the audit and target dates.

BarZero complies with applicable data-protection law as a processor. The Data Processing Agreement at /dpa is GDPR Article 28 compliant, applies automatically to all customers using the Services, and can be countersigned on request.

BarZero is not a HIPAA business associate on standard plans (Zen, Ensemble, Realm) and has not executed a BAA with customers or subprocessors for PHI handling. Customers must not input Protected Health Information into BarZero on these tiers. If your practice regularly handles ePHI and you need a BAA, contact us via /contact to discuss an Orbit-tier arrangement, which is the only path on which BarZero can operate as a business associate. See Terms §4–5 for the full no-PHI prohibition.

9. Incident Response

BarZero operates an incident response process consistent with GDPR Article 33 breach-notification obligations. Commitments in the event of a confirmed security incident affecting customer data:

• 72-hour customer notification window. Affected customers will be notified without undue delay, and in any case within 72 hours of BarZero becoming aware of a personal-data breach affecting their data, via the email associated with the account. The DPA at /dpa further commits to a 48-hour target for controller notification where applicable.
• Incident report. BarZero will publish an incident report describing what happened, what data was (and was not) affected, the timeline of detection and containment, and remediation steps. For confirmed incidents affecting customer data, an individualized notification goes to each affected customer in addition to the public report.
• Root-cause analysis. For material incidents BarZero will share a root-cause summary and the technical and procedural changes made in response.
• Regulator coordination. Where required under GDPR, UK GDPR, CCPA/CPRA, HIPAA, or other applicable law, BarZero will coordinate with the relevant supervisory authority and assist customers in meeting their own notification obligations.

To report a suspected incident, email support@barzero.ai or use the contact form with subject line beginning [SECURITY]. Reports from external researchers are welcome — see §11.

10. Data Retention & Deletion

BarZero splits retention responsibilities between the server (for account and billing metadata) and the client (for all content). The two paths are summarized below.

10.1 Server-side

• Content plaintext: never. BarZero does not persist the plaintext of any prompt, document, contract, or chat message. There is nothing to retain because nothing is written (§3.3).
• Account metadata: retained for the life of the account. Deleted within 30 days of verified account deletion, subject to legal holds.
• Billing metadata: retained as required by tax, accounting, and payment-card-network rules. Typical retention is 7 years for invoices and tax records under US federal and state law; actual retention follows the applicable jurisdiction.
• Webhook dedupe: rows in ProcessedStripeEvent are retained for replay protection and can be pruned without affecting user state.

10.2 Client-side

• User-initiated local wipe. The /settings page exposes a Clear all local data action that deletes every Dexie table (matters, contracts) on the current device. This is the right tool for purging everything before handing over a device or changing jurisdictions.
• Per-matter deletion. Individual matters and contract sessions can be deleted from their respective workspace views. Deletes are immediate at the Dexie layer.
• Device-local scope. Clearing data on one device does not affect data on another device — each device holds its own IndexedDB. If you use BarZero on multiple machines, wipe each one.

10.3 Account deletion

Full account deletion — removal of the User row, all memberships, and organization (for solo accounts) — is available on request via the contact page. BarZero will confirm the request against the OAuth-linked email before acting. A self-serve account-deletion button in settings is planned.

11. Responsible Disclosure

BarZero welcomes reports from security researchers. There is no formal bug bounty program at this time, but BarZero will acknowledge valid reports, credit researchers who consent to being named in the incident report, and work in good faith to remediate.

Please report suspected vulnerabilities to support@barzero.ai with subject line beginning [SECURITY], or use the contact form. Include:

• A clear description of the issue and a minimal reproduction.
• The affected URL, route, or endpoint if applicable.
• Your assessment of severity and the threat model under which it applies.
• Whether you consent to being named in any public write-up.

Researchers acting in good faith under this policy — making a reasonable effort to avoid privacy violations, data destruction, and service disruption, and giving BarZero a reasonable opportunity to remediate before public disclosure — will not be pursued legally by BarZero for the reported research.

Please do not attempt to access accounts you do not own, do not run automated scans that exceed normal user traffic, do not exfiltrate customer data to demonstrate an issue, and do not publicly disclose a vulnerability before BarZero has had a reasonable opportunity to respond.