Security

How KeptHaven is built and run

This page is specific on purpose. It describes what protects a homeowner’s records as of September 2026, who can see them, and what we have not done yet. It is written by the person who runs the system. When something here changes, the changelog will say so.

Where data lives

KeptHaven is a Next.js application running on Railway in its us-east region. The database is Postgres, hosted by Supabase in the United States. Files live in Supabase Storage. Both are listed, with everything else that touches your data, on the subprocessor list.

  • Every table that holds a home’s records has row-level security. There is no table where a homeowner’s data sits without a policy deciding who may read the row.
  • Documents, photos and export archives sit in private buckets, delivered through signed links that expire: one hour for a document, 24 hours for an export archive. Brokerage logos and agent portraits are served from a public bucket, as they are on any website; nothing that names or identifies a homeowner is.
  • Sign-in is Supabase Auth with email confirmation on. An unconfirmed address matches nothing in our role lookups, so it cannot inherit an agent’s or a homeowner’s access. Sessions are httpOnly cookies; we do not keep tokens in the browser’s storage.
  • Email goes through Resend. Payments go through Stripe, and card numbers never reach our servers. Errors go to Sentry with request bodies and cookies stripped before an event leaves the server. ATTOM, PermitStack and RentCast receive a property address and nothing else about you. The US Census Bureau geocoder and state parcel services receive a street address and coordinates. Google Maps Platform and Mapbox render imagery. Firebase Cloud Messaging delivers push notifications to the installed app.

Encryption

  • In transit: HTTPS on every route, with HTTP Strict Transport Security set for two years and applied to subdomains. Connections from the application to Supabase, Stripe, Resend and Anthropic are TLS.
  • At rest: Supabase encrypts the database and storage volumes, and on top of that we encrypt every document and photograph in a customer bucket with a key specific to its brokerage before it reaches storage. That key is itself wrapped under a master key that lives only in the application’s server environment, never in the database. A copy of the database alone holds ciphertext, not your files. The one exception is Street View captures of an address, which carry no tenant and no personal information, and are stored as delivered.
  • Secrets: service-role keys and vendor API keys exist only in the server environment. Nothing prefixed NEXT_PUBLIC carries a secret. Integration API keys are stored as SHA-256 hashes and compared in constant time; the plaintext is shown once and never logged.

Who can see a homeowner’s vault

Access is decided by the database, not by the screen. Every table that holds a home’s records carries row-level security, and the policies are written against a memberships table that records who a signed-in person is inside each brokerage. Every protected page and action re-checks role and tenant on the server. Hiding a button is never the control.

  • The homeowner

    The person the home belongs to can read everything in their vault. They are also the only one who can delete a document: there is no staff delete policy on documents, and that is deliberate.

  • The assigned agent

    An agent sees only the homes assigned to them inside their brokerage, and for those homes only the items that are visible: anything the homeowner has shared with them, and anything they placed in the vault themselves. A homeowner’s own upload starts private and stays that way unless they share it. They can upload a document or log a service record on the homeowner’s behalf, which is visible to them from the moment they add it. They cannot remove a document.

  • Brokerage admins

    A brokerage’s admin role can read the same visible records for every home in that brokerage, under the same rule: shared or staff-placed only. They can upload documents. Brokerages that joined before the membership model shipped in late August 2026 had their existing agents carried over with this admin scope, so an older agent account may see the whole brokerage rather than only assigned homes. New agents come in scoped: an email on a brokerage’s roster grants nothing by itself, and an agent who joins a brokerage through an invite sees only the homes assigned to them.

  • KeptHaven staff

    A platform admin role exists for the people who run KeptHaven, and the database lets it read any portal, but only from a session that has passed a second factor check with an authenticator app. A password alone opens nothing. We use the role for support, when a homeowner or a brokerage asks for help, and not otherwise. That is a rule we hold ourselves to, not a technical control, and we would rather say so than imply a gate that does not exist.

  • Service pros

    A vendor never gets a read policy on a home. The only path is a job the homeowner creates, which exposes the address, the county and the job’s own description while the job is active and for 30 days after completion. The homeowner can revoke it at any time, and revocation cannot be undone from the portal. The vendor side of the product is switched off during the pilot in any case.

  • Server code

    The screens brokerage staff use read homes and clients through the same row policies as everyone else. A handful of server routines run with a service role that bypasses row policies: account linking and membership bookkeeping, the audit log writer, exports and deletion, the payment webhook and scheduled jobs, the document and capture pipelines, the integrations endpoint, and the summary that tells an agent what a homeowner has on file (how many records they keep private, that a policy exists and when it renews) without showing the records themselves. They are narrow, they run only on the server, and the key never reaches a browser.

AI and your documents

Document extraction and the assistant run on Anthropic’s Claude models under Anthropic’s enterprise terms, and Anthropic is listed as a subprocessor. What we send for extraction is the document or photo you asked us to read. For the assistant we send your message and the parts of your home file that relate to it, and a question about the whole home sends the whole file.

  • Your documents, photos and conversations are not used to train any model, ours or Anthropic’s, and are not retained by Anthropic beyond the request and whatever short abuse-monitoring window their enterprise terms define.
  • Every AI document read waits for you. The extraction is shown to the homeowner as a proposal, and nothing is filed until they confirm it.
  • Text that arrives from outside, such as a service report posted by a vendor’s software, is passed to the model as untrusted data, never as instructions.

Retention and deletion

We keep a home’s records for as long as the account exists, because that is the product: a file that outlasts the transaction. You can take a copy or end it yourself, without writing to us.

  • Export, at /account. A zip of every record that names you or your homes, as JSON, plus every original file. It is built into a private bucket and delivered as a 24-hour link by email.
  • Deletion, at /account/delete. For a homeowner, deletion scrubs the homeowner record, deletes their files by row wherever they live (documents, captures, photos), sweeps their own upload folders as a second pass, then deletes the sign-in account. For an agent, the seat is released, the membership removed and the account deleted; the portals stay with the brokerage. A brokerage admin can delete only when they are the last staff member, which also cancels the Stripe subscription and suspends the workspace.
  • Deleted rows can persist in the database provider’s backups until those roll off. We keep no separate archive of deleted data.

What we have not done yet

  • No SOC 2 report. KeptHaven LLC was filed in August 2026 and is one person. We intend to pursue SOC 2 when a customer’s procurement requires it and the company can carry an audit honestly. Until then, this page and the subprocessor list are the controls we can show you.
  • No third-party penetration test. We intend to commission one before the pilot opens beyond invited brokerages. What exists today is our own review, a row-level security test script we run by hand against the live policies, and the constraints described above.
  • Our Content-Security-Policy runs in report-only mode while we tighten it. The other security headers (frame denial, nosniff, referrer and permissions policies) are enforced.
  • No dedicated security@ alias, no bug bounty, and no public status page yet. The footer says so rather than linking to a page that does not exist.

Reporting a vulnerability

Write to legal@kepthaven.com with “Security” in the subject. There is no security@ alias yet; when there is, it will be listed here and in the privacy policy. Reports reach Steven Bell directly, and you will get a reply from a person.

  • Include what you found, where, and how to reproduce it. A timestamp or a request id helps.
  • Test against your own account. Do not read, change or keep data that is not yours; if you think you may have reached someone else’s, stop and tell us.
  • We will confirm receipt, tell you what we did, and credit you here if you want that. We do not pay bounties today.
Security · KeptHaven