Security at QVA

Architecture overview

QVA is stateless with respect to Quickbase record content. QVA's database stores account metadata, encrypted tokens, and schema configuration, but never Quickbase record data. Records are fetched on demand, used to complete the user's request, and are not stored. The data flow is:

• Ephemeral, serverless compute. Both the frontend and API run on Google Cloud Run as stateless containers that scale to zero. There are no long-lived servers, no SSH surface, no interactive shell access, and no persistent disk — even in-memory data is discarded when a container is recycled.
• No record caching. Quickbase records are fetched on demand and returned to the browser. They are never written to our database or file system.
• Two deployment models. SaaS (hosted by us) and self-hosted (deployed in your infrastructure). The self-hosted model gives you full control over networking, identity, keys, and data residency.

What QVA stores / does not store

What we store

• Your account — email, name, OAuth provider, and which organization you belong to.
• Your Quickbase realm and a connection token — the token is encrypted at rest using Google Cloud KMS. The encryption is bound to your user ID (additional authenticated data), so a token can't be decrypted as a different user even if a database were compromised.
• Your schema choices — which Quickbase apps, tables, and fields you've enabled for voice entry. This is configuration, not your records.
• A monthly command count — how many voice writes your org has made this month, for billing.

What we do NOT store

• Voice audio. Audio is sent server-side to OpenAI's Whisper API for transcription, then immediately discarded. Neither QVA nor OpenAI retains the audio after the request completes.
• Transcripts. The text we extract from your speech is never written to disk after the request completes.
• Your Quickbase records. Records are read from and written to Quickbase directly. We don't keep copies.

Authentication & access control

OAuth 2.0 only

QVA does not have a username/password login. All authentication is handled via OAuth 2.0 with Google Workspace or Microsoft Entra ID. Personal consumer accounts (Gmail, Outlook.com, Hotmail) are blocked at sign-in — only business-domain accounts are accepted.

Session management

• JWT tokens are cryptographically signed and stored as HttpOnly cookies — never in localStorage or accessible to JavaScript.
• Tokens include issuer and audience claims that are validated on every request by both the frontend and API, preventing token misuse across services.
• Tokens expire after 1 day. Re-authentication is required after expiry.
• Token revocation on logout. Each token carries a unique identifier (jti). Logging out revokes the token server-side, so it cannot be reused even before its natural expiry.
• A configurable inactivity timeout logs users out after a period of no interaction.

Quickbase user token security

QVA uses your Quickbase user token, not a service account. This has two important security consequences:

1. Permissions match yours. QVA uses the connected user's Quickbase token, so Quickbase permissions remain the source of truth. If a user cannot access a record in Quickbase, QVA cannot access it on that user's behalf — this is enforced by the Quickbase API, not by QVA.
2. Audit trails name you. Records you create or edit through QVA show up in Quickbase as created or modified by you, not by a generic “QVA service” account.

Your Quickbase token is encrypted with Google Cloud KMS using AES-256-GCM. The encryption uses Additional Authenticated Data (AAD) bound to your user UUID, meaning a token cannot be decrypted for a different user even with full database access.

Roles

QVA has two roles: Admin (manages organization settings, invites users, manages subscriptions) and User (voice operations only). The first user from a domain becomes the admin.

Encryption

In transit

• All traffic is encrypted with TLS 1.2+.
• Strict Transport Security (HSTS) is enforced across all domains and subdomains.
• HTTP requests are automatically redirected to HTTPS in production.

At rest

• Quickbase user tokens are encrypted with Google Cloud KMS using AES-256-GCM with AAD bound to the user's UUID.
• Cloud SQL (PostgreSQL) uses Google-managed encryption at rest by default.
• JWT signing keys and API secrets are stored in GCP Secret Manager, not in environment files or source code.

Network & infrastructure

• Google Cloud Run — serverless containers with no SSH access, no persistent disk, and automatic scaling to zero. Region: us-central1.
• Cloud SQL — PostgreSQL with private networking (Cloud SQL Auth Proxy / Unix socket connection from Cloud Run). No public IP exposure.
• Security headers — X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (camera, microphone, geolocation restricted).
• CORS — limited to approved QVA production origins. Arbitrary origins are not allowed.

AI processing

QVA uses two external AI services: OpenAI Whisper for speech-to-text transcription and Google Gemini for converting the transcribed instruction into structured Quickbase field values.

Speech-to-text (OpenAI Whisper)

• Server-side transcription. Audio is recorded in the browser and sent to QVA's Next.js server, which forwards it to OpenAI's Whisper API for transcription. The audio is never written to disk — it exists only in memory for the duration of the request.
• No model training on your data. OpenAI does not use data submitted via its API to train models (opt-out by default for API customers).
• Zero retention by OpenAI. Per OpenAI's current data controls, the Whisper API endpoint has zero abuse monitoring retention and zero application state retention ( OpenAI's data controls).
• No persistence by QVA. QVA does not write audio or transcripts to disk. They exist only in memory for the duration of the request.
• Input validation and rate limiting. The transcription endpoint enforces a MIME type allowlist, a 5 MB file size cap, per-user rate limiting (with Retry-After headers), and requires an active subscription.

Structured data extraction (Google Gemini)

What is sent to the model

Each AI request may include the user's transcribed instruction, relevant table and field metadata (names, types, choices), and — for record updates — the current values of the fields being edited. QVA does not send unrelated Quickbase records, full app exports, or bulk table data to the model.

Data handling

• No model training on your data. Under Google's paid Gemini API terms, prompts and responses are not used to improve Google products or train models.
• Limited retention by Google. Google may retain prompts and responses for up to 30 days for abuse monitoring, security, and legally required disclosures (per Google's Gemini API terms).
• No opt-in to data sharing. QVA does not opt in to Gemini log sharing, datasets, or feedback programs for model improvement.
• No persistence by QVA. QVA does not write prompts or AI responses to disk. They exist only in memory for the duration of the request.

For organizations requiring AI processing inside their own environment, QVA's Enterprise self-hosted deployment can be configured to use customer-controlled infrastructure, keys, and data residency controls. See Enterprise.

Data residency & retention

• Region: All SaaS infrastructure runs in us-central1 (Council Bluffs, Iowa, USA).
• No record caching. Quickbase records are fetched on demand and returned to the browser. They are never written to our database.
• Audio: Sent to OpenAI's Whisper API for transcription, then immediately discarded. Neither QVA nor OpenAI retains the audio after the request completes. Audio is never written to disk.
• Account deletion: Upon account deletion, all user data (account info, encrypted tokens, schema configuration) is removed within 30 days.

Incident response

If you discover a vulnerability or suspect a security incident:

• Email security@tryqva.com.
• Acknowledgment: within 1 business day.
• Triage and initial assessment: within 48 hours.
• We will provide status updates as the investigation progresses and notify affected customers if a breach is confirmed.

Subprocessors

QVA does not use additional subprocessors to process customer data beyond the services listed above.

Compliance posture

QVA's architecture is built around SOC 2 and ISO 27001 control families: AES-256 encryption at rest and TLS in transit, least-privilege access, native Quickbase audit history for created and edited records, no persistent data beyond what's needed to operate, and ephemeral serverless compute with no SSH surface.

Formal third-party attestations are on our roadmap. For customers with strict compliance requirements, the Enterprise self-hosted deployment can be operated inside the customer's existing cloud, network, identity, logging, and compliance environment. See Enterprise.

Enterprise add-ons

Available as add-ons for any SaaS plan, or included in the self-hosted deployment:

For full details on enterprise capabilities, see the Enterprise page.

Reporting a security issue

Email security@tryqva.com. We respond within one business day.