GreetScribe Security Statement
Version: 2.0
Updated: 2026-09-20
Operator: Qevinto Oy
This statement describes GreetScribe's implemented security architecture. Configuration, deployment verification and operational procedures remain necessary; the presence of code is not proof that every optional control is enabled in an individual deployment.
1. Infrastructure and separation
UpCloud provides core hosting and Managed Databases for PostgreSQL. The recorded core database deployment is in Helsinki, Finland. Admin/control-plane and guest-runtime data use separate database clients and access boundaries. Browser clients access backend-authorised interfaces rather than privileged database credentials.
The legacy Rasa system is not the current guest-serving architecture. GreetScribe uses its own structured conversation runtime with knowledge retrieval and optional AI processing.
2. Authentication and authorisation
Staff/customer authentication uses the self-hosted Better Auth implementation. Supported methods include passwords, multifactor authentication and passkeys; enabled methods and enforced assurance depend on account/deployment policy. Supported federated sign-in is a separate optional configuration.
Backend checks enforce tenant membership, roles, permissions and resource ownership. Guest sessions are distinct from staff authentication. Guest requests are checked against configured origins and tenant/session context. Webhook signatures and replay checks protect the applicable inbound-webhook path; these must not be mistaken for a universal signed-widget-token mechanism.
3. Secrets and external connections
Scaleway Secret Manager and Key Manager support server-side credential management. Application code resolves authorised secret references; credentials must not be included in guest messages, public forms, browser bundles or support screenshots. Revocation and deletion are separate lifecycle actions when an integration ends.
External AI/provider/tool requests have target-validation and request-budget controls. The AI request includes the question and selected knowledge context, which can contain personal information; this is not an automatic anonymity guarantee.
Public endpoints use HTTPS. Database connections in the recorded deployment use encrypted transport; this statement does not claim certificate verification on every internal/database connection. Internal network and certificate settings require operational verification.
4. Abuse, quotas and resource limits
Ingress protection and application rate limits operate alongside authentication, tenant authorisation, input validation and customer quotas. Application rate counters are process-local on relevant paths; they are not a single global distributed limit across every replica.
Database clients use connection pools. Pool presence alone does not establish a complete connection/query timeout budget. External model requests have per-attempt timeouts and bounded retries; a higher-level answer timeout can finish the caller before the underlying operation finishes.
Optional platform AI budgets and visitor/tenant controls can limit resource use. They must be configured and verified; the existence of a limiter is not a guarantee that every quota fault fails closed. See the Billing Policy for charges: a technical overrun is not permission to charge unapproved additional capacity.
5. Diagnostics and operator alerts
Operational error reporting uses an allow-list and removes sensitive request content from its reporting path. Enabled alert adapters are intended for minimal technical event information and operator contact details, not guest conversations or a customer messaging channel.
Qevinto must verify the configured reporting destination and its processing terms before sending personal data. This statement does not represent a monitoring service as enabled simply because its client library is present. Monitoring events are not a substitute for the separate audit trail.
Log scrubbing on one path does not mean all stored conversations, audit records or support material are anonymous.
6. Retention, backups and rights
A scheduled purge handles eligible expired guest conversation/session/contact data using the implemented default 30-day clock. Explicit retention instructions and preservation restrictions require separate handling. Other record classes and development copies are not all covered by that purge.
Managed database backups rotate according to the selected UpCloud service. They do not provide instantaneous selective deletion of an individual guest's record. Availability of backups is distinct from a completed restore exercise or a guaranteed recovery time.
Authorised export and lifecycle tools support privacy operations. Requests can be made through contact@qevinto.com; this statement does not promise a complete self-service guest-erasure interface.
7. Product-development safeguards
Original conversations and separate development copies are subject to Privacy Policy section 4. That section sets limits and prerequisites; it does not assert automatic deletion or anonymisation of every historical exported copy. Shared development material must be genuinely anonymous or otherwise cleared for its intended use.
8. Incident handling and responsibilities
Qevinto investigates relevant incidents and, as processor, notifies the Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Personal Data, under the Data Protection Addendum.
Customers must manage their users, device security, host website and integration permissions; keep information accurate; and promptly report suspected compromise. Send reports to contact@qevinto.com, without including secrets or unnecessary guest data.
This statement is not a security certification, a guarantee of uninterrupted service, or a claim of completed regulatory compliance. Specific service levels apply only where agreed in writing.
Qevinto Oy, Business ID 3583823-3, Sarkakatu 3 F23, 96460 Rovaniemi, Finland. Previous published version.