Security & trust

Boring where it counts. By design.

This page is not a badge wall. It is a plain description of how the system is actually built: who can see what, who can move money, and what gets written down when anything changes.

The guarantees

In plain words.

Every workspace is a sealed tenant

Every table is tenant-scoped, and row-level isolation is enforced inside the database itself, not just in application code. A bug in the app cannot read another company's rows, because the database refuses to return them.

The books reconcile to zero

The ledger is double-entry: every transaction posts balanced legs, so the whole book sums to zero or something is wrong. A permanent property test asserts that reconciliation on every change to the system, and a database-level check backs it up.

Every state change leaves an audit row

Immutable, and without exception. Human actions record the person. Automated actions record actor "system" plus the id of the exact rule that authorized them. Nothing in the product changes state silently.

Door codes sit behind a dual gate

A smart-lock code goes out only when payment is verified and ID is verified, and the gate is re-checked at the moment of sending, not when the rule was configured. A failed check holds the code with its reason and puts it in front of a human.

Humans gate the money

Approval gates stand in front of everything that moves funds: verifying a payment proof, issuing a refund, releasing a payout. No automation can move money, and no agent rule that moves money can be written.

24 roles, scoped per property

Access control ships with 24 roles, from owner to cleaner, each grantable per property, so a seat sees only the buildings it works. Custom roles carry a hard ceiling: they can never move money and never release door codes.

The supply chain is pinned and signed

Every base image the product runs on is pinned by digest rather than by a tag that can be moved under us, scanned for known vulnerabilities on the way through, and signed so a deploy can prove the image it is running is the image that was built. A dependency advisory published overnight turns the build red the next morning.

The code is scanned against our own rules

Alongside the usual secret and dependency scanning, the pipeline runs a static-analysis pack written for this codebase specifically: the rules encode our own invariants, like money never being a float and a query never escaping its tenant scope, so the class of mistake that would matter most here fails a build rather than a review.

Production access is read-only, and it is a document

Engineers do not hold a shell on the production database. Debugging goes through a fixed-command mechanism backed by a role that can only SELECT, so a support investigation cannot write, and every invocation is logged by the cloud provider rather than by us.

Backups that are tested, not assumed

The database is dumped to encrypted storage every night, and an alarm fires if a dump fails or stops happening. Once a month a scheduled drill restores the newest dump into a throwaway database and checks the ledger in it, so the recovery path is rehearsed rather than hoped for.

Posted books cannot be edited

A posted ledger line is refused any change by the database itself. A mistake is corrected the way an accountant would: with a reversal that leaves the original in place.

Sign-in with no password to steal

Workspace users sign in with an email link bound to the browser that asked for it, with Google or with Microsoft. Before anyone gets in they prove their own mobile number with a one-time SMS code, and an invite never carries one. Sessions last seven days. The internal admin console adds a TOTP second factor.

Rate limits on every public door

Guest-app sign-in, guest-app reads and writes, booking-site searches and enquiries, and API keys each have their own limits, per workspace and per address, shared across every server so a flood cannot slip between them.

API keys and webhooks, built defensively

API keys are stored hashed and shown once, and a key can never hold more than the person who created it. Outbound webhooks are signed with HMAC-SHA256 and a timestamp, and they refuse to call private or internal network addresses.

The AI never sees the keys to the door

Door codes and Wi-Fi passwords are stripped from anything sent to the model behind AI guest replies. Money, refunds, discounts, cancellations, complaints and door codes always wait for a person, whatever the autopilot's confidence.

Logs that do not keep secrets

Application logs pass through a redaction step that scrubs credentials before they are written, and sign-in tokens, codes and email addresses are stripped from the web server's access log, with referrers masked. Production secrets are read from the cloud provider's parameter store at start-up, not baked into the server's launch data.

A content security policy, stated honestly

Every page of the app sends a Content Security Policy in report-only mode: the browser reports what would be blocked, and blocks nothing yet. Enforcing it is planned once the reports are quiet. We would rather say that than imply a protection that is not on.

Transport

Every connection runs over TLS, in the browser and between our own services. Encrypted in transit, everywhere, always.

Card numbers never touch our servers

Card payment is not available yet, so no card number exists anywhere in Stay n Host. When it ships it will run through a PCI-DSS Level 1 processor that holds the card data, and we will store only references. Bank-transfer and cash proofs live as evidence documents inside your sealed tenant.

The audit trail

If it happened, it's written down.

Every booking, payment, message, and door code carries a permanent history of who did what and why. When an agent acts, the row names the rule that authorized it, so an automated action is more accountable than a human one, not less. This is the record you hand an owner, an accountant, or an auditor without flinching.

"Trust the automation because you can read its receipts."

Audit · booking BK-2119immutable
13:58 lock_code.held · payment unverifiedsystem · rule pre-checkin-30m
14:29 payment.verified · proof matchedhuman · ops seat
14:31 lock_code.sent · dual gate passedsystem · rule pre-checkin-30m
Every row above is permanent3 of 3 audited

FAQ

Security questions, answered

Can another customer ever see my data?

No. Every workspace is a sealed tenant: every table is tenant-scoped and row-level isolation is enforced inside the database itself, not just in application code. Even a bug in the application cannot read across tenants, because the database refuses the query.

Do you store card numbers?

No, and today we never see one either: card payment is not available yet, so there is no card number anywhere in the system. When it ships it will run through a processor that holds the card data, and we will keep only references. Bank-transfer and cash proofs are stored as evidence documents inside your own sealed tenant.

Can an AI agent move money or open a door on its own?

Money: never. No automation can move funds, and no agent rule that moves funds can even be written. Door codes: only through a rule your workspace authored, and only after the dual gate passes, payment verified and ID verified, re-checked at the moment of sending. A failed check holds the send with its reason and surfaces it to a human.

Does the AI ever see door codes or Wi-Fi passwords?

No. Before any guest message or property fact goes to the model behind AI guest replies, door codes and Wi-Fi passwords are replaced with a placeholder, both the exact codes on file for the stay and anything that looks like one typed into free text. If a drafted reply still carries something that looks like a secret, the autopilot does not send it. Replies about money, refunds, discounts, cancellations, complaints or door codes always wait for a person.

Who can release a door code?

Only seats holding that specific capability, and it is deliberately scarce. Custom roles have a hard ceiling: no matter how they are configured, they can never move money and never release door codes.

How do I ask a security question or report an issue?

Email hello@staynhost.com with SECURITY in the subject line; the same contact is published at staynhost.com/.well-known/security.txt. Reports get a human reply, and confirmed issues get fixed before they get discussed.

Try the whole platform free for 14 days

Full Growth-plan access. No credit card. Your data stays yours.

Start free trial
From $15/month after. All five prices public.