Chuyển đến nội dung

Security Policy

Last updated:

This document is written in English. Website language settings do not translate its legal text.

1. Scope and assurance

This Policy describes security controls implemented in Vyach’s bot, web dashboard, meeting-processing services and optional backup tooling, and the safeguards that depend on the actual deployment. It complements the Privacy Policy, DPA and Terms. It is not a warranty of absolute security or an independent audit report.

We do not claim SOC 2, ISO 27001, HIPAA certification, an uptime SLA, end-to-end encrypted processing or universal full-disk encryption. A hosting provider’s certification, if any, does not certify Vyach itself. Contractual security and statutory duties remain applicable despite these limits.

2. Processing and data boundaries

Discord delivers voice and relevant account/server events to the bot. The deployed STT service reads temporary meeting WAV chunks from server storage and transcribes them with Nemotron/NeMo. Raw WAVs are not submitted to the OpenAI or Alibaba text APIs for transcription. Necessary infrastructure operators can still process the underlying audio and files.

Model weights are downloaded from Hugging Face and inference is then performed in the deployed STT service. The model-download requests do not include meeting WAVs.

Text inference and embedding use the disclosed AI providers. Transcripts, summaries, prompts, question/reply context and speaker aliases may need to be transmitted for those features. This is not processing exclusively on a user’s device: readable content exists in the authorised services and providers. We do not create a persisted question-and-answer history in Vyach.

Database access and retrieval are scoped to the relevant server and meeting context. Public analytics use a separate self-hosted counter workflow and do not receive meeting content or visitor identifiers. An API URL or container name alone is not a data-residency or encryption guarantee.

3. Discord authentication and sessions

The dashboard uses Discord OAuth with identify and guilds scopes. Discord passwords are not handled by Vyach. Browser-bound, expiring sign-in states protect the callback, and access/refresh tokens are encrypted using AES-256-GCM with authenticated session binding. The database stores hashes of opaque browser session tokens.

Main sessions expire after 30 days or earlier revocation/logout. Authentication cookies are host-specific, HttpOnly and SameSite=Lax, with Secure on HTTPS. Mutating authenticated API requests require an appropriate origin and cryptographic CSRF token. Destructive actions require short-lived confirmations bound to the session, server generation and relevant subscription state.

The owner-analytics host uses a separate session cookie linked to the main session, with a lifetime of at most one day. Its one-use grant expires after 60 seconds; access is checked against configured instance-owner IDs. It does not create a separate publicly registered analytics account. Secure your Discord account, enable its available multi-factor protection and sign out on shared devices.

4. Authorisation and publication

The service evaluates server ownership, current Discord membership/permissions and delegated capabilities when authorising actions. Permission checks do not rely on display-name or avatar caches to preserve revoked access. Configured instance owners have owner-level administration across bot servers, including those they have not joined; that access is privileged operator access.

Payer status provides billing management only. It does not grant settings, export or deletion permission, while independent owner, administrator or delegated permissions still apply. Whole-server deletion and exports require owner-level authority. Search and meeting functions remain subject to their capability configuration and channel publication is subject to Discord’s own access controls.

Published messages can be visible to everyone allowed into their channels, and later channel changes can change that audience. The application cannot make an already downloaded archive private again. Server operators must review delegates, channel recipients and publication settings.

5. Transport and deployment security

Public authenticated deployments require an HTTPS origin; HTTP is allowed for local development. The web application sends anti-framing, content-type, HSTS and restricted content-policy headers. OAuth, grant and export responses use additional no-store and referrer restrictions where appropriate. These controls reduce particular risks rather than eliminate all injection or session threats.

External Discord and configured cloud API connections use their HTTPS interfaces. Internal container-to-container HTTP and database connections are not all TLS-encrypted by default; they require appropriate network isolation and host protection. The supplied configuration restricts several service ports to loopback, but deployment changes must not expose private services or credentials.

Vyach is hosted on an OVHcloud VPS in Beauharnois, Quebec, Canada, with Hebergement OVH Inc. identified in the Canadian service terms. The bot, self-hosted STT, web application and databases run on that host. The host firewall exposes SSH and HTTP/HTTPS; application, database, STT and Umami ports are bound to loopback or the private container network. Administrative deployment access uses SSH keys. The current VPS filesystem is not protected by guest full-disk encryption. Encrypted application backups do not encrypt the live database or the whole provider disk image.

Website and dashboard DNS records are proxied through Cloudflare, including its DDoS protection. Cloudflare terminates browser HTTPS; a separate HTTPS connection to Caddy on the VPS uses certificate validation in Full (strict) mode. The proxy can access traffic it processes. Its network protection can mitigate or challenge requests and is not a guarantee of availability or immunity from attacks. Public website crawling is allowed by the application's robots policy; authentication still protects dashboards and private analytics.

6. Consent, retention and erasure safeguards

Audio capture excludes bots, unknown identities and humans without an accepted server recording preference. Withdrawal stops further capture; unanswered or undeliverable prompts do not grant permission. Consent controls protect capture but do not validate the operator’s legal notices or prevent another person from relaying speech.

Successful transcription results are committed before WAV cleanup. Untranscribed audio has a 24-hour expiry target, with periodic stale-file sweeps. Database leases, transactional erasure, content revisions, export invalidation and durable cleanup queues reduce accidental replay or reconstruction of erased data; retries handle recoverable failures.

Meeting content is subject to configurable server-inactivity retention and Free capacity limits, rather than an unconditional maximum age for every recording. Personal erasure removes attributed data and affected private derived records, then rebuilds remaining transcripts and indexes. A minimal declined preference remains. Published Discord messages, third-party records and downloaded copies have separate lifecycles.

