Security overview

This overview describes the controls and operating scope of the Rylvo platform, including identity, data handling, monitoring, and the current availability of enterprise controls.

For a security questionnaire or to report a vulnerability, see /.well-known/security.txt or write to contact@rylvo.com.

A customer turn enters through a deployed channel or the public API, is authenticated, runs through a single engine loop — context, gates, guardrails, model, tools — and is recorded to the observability store.

• Web dashboard: Firebase App Hosting on Cloud Run. Holds no customer data at rest.
• Engine: Cloud Run. Conversation content transits it.
• Configuration and identity: Firestore — organizations, bots, prompts, guardrails, members, and API key hashes.
• Observability: Cloud SQL PostgreSQL — traces, spans, cost and latency records.
• Vector store: Qdrant, self-hosted on Rylvo's own Google Cloud project — knowledge-base embeddings.
• Background jobs: Cloud Functions.

Data residency: every component runs in us-central1 (Iowa, USA). Rylvo does not offer regional pinning, multi-region replication, or in-region processing elsewhere. This is stated in the DPA and any change will be published there before it takes effect.

Inference runs on the customer's own provider key where configured. Provider keys are encrypted with AES-256-GCM at the application layer, so a provider key is not readable from a database dump alone.

• Firebase Authentication with email/password and Google.
• Email verification is enforced — signup lands on a verification gate before the workspace is reachable.
• Sessions are ID tokens, verified per request server-side. API-key authentication checks revocation on every call.

Authorization is 123 capabilities across 29 areas, enforced server-side. Four organization roles — owner, admin, operator, viewer — plus an agency delegate: an admin inside a client workspace holding the admin set minus the capabilities that would let them seize or bill that workspace. The dashboard hides what a role cannot do, but hiding is not the control.

The full role matrix is generated from the enforcement code itself, and a test fails the build if the published table drifts from it, so it cannot quietly go stale.

Two-factor authentication (TOTP) is live as of 2026-09-12 — enrolment in settings, the challenge on the login path, and per-organization enforcement with a grace period so turning it on does not lock a team out. Enforcement is checked server-side on every authenticated request, not in the browser, and today it is set by us on request rather than from a dashboard control.

TOTP recovery is support-assisted if a device is lost; recovery codes and a second authenticator are not currently available. Organizations enforcing 2FA should nominate an emergency-access owner.

Single sign-on (SAML 2.0) is supported on Enterprise, against any SAML identity provider — Google Workspace, Okta, Entra ID. Domains must be verified by the organization before they can be routed to a provider, so one organization cannot point another company’s sign-ins at an identity provider it controls. Enforcement is applied server-side against the sign-in method recorded in the token, not in the browser, on both the dashboard and the engine API: only a session from the organization’s own configured identity provider satisfies it, so a password session — or one from any other provider — cannot be used. Enforcing SSO requires nominating a break-glass address that keeps password sign-in, and a configuration without one is rejected — if the identity provider fails, the people who could turn enforcement off must still be able to sign in.

SCIM 2.0 user provisioning is available: /Users with filtering, create, update, PATCH and delete, authenticated by an org-scoped bearer token stored hashed. Deprovisioning is a soft delete, so access is revoked while audit attribution survives. A directory sync cannot change a Rylvo role — role writes are refused however they are expressed, because a sync that could set roles could create administrators unattended. SCIM group-to-role mapping is deliberately not offered rather than guessed at.

An organization can configure an idle session timeout in Settings → Security. Member removal revokes sessions and API keys immediately. IP allowlisting, an absolute session lifetime, and a user-facing "sign out everywhere" action are not currently offered.

• Stored as SHA-256 hashes. The plaintext is shown once at creation and is never retrievable.
• Scoped by permission and bound to an environment.
• Revocation is immediate, and verified end to end: a key returning 200 returned 403 key_revoked on its next call.
• Revoking any copy revokes the logical key — the authenticator reads the whole hash group and fails closed on a divergent group rather than trusting the loosest copy.

API keys remain active until revoked; per-key expiry and scheduled rotation are not currently available.

• HSTS: max-age two years, includeSubDomains. Deliberately no preload — that list entry is effectively irreversible and every subdomain must be HTTPS-only first.
• X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin.
• Permissions-Policy: camera, geolocation, payment and USB denied; microphone same-origin only.
• Content Security Policy: deployed report-only with violations logged. Enforcement follows a full week of clean real-traffic reports — deliberately not flipped on a two-day sample.
• Guardrails fail closed: if the evaluator errors, the turn is blocked rather than allowed through.
• SSRF: knowledge-base URL ingest rejects private, loopback, link-local and cloud metadata addresses in decimal, hex, octal and short-form encodings, and re-checks after every redirect.
• Audit log: HMAC-signed, and verification fails closed when the signing key is unset.
• Uploads are validated by their leading bytes, not the declared type or filename — an executable renamed to .txt is rejected.
• Dependency and secret scanning: npm audit over the production tree, pip-audit, and gitleaks over full history, weekly and on any dependency change.

• Retention is plan-aware, with the effective window shown in-product and the option to shorten it below the entitlement. A daily sweep enforces it.
• Person-level erasure is a single action with two modes — Forget, which erases the person and keeps a compliance record, and Delete, which keeps none. The cascade covers the profile and collected fields, sessions and transcripts, the dialectic model and run-log embeddings, traces, the canonical customer record, live conversations and their interventions.
• Organization deletion runs a registry-driven cascade across every data namespace, retaining only financial records under their legal retention period, and has been verified end to end against a disposable organization.
• Data export returns the organization's data across every namespace as a single JSON bundle, and reports any collection it could not read rather than omitting it silently.
• Consent is per-person and layered, from no personalization through to long-term memory, and gates whether a profile may be built at all.

Encryption in transit: the public site uses HTTPS with HSTS. Application database connections use TLS through the Cloud SQL connector. The Cloud SQL instance has no authorized public networks.

Encryption at rest: the managed provider defaults of Firestore, Cloud SQL and Cloud Storage — Google-managed AES-256, with no customer-managed key.

Backups: scheduled Firestore backups are retained for 98 and 14 days. Cloud SQL point-in-time recovery is enabled with 14 retained daily backups. Restore timing has not been established, so no recovery-time target is claimed.

• A public status page at /status, fed by a probe that publishes every five minutes: per-surface state, 24-hour uptime and p95 latency. It names recent failures rather than hiding them.
• Two uptime checks and nine alert policies, each routed to two channels — covering API 5xx, uptime for web and engine, scheduled-job errors, missing database indexes, engine checkpointer degradation, failed web builds, rate-limiter degradation, and browser-side crashes reported by users.
• An incident runbook with severities, triage order and per-service rollback.

Capacity targets are not published. Load testing, a standing staging environment, and third-party error tracking are not currently part of the operating programme.

Rylvo does not currently hold SOC 2 or ISO 27001 certification. A Data Processing Addendum and subprocessor list are available for review.

A Data Processing Addendum and a subprocessor list are published and kept current; material new subprocessors are subject to the objection process described in the DPA.

The pricing page references a support response target. Treat that as the operative commitment rather than an availability SLA — there is no contractual uptime guarantee.

Vulnerability disclosure: /.well-known/security.txt.