Security overview

Encryption in transit

All traffic between your browser and Right at Hand, and between our servers and Google, Supabase and OpenAI, uses HTTPS/TLS.

Workspace isolation and authorisation

• Right at Hand is multi-tenant: every workspace table is protected by database row-level security, so queries can only ever see rows belonging to workspaces the signed-in user is a member of.
• Sensitive operations additionally check membership and role server-side — for example, a shared mailbox can only be disconnected by a workspace owner or admin, and a personal mailbox only by the person who connected it.
• Every server operation runs behind authentication middleware; the browser never talks to the database with elevated privileges.

Credential and secret handling

• Google refresh tokens are stored encrypted in a dedicated secrets vault on the backend, in a private schema separate from application tables, and are never returned to the browser.
• Short-lived Google access tokens are fetched on demand and used in server memory only.
• API keys and other secrets live in server-side configuration only; they are never shipped in the client bundle, and automated checks scan built output for leaks.
• Log sanitisation removes token material before log lines are written.

Least-privilege Google access

The product requests a single Gmail scope (gmail.modify) — enough to read, send and organise mail, and deliberately excluding the broader scope that allows immediate permanent deletion. The permissions actually granted are recorded per mailbox, and anything wider would require going back through Google's consent screen. Details on the Gmail permissions page.

Public endpoint verification

• Gmail change notifications delivered to our public endpoint are verified against Google's published signing certificates before they are processed.
• Scheduled/background endpoints require a server-held shared secret.
• Form endpoints validate input, rate-limit and reject automated submissions.

Audit and operational logs

Significant actions are recorded in an append-only audit log that application roles cannot rewrite. AI usage is metered per workspace. Operational logs are sanitised of credentials, and diagnostic access is limited to authorised personnel.

AI data boundaries

• All AI provider calls happen server-side; the browser never holds AI keys.
• Requests are sent with the provider's conversation-storage option disabled, and chain-of-thought is never requested or stored.
• Attachments are passed inline within the request; the provider is never handed a link into our storage.

No trackers inside the product

The authenticated workspace contains no advertising or analytics trackers. Optional, consent-gated marketing measurement exists only on the public website pages, and automated tests enforce that boundary — including that no Gmail-derived data can ever reach a marketing platform.

What is current vs planned

Everything above is implemented today. We do not yet have formal third-party security assessments, a published incident-response policy or compliance certifications; those are future work, and we will only list them here once they are real. If you need a security detail we have not covered, ask us directly.

Reporting a vulnerability

If you believe you have found a security issue, email sales@upweb.com with "Security" in the subject line. Include what you found and how to reproduce it. Please do not access data that is not yours, and give us a reasonable opportunity to fix the issue before disclosing it publicly. We read every report; we do not currently run a paid bounty programme.