Deletion can wait for ongoing recording or processing and physical file removal can be retried. We do not describe ordinary filesystem deletion as certified secure overwriting. The full retention and rights process is in the Privacy Policy.

7. Export protection

Server exports are prepared as compressed JSON files with restrictive file creation permissions. Only hashes of randomly generated download tokens are stored. A ready archive expires after 24 hours and can be revoked earlier on erasure. Downloading requires Discord sign-in and current owner-level permission in addition to the token.

Export paths and filenames are validated against their storage directory and responses are marked private/no-store. An exported copy remains sensitive: recipients must protect it, avoid sharing URLs and delete copies when no longer needed. Token expiry cannot revoke data someone already downloaded.

8. Backups and recovery

The deployed application backup worker encrypts database archives with authenticated AES-256-GCM. It can also include configured analytics/configuration records. Raw meeting WAVs and generated export archives are excluded; transcript and summary files are rebuilt from retained database records when restoring. Backup keys and configuration material require separate restricted access.

The current schedule is every 24 hours, with an additional application backup before deployment, and retention is seven days. The application supports configuration from one to 30 days. A privacy revision invalidates older archive generations after protected erasure events. Backup creation checks for pending erasures, and restoration checks revision compatibility and empty destinations. These protections must not be bypassed to recover deleted personal data.

Application archives reside on the same VPS; they are not an independent off-site copy. Separately, OVHcloud's daily disk backup captures a restore point of the host disk, potentially including WAVs, generated exports, configuration and keys that the application archive deliberately excludes. Application deletion and privacy revisions do not purge OVHcloud restore points. A disk restore must therefore be reconciled with erasure instructions and current privacy revisions before serving data or restarting processing.

Backup existence, rotation and recovery depend on the worker and deployment actually operating. The feature is optional and is not a promise of uninterrupted backups, an off-site copy, a specific recovery time or immediate physical purge during an outage. Operators must test restores and maintain host storage protection.

9. Content-safe logging and abuse controls

Application logging is filtered through an allowlist of technical events, error types, codes, statuses and permitted identifiers. It excludes raw request/error bodies, arbitrary exception text, transcripts, summaries, question/answer text and credentials. Python STT logging also restricts fields, while retaining approved numerical diagnostics such as duration and speech-activity measures. Default STT access logging is disabled, and the database configuration suppresses parameter-bearing error logging.

Technical identifiers and diagnostics can still be personal information. Infrastructure and third-party services have separate logging controls; this Policy does not claim a universal 30-day lifetime for all logs or immunity from every future library’s output. Content should not be inserted into debugging output or public support reports.

Question requests are limited to one per person every 30 seconds in addition to plan quotas. Sign-in protections include windowed address-based and global request limits. Queues, bounded payloads, leases and processing limits help contain abuse and crashes. They do not guarantee defence against every denial-of-service attack or constitute proactive content moderation.

10. Incident handling

When we identify a credible security incident, we will assess its scope, contain affected processing, restrict compromised access, preserve necessary technical evidence and take proportionate remediation steps. Where appropriate, this can include credential rotation, pausing features, coordination with providers and review of the underlying cause.

If Customer Data is affected by a personal-data breach, we will notify the relevant controller without undue delay under the DPA, giving available information and subsequent updates. Where we act as controller, we will make authority and individual notifications required by applicable law. Discord or other provider notices will be made where required by their applicable agreements. We do not promise that every incident can be detected immediately or that public announcements precede containment.

A data controller’s applicable 72-hour reporting duty is distinct from a processor’s obligation to notify it without undue delay. We will cooperate with lawful investigations while avoiding unnecessary disclosure of meeting content.

11. Reporting vulnerabilities and incidents

Report vulnerabilities and incidents to inbox@vyach.app. You can also request a private security contact through our support server. Arrange a secure channel before sending confidential details. Provide the affected interface or version, expected and observed behaviour, minimal reproduction using your own test data, approximate time and likely impact. Do not send live tokens, payment data or another server’s transcripts. If sensitive material was encountered accidentally, report the fact without copying it further.

For a lost session or disclosed export link, sign out or use available revocation/deletion controls as appropriate and contact us promptly. For immediate danger or illegal content, use Discord’s reporting and local emergency channels as relevant; a vulnerability report is not an emergency-response channel.

12. Authorised research and disclosure

Limited, good-faith testing may be performed using accounts, servers and data you own or have permission to test, through the public application interfaces, without degrading service or affecting others. Seek written agreement before broader testing, scanning or accessing non-public infrastructure. This Policy grants no permission over Discord, Polar, cloud providers or another person’s account.

  • Do not retrieve, alter, erase or publish another customer’s data, continue exploiting a flaw after minimal proof, or maintain persistence.
  • Do not conduct denial-of-service, resource exhaustion, high-volume scanning, credential guessing, phishing, social engineering or destructive testing.
  • Stop when evidence shows unauthorised access might occur; report privately and use synthetic evidence where possible.
  • Coordinate a reasonable disclosure timeline with us, allowing remediation while respecting any legal reporting or disclosure duty.

We will evaluate substantiated reports and communicate as reasonably practicable. No bounty, fixed response time, legal immunity or permission for otherwise unlawful activity is promised. A required disclosure must not be prevented by an indefinite confidentiality demand.

13. Shared responsibilities and updates

Server operators must choose lawful meeting purposes, provide notices, maintain permission and channel hygiene, verify material AI outputs and secure exported copies. Users must protect their Discord accounts and avoid sharing credentials. Necessary hosting and provider controls must be verified for the actual deployment.

We may update this Policy as controls change, indicating the revision date and communicating material changes where appropriate. An update cannot reduce mandatory obligations or retrospectively cure an unlawful disclosure. Specific contractual commitments in a DPA or written service agreement remain binding according to their terms.

Questions about these measures can be sent to inbox@vyach.app.