Security & Architecture Brief

This brief describes how AsyncConfer handles confidential litigation material. It is written for the vendor risk reviewer at a firm evaluating whether to let its litigators use the platform. Print it to PDF if you need it as an attachment.

AsyncConfer is operated by AsyncConfer LLC, a limited liability company with a single owner-operator. Being a small vendor, we would rather state our controls precisely — including what we do not yet have, in the last section — than imply an enterprise security program we do not run.

Hosting and data location

The application and its database run entirely on Render, in Render's Oregon region in the United States. We operate no servers of our own, and no case material is ever stored on personal or office hardware.

Render maintains SOC 2 Type II and ISO 27001 certifications covering the infrastructure, physical facilities, and network boundaries beneath us. Render's SOC 3 report is available to firms that ask us for it; Render's full SOC 2 Type II report and ISO 27001 certificate are obtainable through Render under a non-disclosure agreement, which we can help arrange for a firm whose review requires them. Those certifications cover Render's infrastructure, not AsyncConfer's application layer — the controls below are the application layer, and they are ours.

Encryption

• In transit: all traffic is HTTPS over TLS, terminated by Render, with HTTP Strict Transport Security set for one year including subdomains. Database connections are encrypted with Render-managed TLS certificates.
• At rest: Render Postgres encrypts data at rest with AES-256, covering the primary instance, any replica, and all backups.

Authentication and sessions

• Passwords are stored as salted scrypt hashes with a 64-byte derived key. Plaintext passwords are never written to disk or logs, and cannot be recovered by us.
• Sessions are held server-side and are individually revocable. The cookie carries only an opaque random token; the database stores its SHA-256 hash, never the token itself. It is set HttpOnly, Secure, and SameSite=Lax — unreadable to JavaScript, never transmitted over plain HTTP, and not sent on cross-site requests — and expires after 30 days. Account holders can see every signed-in device and revoke any of them, or all of them at once; a revoked session stops working on its next request.
• Two-factor authentication is available on host accounts, using time-based one-time passwords (TOTP, RFC 6238) from any standard authenticator app. The shared secret is stored encrypted under AES-256-GCM, so a database copy alone does not yield working codes. Each code is accepted once — a code observed in transit cannot be replayed within its own window. Enrolment issues ten single-use recovery codes, stored only as keyed hashes. With 2FA enabled, a password reset does not bypass the second factor.
• Both audit trails are hash-chained. Every entry stores the hash of the entry before it plus its own keyed digest, so altering, reordering, or removing an entry breaks every link after it and is detectable. The key lives in the application environment rather than the database, so database access alone will not produce a consistent chain over doctored entries. A conferral record's current seal appears on its PDF export and on the read-only inspection page, putting a copy outside the database. One honest limit: entries written before we introduced this are outside the guarantee and are labelled as such.
• A chain shortened from its end would still verify from the inside — what remains is a shorter, consistent chain. So once a day we take a root seal over the current tip of every chain and email it, with the full list of tips, off the system. Removing entries from any chain changes that list, and the copy that would show it is already out of reach in a mailbox. Each day's mail is checked against the previous day's and says plainly whether anything was lost or rewritten. The mail is also a heartbeat: if it stops arriving, that is itself a signal, whether or not anything else reports a problem.
• Each account carries its own security trail — sign-ins and whether a second factor was used, password resets, two-factor changes, recovery-code use, and session revocations. Actions we take on your behalf during support are recorded as such and are visible to you in the application, and any change to a factor protecting your account is emailed to you. A support request to reset two-factor is verified out-of-band, on a channel other than the account's own email.
• Both trails are read by rules, not only kept for later. A chain that fails verification, or any action taken with operator powers, is emailed immediately. Activity that is usually legitimate but is also what a takeover looks like on its first day — a sign-in from an address an account has never used, a run of failed sign-ins followed by a success, an unusual number of exports, an access link being replaced — goes into the daily digest. The split is deliberate: an alert that fires often is an alert that gets ignored, so only the things that should never happen interrupt anyone.
• Authentication endpoints are rate-limited per source address and per targeted account, as are the two-factor verification and document-export endpoints. Counters live in Postgres, so they are shared across instances and survive deploys.
• Sign-in, sign-up, and password-reset requests carry a bot challenge (Cloudflare Turnstile), which raises the per-attempt cost of automated credential stuffing beyond what rate limiting alone can reach when an attacker spreads attempts across many addresses. Turnstile is privacy-preserving by design: it sets no tracking cookie, and it is loaded only on those three pages.
• Every host must verify their email address before using the application. Everyone invited into a workspace must verify their own address before entering it, including colleagues added by counsel rather than by the host.
• Email verification, invitations, and password resets all use purpose-scoped, HMAC-signed tokens that expire — one hour for a password reset, twenty-four hours for a verification link. A reset link is single-use: it is bound to a fingerprint of the current password hash, so setting a new password invalidates any outstanding link immediately.
• The password reset endpoint returns an identical response whether or not an account exists, so it cannot be used to enumerate which attorneys hold accounts.

