Security

A customer-facing overview of how we protect case data, isolate tenants, encrypt at rest and in transit, control internal access, and respond to incidents. The technical details that back each claim are in our public repository and our internal control documents (available under NDA for enterprise diligence).

Last reviewed
2026-05-20
Editorial owner
Engineering & Security

Architecture in one paragraph

Servd runs on Vercel (Next.js, US regions). Persistent data lives in Neon Postgres (US) with point-in-time recovery; documents in Cloudflare R2 with vendor-managed AES-256 encryption. Authentication via Clerk. Payments via Square. AI inference routed through Portkey to Anthropic with our redaction pipeline in front. Each layer has independent SOC 2 attestation from its vendor; the controls Servd itself owns are summarized below.

Tenant isolation

Each customer is a “firm” (or, for direct consumer purchases, a single-user firm-equivalent). Tenant isolation runs in three defense-in-depth layers:

  1. Application layer. Every API route calls requireAuth() and filters database queries by the caller's firmId.
  2. Belt-and-suspenders. Routes that load a case row also call assertCaseAccess(), which raises if a case leaks across tenants.
  3. Database layer. Postgres Row-Level Security is enabled on every firm-scoped table. Policies read transaction-scoped GUCs that the app layer sets per request. Even a vulnerability in the application layer cannot read a row outside the caller's firm.

A weekly cross-tenant evaluation cron job runs synthetic queries across tenant boundaries and writes the results to an immutable audit table; failures alert the on-call.

Encryption

  • In transit: TLS 1.2+; HSTS preload; modern ciphers only.
  • At rest: Neon AES-256 transparent encryption; Cloudflare R2 AES-256; Clerk vendor-managed.
  • Payment cards: Servd never sees a card number. Square handles tokenization and storage within PCI scope.
  • Secrets: Vercel environment variables + GitHub Actions secrets; quarterly rotation; emergency-rotation runbook in our internal docs.

Access control

  • Customer accounts authenticated via Clerk. Multi-factor authentication is enforced for Servd internal admin and superadmin roles at the application layer.
  • Least-privilege role model: firm-admin, firm-paralegal, consumer, server, servd-admin, servd-superadmin. The full role × resource matrix is documented in our internal RBAC table; the canonical code is at packages/auth/src/rbac.ts in our repository.
  • Internal access is least-privilege + quarterly access review (next review date in our internal docs).
  • Every state-changing admin action (refund, server suspension, tier adjustment, payout batch creation, prompt edit, RAG statute edit) is audit-logged with actor, before / after, and timestamp.

Audit log

Append-only. 7-year retention floor (configurable up). Includes user / role / action / resource / case_id / thread_id / IP / user-agent / result / metadata. Exportable on request and via a per-case PDF report admin can generate.

AI safety

  • Customer data is processed by Anthropic via Portkey under commercial terms that prohibit model training on Customer data.
  • Direct identifiers (SSN, full bank account, full payment-card number, DOB) are stripped by a redaction pipeline before prompts leave Servd's servers. Code path lives at packages/ai-brain/src/safety/redact.ts.
  • A “UPL check” pass classifies outputs that risk unauthorized practice of law and surfaces a disclaimer or refuses the response.
  • Every affidavit gets a human review before signing.
  • Rate-limit and duplicate-prompt detection guard against abuse and runaway agent loops.

Observability

  • Sentry for errors + session replay (replay has text + media masked by default).
  • PostHog for product analytics with PII redacted.
  • Axiom for application logs.
  • PostHog Status, internal Vercel observability, and SLO targets documented in our internal SLO doc.

Vulnerability disclosure

Report security issues to security@servdlegal.ai. We acknowledge within 2 business days, triage within 5, and disclose remediation in our changelog where appropriate. We do not currently run a paid bounty but welcome coordinated disclosure.

Compliance roadmap

  • SOC 2 Type I — engagement in planning. Scope: Security + Confidentiality.
  • SOC 2 Type II — planned after a 6-month observation window.
  • Third-party penetration test — planned annually; current report under NDA.
  • HIPAA — not in scope (Servd does not process PHI as a covered entity or BA).

Documentation available on request

  • RBAC matrix.
  • Incident response plan (NIST SP 800-61 Rev.3 aligned).
  • Disaster recovery plan (RTO / RPO targets per system).
  • Vendor inventory + subprocessor list.
  • Encryption + KMS documentation.

Send NDA + diligence request to security@servdlegal.ai.