Security

How we protect your data

Boring, battle-tested infrastructure. Row-level security on every table. No AI training on your data. Everything on this page is verifiable in our code.

EFFECTIVE · 2026-04-17UPDATED · 2026-04-17DISCLOSURE · security@restay.ai
In one sentenceBattle-tested managed infrastructure, row-level security on every table, service-role credentials server-side only, and zero model training on your data. We're early-stage — SOC 2 and third-party penetration testing are on the roadmap, not today. A full subprocessor list lives in section 3.

1. Architecture at a glance

Frontend
Next.js 14 · edge-delivered
Backend
Python · FastAPI
Database
Managed relational database
Auth
Managed identity
Payments
Stripe
LLM
Frontier models, routed

Every production request flows frontend → authenticated session → backend → database. There are no direct client-to-database writes. The service-role key lives only in the backend environment and is never shipped to the browser. A full sub-processor list is available on request under a signed DPA (section 3).

2. Data protection

Encryption

  • In transit. All traffic served over TLS 1.3. HTTP requests are automatically redirected to HTTPS at the edge (Vercel).
  • At rest. Storage is encrypted using AES-256. Backups use the same standard.
  • Secrets. API keys and credentials live in environment variables on Vercel (frontend) and the backend host, never committed to source control.

Row-level security (RLS)

Every table in our database has RLS enabled (migration 002_enable_rls.sql). The public anonymous key has zero access to user data. The backend uses the service-role key to read and write on behalf of authenticated users, after verifying the session.

Users cannot read or write another user's listings, audits, or billing state. We re-run the database security advisor after every schema change.

AI and your data

  • No training on user data. We do not fine-tune models on your listings, audits, or messages.
  • Model providers. We route LLM calls across multiple frontier providers. Zero-data-retention mode is used where supported. Specific providers are listed in section 3.
  • Prompt-injection defense. All content fetched from third parties (Airbnb listings, comps, reviews) is treated as untrusted input. Model instructions come only from our server-side system prompt.

3. Subprocessors

We use a short list of third parties to process data on our behalf. Each one is scoped to a single role:

RolePurposeData
Edge hostingFrontend delivery + edge networkRequest metadata, IP addresses
Production databaseStorage + row-level securityUser records, audits, listings
Identity providerAuthentication and session managementEmail, name, password hashes
StripeSubscription billing and invoicingPayment methods (Stripe-tokenized), billing email
LLM routingReasoning for Rev and audit pipelinesPrompt content (listing data, analysis requests)
Market-data providerComparable listings for rate-gap analysisListing URLs, lat/lng
Transactional emailAudit reports, weekly briefings, receiptsRecipient email, audit summaries

We keep the list short on purpose. Adding a sub-processor is a product decision, not a convenience decision. Enterprise customers can request the named sub-processor list under a signed data-processing agreement — email security@restay.ai.

4. Access and audit

  • Human access. Only the core team has production database access. We do not grant read access to contractors or vendors.
  • Session logging. Our identity provider logs every sign-in with IP and user-agent; you can view your own sessions from account settings.
  • API call logging. Every LLM and market-data call is logged to api_call_log with cost, latency, and user attribution so we can spot abuse and runaway spend.
  • Stripe audit trail. All billing events (checkout, subscription change, payment failure) are logged via signed Stripe webhooks.

5. What we have vs. what's on the roadmap

We think it's more useful to tell you what we have than to list certifications we aspire to.

  • TLS 1.3 end-to-end. Enforced.
  • Row-level security on every table. Verified by database advisors on every deploy.
  • No LLM training on user data. Policy-level and vendor-level.
  • Per-user API budget enforcement. Graceful degradation, no surprise overage bills.
  • SOC 2 Type I. Planned for 2026 once we cross the customer threshold that makes the audit useful.
  • Third-party penetration test. Planned before launching automated PMS write-back.
  • Bug bounty. Informal today; formal program later.
  • HIPAA / FedRAMP / PCI-DSS Level 1. Not in scope — we don't handle regulated healthcare, government, or cardholder data. Card data is tokenized by Stripe and never touches our servers.

6. Responsible disclosure

Found a vulnerability? Please tell us before telling anyone else. We'll acknowledge your report within 2 business days and keep you updated as we investigate.

  • Email: security@restay.ai (PGP key available on request)
  • In scope: restay.ai, app.restay.ai, any ReStay-owned subdomain, our backend APIs
  • Out of scope: findings that require social engineering, physical access, or third-party services (see subprocessor list — report those directly to the vendor)
  • Good faith. Don't access or exfiltrate data beyond what's strictly necessary to prove the issue. Don't target other users.

We're small enough that you'll talk to the team directly. We don't pay bounties yet, but we publicly credit researchers who help us (with your permission).

7. Incident response

If a security incident affects your data, we will notify affected users within 72 hours of confirmation, with the facts we know and the facts we don't. We will not delay disclosure to write a better-sounding email.

Legal notifications required by GDPR, CCPA, or state breach-notification laws are sent through our registered contact channels.

8. Contact