Security

1.1 Amvio is three parts: a dashboard where customers configure the agent, an API that runs sessions and processing, and an embeddable widget that runs inside the customer's product. There is one widget and one embed snippet.

1.2 The widget holds a publishable embed key only. Every privileged operation happens server-side; no secret capable of reading data is ever present in a browser.

2.1 Isolation is enforced in the database, not in application code. Row-level security policies key every table to organisation membership, so a query issued with a user's credentials cannot return another tenant's rows even if the application asks for them.

2.2 Mutations to organisations, memberships and invitations run through privileged database functions rather than direct table writes. Those tables grant no insert, update or delete rights to ordinary users at all, so the invariants — every organisation keeps an owner, an invite can only be accepted by its addressee — hold in one place rather than being re-checked by each caller.

3.1 Authentication is email and password, with cookie-based sessions refreshed server-side. There are no social or SSO buttons because none is wired up — a control that cannot work is worse than its absence.

3.2 Roles within a workspace are owner, admin and member. Owners and admins can change how the agent behaves toward end users, including how far it acts alone.

3.3 Return paths after sign-in, sign-up and email confirmation are validated against a same-site allowlist, so a crafted link cannot redirect a freshly authenticated user off-site.

4.1 Two server-side secrets exist: an identity secret used to sign assertions about who an end user is, and an API secret. Both are generated server-side, never sent to the browser, and cannot be read back after generation — only rotated.

4.2 Identity assertions are verified with a constant-time comparison, so a forged signature cannot be discovered by timing. Each key carries a derived identifier, and rotation runs an overlap window so a customer can roll a secret without dropping live sessions.

4.3 Without a signed assertion from the customer's own servers, a session is anonymous. Amvio cannot be told who someone is by the browser alone.

5.1 All traffic runs over TLS. The API must be served over HTTPS in production; the browser blocks it otherwise as mixed content.

5.2 Data at rest is encrypted by the managed database and storage providers. Uploaded files are stored under a per-organisation path convention enforced by storage-level policy, so a path outside your own organisation is rejected rather than merely unused.

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

6.1 Both are off by default and only a customer can turn them on.

6.2 Screen awareness is inbound only. Frames travel from the widget to the model. Nothing is returned to the page: Amvio cannot click, type, scroll or change anything in your product.

6.3 Audio and screen frames are processed by Google — see the sub-processor list. This is the most consequential data flow in the product and the reason your own notice to end users has to mention it.

7.1 Schema changes are applied by migration as part of deployment, and a failed migration aborts the rollout rather than letting un-migrated code serve traffic.

7.2 Tests run against a disposable local database guarded by an explicit safety check that refuses any target that is not a local test instance. Production credentials are not used in development.

7.3 Client-side errors are reported to a first-party endpoint. There is no third-party analytics or session-replay script on the dashboard or in the widget.

8.1 No SOC 2, ISO 27001 or comparable certification. None is in progress. If your procurement process requires one, Amvio will not pass it today.

8.2 No third-party penetration test and no independent security audit has been carried out.

8.3 No bug bounty programme. Reports are welcome at hello@amvio.ai and handled directly, but there is no managed programme or reward.

8.4 No customer-managed encryption keys, no data residency choice, and no single-tenant deployment option.

8.5 No SSO, SCIM or enforced MFA for dashboard accounts.

8.6 No self-serve audit log export and no self-serve deletion of an individual conversation. Both are handled by request.

8.7 Amvio is an early-stage product. This list is honest rather than flattering, and it is the list to base a risk decision on.

9.1 Email hello@amvio.ai with enough detail to reproduce. We aim to acknowledge within two business days.

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