Executive summary
DocuChase is designed so tax-document content is encrypted in the client browser before storage. A unique authenticated encryption key protects each document; that key is wrapped to the accounting firm rather than stored in plaintext.
Application security still depends on identity, authorization, endpoint integrity, provider configuration, and the firm's own operational controls. This brief describes those shared responsibilities instead of treating encryption as a complete compliance program.
Document security flow
Request
The accounting firm creates a document checklist. DocuChase stores request metadata and generates a high-entropy upload token.
Encrypt
The client browser generates a unique AES-256-GCM key, encrypts the selected file, and wraps that key to the firm’s RSA-OAEP public key.
Store
The encrypted payload and wrapped document key are stored in private Supabase infrastructure. The application does not need plaintext document content to store it.
Unlock
An authenticated firm user unlocks the password-wrapped private key in the browser. A short-lived signed URL retrieves the encrypted object for browser decryption.
Cryptographic construction
Document encryption
AES-256-GCM provides confidentiality and authentication for each document payload. Each file receives a fresh random key generated with browser Web Crypto.
Key wrapping
The document key is wrapped with the firm's RSA-OAEP public key. The corresponding private key is itself wrapped in the browser with a password-derived AES key before storage.
Key availability
The vault password and unwrapped private key are intended to exist only in the active browser session. DocuChase cannot recover a forgotten vault password.
Identity and authorization
Firm users authenticate through Supabase Auth. PostgreSQL Row Level Security policies scope firm, client, request, and item records to the authenticated firm owner. Server actions repeat ownership checks before sensitive document operations.
Client upload links use random bearer tokens and expire after the configured window. Storage remains private. Firm downloads use signed URLs with short validity after authorization.
Security responsibility boundary
DocuChase application
Request metadata, firm/client contact data, ciphertext, wrapped keys, and operational events.
Accounting firm
Vault password custody, endpoint security, user access, downloaded plaintext, retention decisions, and compliance program.
Infrastructure providers
Controls and attestations for the provider services in their own audit scope.
Communications and billing
Twilio, Resend, and Dodo process the minimum contact, message, delivery, or transaction data needed for their service.
Local processing and AI
PDF text extraction and Tesseract OCR execute in the accounting firm's browser after decryption. Browser code and worker assets may be delivered by third-party content networks, but the document is processed locally by those browser workers.
The Gemini-powered assistant is a separate operational tool. User-entered chat messages, firm context, and tool results can be sent to Google to generate responses. The current agent route does not intentionally attach document files.
Assumptions and limitations
- DocuChase has not represented that it has completed an independent SOC 2 examination.
- Client-side encryption does not protect plaintext after an authorized user decrypts or downloads a document.
- A compromised browser, device, vault password, or authorized account can defeat controls at that endpoint.
- Message delivery requires providers and telecommunications networks that receive contact and message metadata.
- The Gemini-powered firm assistant processes user-entered prompts and tool results; document files are not intentionally attached to that model route.
Evidence requests
For security questionnaires, architecture questions, or a scoped provider-document request, contact security@docuchaseapp.com. Availability of third-party audit reports is subject to the provider's plan, terms, and confidentiality requirements.