How KeptHaven is built and run

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. A document or photo is never handed out as a storage link: the application reads its row under row-level security, checks that you own it or may see it, decrypts it on the server and streams it from KeptHaven’s own address. The one link we issue is for an export archive, and it expires after 24 hours. 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.

• 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 live in the server environment, and the service-role key also on the operator’s laptop for the maintenance scripts described under Server code below. 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.
• Every week, our build pipeline scans the code’s dependencies for known vulnerabilities and the repository for secrets committed by mistake.

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 home file. 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 home file 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 home file, but the role works only from a session that has passed an authenticator check: row-level security refuses every platform admin read from a session that has not. A password alone opens nothing. There are two exceptions, and we name them. An operator who has lost their authenticator is reset by a scripted procedure, and the reset is logged. An emergency override exists for the authenticator requirement; it is logged, and its use is reviewed. 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, and the key never reaches a browser. They run on the server, and also on the operator’s laptop for a set of named maintenance scripts, each behind a production guard that refuses to touch live data unless the operator names that exact operation.

• A database rule refuses a second platform administrator. There is one, and the database will not accept another.
• Security events, such as an administrator’s authenticator reset, are written to an append-only security event log. That log and the staff access log are kept for as long as the service operates and are never edited or deleted by the application.
• A security posture check runs every night. It confirms there is exactly one platform administrator and that they have a verified authenticator, that every table has row-level security on, and that no customer file sits in storage unencrypted. If any of those slips, it emails the operator.

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.
• An AI document read is shown to the homeowner as a proposal, and nothing from it is filed until they confirm it. The exception is the Home Inbox, where things sent by voice or from the share sheet arrive: an item the model reads with a confidence of 0.6 or higher (on a scale of 0 to 1) is filed automatically, and everything else waits for the homeowner.
• 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.

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, from Account settings once you are signed in. 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, on the Delete your account page. 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 home files stay with the brokerage. A brokerage admin can delete only when they are the last staff member. That suspends the workspace and schedules its Stripe subscription to end when the period already paid for closes, rather than cancelling it on the spot (a subscription whose payment is failing is cancelled at once, so collection stops). A workspace on the twelve-month Brokerage plan cannot be deleted this way; support closes it with you. A subscription bought through the App Store can only be cancelled with Apple, and the page says so before it lets you continue.
• Deleted rows can persist in the database provider’s daily backups until those roll off: 7 days on our current plan, and point-in-time recovery is being enabled. Either way, a deleted row is gone from those backups within 30 days. We keep no separate archive of deleted data.

• No SOC 2 report yet. KeptHaven LLC was filed in August 2026 and is one person. We keep a SOC 2 control set and are preparing for a Type I examination. Until a report exists, 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 today, while one last library incompatibility is removed. Enforcement follows once it is; until then it reports violations and does not block them. 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.

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.
• The written disclosure policy is published at /.well-known/security.txt and in the SECURITY.md file in our code repository.