Security at JEM

JEM handles mortgage documents — some of the most sensitive financial information a person has. The platform was designed around that fact from the first table in the database, not retrofitted.

Every customer workspace is a separate tenant, and isolation is enforced by PostgreSQL Row-Level Security on every table — the database itself refuses cross-tenant reads and writes, regardless of what application code asks for. Isolation is not a WHERE clause we remember to write; it is a property of the storage layer.

All traffic is encrypted in transit with TLS. Data is encrypted at rest by our database provider (Neon, on AWS infrastructure). Borrower share links use unguessable cryptographic capability tokens that expire automatically and can be revoked instantly by rotating the link.

Every document access, AI action, borrower page view, and delivery is recorded in an append-only audit log with no update or delete path — not even for administrators. This supports GLBA-aligned oversight of who touched what, when.

Document analysis runs on Anthropic's Claude via API — API inputs and outputs are not used to train Anthropic's models. Our AI reads documents and drafts recommendations; every underwriting number (DTI, LTV, risk scores) is computed deterministically in code, and no AI-drafted message is ever sent without explicit human approval.

Clerk (authentication), Neon (database, AWS), Vercel (hosting), Anthropic (AI processing), and — when a customer connects it — GoHighLevel (CRM and message delivery). Each processes only what its role requires.

Security questions or vulnerability reports: christopher71.hall@gmail.com. We respond to security reports as our highest priority.