Security, stated plainly.

This overview describes the controls and operating scope of the Rylvo platform: identity, data handling, monitoring, and which enterprise controls are available today, and which are not.

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.
• Files: Cloud Storage. Uploaded knowledge-base documents and media.
• Background jobs: Cloud Functions.

Data residency: every Google Cloud component above runs in us-central1 (Iowa, USA). Rylvo does not offer regional pinning, multi-region replication, or in-region processing elsewhere. The services named at /subprocessors process data where that list says. 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 the key's status on every call.

Authorization is 134 capabilities across 31 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) has been live since September 12, 2026: enrolment in settings, the challenge on the login path, and per-organization enforcement with a 7-day 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. Today we turn enforcement on for an organization on request; there is no dashboard switch for it yet.

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 on Enterprise: /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 dashboard "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 takes effect within seconds: the engine caches a key lookup for at most five seconds, after which a revoked key is refused.
• 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.

A key can be given an expiry of up to 365 days when it is created through the API; otherwise it stays active until revoked. Scheduled rotation is not currently available.

• HSTS: max-age two years, includeSubDomains. Deliberately no preload on the site: that list entry is effectively irreversible and every subdomain must be HTTPS-only first.
• Framing and sniffing: X-Frame-Options DENY everywhere except the embeddable chat widget, which any site can frame by design; 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: enforced since September 12, 2026, after a report-only period. Violations are still reported and logged.
• 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; Firestore point-in-time recovery is not enabled. Cloud SQL point-in-time recovery is enabled with 14 retained daily backups. No recovery-time or recovery-point target is claimed.

• A public status page at /status, fed by probes that run every five minutes, and by a real question answered end to end every 15 minutes: per-surface state, 24-hour uptime and p95 latency. It names the last failure rather than hiding it.
• Two uptime checks and a set of alert policies covering API 5xx, uptime for web and engine, scheduled-job errors, missing database indexes, engine checkpointer degradation, failed web builds, rate-limiter degradation, browser-side crashes reported by users, the knowledge-base vector store, and any status-page surface that goes down or recovers.
• 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 (/dpa) and a subprocessor list (/subprocessors) are published and kept current; material new subprocessors are subject to the objection process described in the DPA.

The pricing page names a next-business-day target for an Enterprise named contact. Treat that as a response target, not an availability SLA: there is no contractual uptime guarantee.

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