Security

1.1 Amvio has three parts: a dashboard where customers configure the assistant and review activity, an API that runs sessions and processing, and a widget that customers embed in their product with a single script.

1.2 The widget holds only a publishable embed key. All privileged operations run on the server, and no credential capable of reading customer data is sent to an end user's browser.

1.3 The assistant guides users by speaking and by showing where to act. It cannot click, type, submit, scroll or navigate in the customer's product.

2.1 Each customer's data is scoped to its organisation. Dashboard access is enforced in the database through row-level security policies tied to organisation membership. The API verifies that the caller belongs to the workspace before every operation.

2.2 Changes to organisations, memberships and invitations are made only through controlled database functions that enforce ownership and invitation rules.

3.1 Dashboard users sign in with email and password. Sessions are held in cookies and refreshed on the server.

3.2 Workspaces have three roles: owner, admin and member. Owners and admins manage the team and configure the assistant, including its tone, the subjects it must avoid, and how it responds when it does not know an answer.

3.3 Redirects after sign-in, sign-up and email confirmation are limited to addresses on the Amvio site.

4.1 Customers can identify their signed-in users to Amvio with a signature generated on their own servers using an identity secret. Signatures are verified with a constant-time comparison, and secrets can be rotated with an overlap period so live sessions are not interrupted.

4.2 Identity and API secrets are generated on the server and are never sent to the widget or to an end user's browser.

4.3 Without a valid signature, a session is anonymous.

5.1 All traffic to Amvio is encrypted in transit with TLS.

5.2 Data is stored with Supabase and encrypted at rest by the provider.

5.3 Uploaded files and session recordings are kept in private storage. Files are stored under a per-organisation path enforced by storage policy, and recordings are available only to members of the workspace through short-lived signed links.

5.4 The API sets standard security headers, restricts cross-origin requests, and applies rate limits.

6.1 Voice.Before asking for the microphone, the widget shows a notice covering microphone use, recording and retention, with a link to the customer's privacy notice. It is shown in the end user's browser language where a version exists: Amvio's default wording is available in seven languages, and customers can add their own wording per language. End users may continue with voice or type instead, and the time of acceptance is stored with the session together with the exact wording, link and language shown. The notice cannot be disabled; its wording and link can be customised.

6.2 Indicator. Whenever a session is recorded or the screen is shared, the widget shows an indicator at the top of the page. It includes a control that ends screen sharing immediately; the conversation continues by voice.

6.3 Screen.Customers can turn screen sharing off or allow it only on listed pages; sharing stops when the user leaves an allowed page, and the API discards any screen image received from a page where sharing is not allowed. Where it is allowed, the assistant sees an end user's screen only when the user shares it through the browser's screen-sharing prompt. The description of the last screen used after a session is taken only from an image that passed these checks. While sharing, one image every two seconds is sent for processing; individual images are not stored. Without screen sharing, only the page address is received.

6.4 Recordings.Unless the customer turns recording off, the session's audio is recorded while the microphone is in use, with a video of the screen if it is shared. When recording is off, the API refuses recording uploads. Recordings are stored separately from transcripts, deleted automatically after the period the customer chooses (7, 30 or 60 days), and can be deleted sooner on request.

6.5 Voice, typed messages and screen images are processed by Google, which provides Amvio's AI models. See the sub-processor list.

6.6 Customers are responsible for informing their end users that sessions are recorded and for obtaining any consent required.

7.1 Recordings are deleted automatically after the period the customer chooses (7, 30 or 60 days). Other customer data is kept for the life of the workspace. Customers can request deletion of a conversation, a recording, or a whole workspace, and an export of their data, at hello@amvio.ai; we complete these requests within 30 days. Retention is described in full in the Privacy Policy.

8.1 Database changes are applied through versioned migrations during deployment, and a failed migration stops the release.

8.2 Development and testing use separate databases. Production credentials are not used in development.

8.3 Errors are reported to Sentry with the error, the request address and browser details, but not conversation content. Page views on the website and dashboard are counted with Vercel Web Analytics, which uses no cookies. No third-party session-replay tools are used.

9.1 Amvio does not currently hold SOC 2, ISO 27001 or similar certifications, and has not yet undergone an independent penetration test or security audit.

9.2 Single sign-on, SCIM provisioning, enforced multi-factor authentication, customer-managed encryption keys, a choice of data region, and single-tenant deployment are not currently offered.

9.3 A Data Processing Agreement is available on request.

10.1 Report security issues to hello@amvio.ai with enough detail to reproduce them. We aim to acknowledge reports within two business days.

10.2 We will not pursue good-faith research that avoids other customers' data, does not degrade the service, and gives us a reasonable opportunity to fix the issue before disclosure. See clause 6.1 of the Acceptable Use Policy.