Security Statement

Last updated: 21 May 2026

1. Encryption

• In transit: TLS 1.2 minimum (TLS 1.3 preferred). HSTS enforced on hostpal.co.
• At rest (database): MongoDB Atlas storage-layer encryption using AES-256.
• At rest (file storage): Cloudflare R2 with server-side encryption.
• Channel credentials: Telegram bot tokens, Google Drive refresh tokens, and Twilio sub-account tokens are encrypted at the application layer (AES-256-GCM) before storage. Only the application can decrypt at runtime.
• Access codes & wifi: An optional encrypted secrets store (Property.accessSecrets) holds wifi password + entry codes AES-256-GCM-encrypted at the application layer. Codes hosts paste into property notes or the knowledge base are still subject to storage-layer encryption only; we recommend using the dedicated secrets store going forward.

2. Tenant isolation

The Service is multi-tenant. Every database record is scoped by accountId; property records additionally by propertyId. Every database query and every retrieval-augmented generation (RAG) lookup is filtered by both. An internal security review confirms no cross-tenant or cross-property data path in the message pipeline.

3. Authentication & access control

• Passwords hashed with bcrypt (cost ≥12). We do not store plaintext passwords.
• Email verification required before the bot replies to real guests. Hosts can use the dashboard + sandbox immediately, but live messaging to WhatsApp/Telegram guests is suppressed until the account owner clicks the verification link sent at registration.
• Sessions use signed JWTs over secure HTTP-only cookies.
• Account lockout after 10 failed login attempts in 1 hour (sliding window, per account).
• Roles: owner, manager, property_manager, viewer — least-privilege enforced at the API layer.
• Two-factor authentication is on the roadmap and not yet shipped.

4. Prompt-injection & adversarial-input defences

Guest-sourced text is sanitised before injection into LLM prompts: Unicode normalisation, zero-width character stripping, length capping per field, and pattern-based removal of common injection vectors ("ignore previous instructions", role-override phrases, system-tag tokens). All Host- and Guest-sourced data is rendered into XML-fenced prompt sections with [SYSTEM NOTE] markers so the LLM treats them as reference data, not instructions.

5. Inbound media controls

• Accepted: images (image/*), voice notes / audio (audio/*), location pins.
• Rejected: video, documents (PDF, Office formats), archives, executables, unknown MIME types.
• Size cap: 20 MB per item; oversized uploads are aborted mid-stream.
• Rejected media is not parsed, not OCR'd, and not exposed to the LLM.

6. Logging, monitoring, audit trail

• Structured request logs with correlation IDs (Pino).
• Error monitoring via Sentry (PII scrubbed at the SDK layer).
• Admin actions and sensitive operations are logged to an internal audit trail (retained 2 years).
• Failed authentication and security-probing events on guest channels are counted per conversation and used for adaptive defence.

7. Vulnerability management

• Dependencies scanned for known CVEs in CI (npm audit; Dependabot weekly).
• Critical vulnerabilities patched within 7 days; high within 30 days.
• Coordinated disclosure: [email protected] (RFC 9116 contact published at /.well-known/security.txt). We acknowledge within 72 hours and do not pursue legal action against good-faith researchers acting within our safe-harbor terms.
• A third-party penetration test has not yet been performed.

8. What HostPal is NOT responsible for — Shared Responsibility Model

This section is critical. The Service is a communications and information layer; it is not a physical security service. The Host retains sole responsibility for:

• Physical access control: locks, keys, lockboxes, smart-lock provisioning, key rotation between guests, key recovery.
• Code hygiene: rotating access codes between bookings. A static access code reused across multiple guests creates an unmitigable risk that no software product, including this one, can fully address. HostPal will issue whatever code is configured to the verified messaging channel. If that code is also known to previous guests, cleaners, contractors, or anyone the Host has previously shared it with, those parties retain physical access regardless of HostPal's role.
• Accuracy of property data: Hosts are solely responsible for the correctness of property notes, knowledge base contents, restricted-topic configuration, escalation contact information, and emergency procedures.
• Compliance with local law: short-term rental registration, tax collection, fire/safety requirements, guest registration obligations.
• Insurance: appropriate property and liability insurance for the rental operation.
• Guest identity verification: HostPal verifies a Guest only by the messaging channel they use (WhatsApp phone number, Telegram chat ID). HostPal does not verify whether the human messaging the channel is the named reservation holder. Hosts requiring strong guest-identity binding should use smart-lock providers that issue per-reservation PINs and not rely on chat-based verification alone.

9. Incident response

We follow a documented incident-response process targeting 4-hour triage and 72-hour notification to affected Hosts (GDPR Art. 33 / 34 where applicable). Detection sources include Sentry alerts, Atlas anomaly monitoring, Cloudflare WAF, Twilio / Stripe fraud signals, and inbound coordinated-disclosure reports.

10. Safe harbor for security researchers

If you believe you have found a security vulnerability, email [email protected]. Do not access, modify, or delete data belonging to others; do not disrupt the Service or perform denial-of-service testing; and allow 90 days for remediation before public disclosure. We will not pursue legal action against researchers acting in good faith within these limits.