Access control and workspace isolation

• Authentication is enforced in server-side middleware on every request to the host application, not in client-side code.
• A workspace is visible only to its host, to the parties the host invites, and to the colleagues those parties add to their own side. Everyone reaches it through their own unguessable, signed invitation link, and each browser must independently prove control of that person's own email address before it can act in the workspace. Counsel can add and withdraw people on their own party and no other; withdrawing someone stops their link working but leaves what they already submitted in the record.
• A host may issue a read-only record link so chambers or a clerk can inspect the conferral record without an account. The link carries an unguessable token, exists only if the host creates it, and can be rotated at any time — which immediately invalidates the previous one.

Payment data

Card details are entered into fields served by Square, inside an iframe from Square's own origin, and go directly to Square. Card numbers never reach our servers and are never stored in our database. We retain only the payment identifiers Square returns, which keeps our systems out of PCI cardholder-data scope.

Subprocessors

Provider	Purpose
Render	Application hosting and managed PostgreSQL (United States).
Square	Card processing and subscription billing.
Resend	Transactional email delivery.
Amazon Web Services	Outreach email delivery only — a deliberately separate provider and account from Resend, so that a problem with one cannot stop the other. Receives no workspace content and no account data.
Cloudflare	Bot challenge (Turnstile) on the sign-in, sign-up, and password-reset pages only.
Anthropic	AI features, when you use one. Receives the text you submit to that feature: an imported document, the notes you type for a section, or two competing positions and their discussion. Not used to train models.

That is the complete list, and only the first is involved in an ordinary page view. We serve our own fonts rather than using a font CDN, and we run no third-party analytics, advertising, or session-recording trackers of any kind. Outside the three authentication pages that load the bot challenge, viewing a page — including any workspace, section, or conferral record — discloses your visit to no third party at all.

AI features

Three features use Anthropic's Claude API. Importing a document sends the text of that document, and the model tells us which paragraph belongs to which section. Drafting a section sends the notes you type for that one section, and returns language you can edit, replace, or discard. Suggesting a compromise on a section where the parties disagree sends the two competing positions and that section's discussion, and the model proposes language that might settle it. In every case text goes to Anthropic only when someone invokes the feature, never in the background, and never merely because a workspace exists.

Five things about how this is built are worth stating, because they were choices rather than defaults:

• The file still never leaves your browser. A PDF or Word document is converted to text on your own machine, as it always has been. What is sent is that text — not the file, and not any metadata it carries.
• Import cannot paraphrase you. There the model answers with paragraph numbers, not prose, and the text that lands in a section is copied from your document exactly. It is never asked to produce your language, so it cannot alter it.
• Nothing is ever asked for legal authority. No feature requests a case, statute, or rule citation, and none is prompted to supply one. Drafting produces procedural language — deadlines, scope, protocols — from the notes you gave it. The instruction is also enforced rather than trusted: a finished draft is scanned for citations and compared against your notes, and one that introduces authority you did not write is discarded rather than shown to you with a warning. A citation you typed yourself is carried through untouched — it is your text. Sections that turn on authority are written by counsel rather than generated.
• Drafted language is yours only when you keep it. A drafted section is written from the notes you typed for that section and nothing else — not the other side's positions, not the rest of the matter. It lands in an editable field, and it becomes your proposed language when you submit it, exactly as if you had typed it yourself.
• A compromise suggestion is prose, and it is labelled as such. It is shown to both parties at once, marked machine-generated, and belongs to nobody unless one of them adopts it — at which point the conferral record shows where the language came from. It is not advice about whether to agree, and neither party is asked to respond to it.
• Nothing is saved until you accept it. An import is staged for review; you confirm or correct every section before anything becomes part of the record. A drafted section sits in an editor until you submit it. A suggestion sits in the section until someone adopts it or nobody does.

One further precaution is specific to compromise suggestions. The model is not told which position belongs to which party, which side is the plaintiff, or whether either party is representing themselves — and the suggestion is generated twice, with the two positions in opposite orders. If the two runs settle the disagreement at different points, the model was responding to the order it read them in rather than to their merits, and no suggestion is shown at all. We would rather offer nothing than offer something quietly tilted toward the side that wrote more like a lawyer.

Anthropic does not train models on content submitted through its API. If your matter is one where no third party may see the content at all, do not use these features — everything else in the application works without them.

We do keep a first-party operational request log: the route pattern, response status, duration, IP address, and a coarse browser label, retained about 30 days and then reduced to daily totals. It never leaves our systems and no third party sees it. Two details matter for confidentiality: the log records the route pattern rather than the URL, so a workspace invitation or record-inspection token can never appear in it, and it records a browser family rather than the full user-agent string. It exists to show errors, capacity limits, and attacks in progress — the things you would want us to notice.

Auditability

Every workspace keeps an append-only audit log recording who took which action and when — proposals, counter-proposals, comments, accept and reject decisions, and stipulation acknowledgements. This is what makes the exported conferral record defensible if the adequacy of the conferral is ever challenged.

Confidentiality and data use

• We do not sell client data, and we do not share it for advertising.
• We do not use workspace content to train machine learning models, and neither does the AI subprocessor: Anthropic's API terms exclude submitted content from model training. Content reaches Anthropic only when you invoke an AI feature yourself — see AI features above for what is sent and when.
• Access by us is limited to what is necessary to operate the platform or to support a problem you have reported.
• Material subject to a protective order remains the responsibility of the filing attorney; the host controls what enters a workspace and whom it is shared with.
• When you import an existing 26(f) statement, the file is read in your browser — the DOCX or PDF itself is never uploaded and we never hold a copy of it. What reaches us is the extracted text, which is what you are proposing as workspace language anyway. It is held while you review the mapping and discarded once you apply it, or within seven days if you abandon the review. We keep a hash of the file so a record can be matched back to a document on disk; the hash is computed in your browser, so treat it as provenance rather than proof.

Application security controls

Every response carries a Content Security Policy restricting script, style, frame, and connection origins to our own domain and our payment processor; HSTS; X-Frame-Options: DENY and frame-ancestors 'none' to prevent clickjacking; nosniff; a strict referrer policy; and a permissions policy disabling device APIs the application does not use. Form submissions are restricted to our own origin, and the framework enforces an origin check on every state-changing request.

Retention and deletion

Workspace content is retained while your account is active. On written request to the address below we will delete an account and its workspaces from the production database, retaining only what tax and accounting law requires — payment records in particular. Deletion is performed manually today rather than through a self-service control; we would rather tell you that than imply an automated destruction pipeline we have not built.

Backups and recovery

Render performs automated backups of the database with point-in-time recovery across a rolling seven-day window, so it can be restored to any moment within the last seven days. Backups are held by Render — never on a machine of ours — and are encrypted at rest under the same AES-256 protection as the live database.

What we do not have yet

A vendor risk review is worth more when the vendor is candid, so: two-factor authentication is available but not mandatory, and covers host accounts rather than invited counsel; there is no self-service data deletion; we run no third-party error monitoring; and, as a single-operator business, we maintain no formal SDLC, background-check program, or written incident response plan. We have not commissioned an independent penetration test. These are known gaps, several are on the near-term roadmap, and we will answer questions about any of them directly.

Contact

Security questions, vendor questionnaires, and requests for Render's SOC 3 report go to stan@asyncconfer.com. Suspected vulnerabilities go to the same address and will be acknowledged within two business days.

AsyncConfer LLC
San Francisco, California, USA