Vysible asks for read access to your commerce database. That is a bigger ask than most tools make, so this page explains exactly what that access does and does not allow, in enough detail that your developer or hosting provider can check it rather than take our word for it.
Three read-only connections, all of which you create and can revoke:
- Your Magento database. A MySQL user with
SELECTand nothing else, created by you or your host, on your Magento schema only. - Google Analytics 4. Viewer access to one property, granted from your GA4 admin panel.
- Google Search Console. Read access to one property, granted from your Search Console settings.
Nothing is installed on your store. There is no Magento extension, no module, no Composer package and no code running inside your application. Nothing to conflict with another extension, nothing to break during your next upgrade, and nothing to uninstall if you leave. You revoke access by dropping the database user and removing our Google access.
The database account you create is granted SELECT and nothing else. That is the primary boundary, and it is yours to verify rather than ours to assert. Run this against your own database:
SHOW GRANTS FOR 'dashboard'@'%';It should return a single GRANT SELECT line and nothing more. If it returns anything else, the account has more access than we need and you should narrow it.
Independently of that, every connection Vysible opens begins with this:
Sent on every connection, before any querySET SESSION TRANSACTION READ ONLYWhich means the MySQL engine itself rejects any INSERT, UPDATE, DELETE or schema change for the life of that connection. If the account were ever granted more than SELECT by mistake, writes would still fail.
We have no mechanism to write to your store. Not a disabled one. There is no code path in the product that issues a write.
Queries are restricted to Magento reporting tables: orders, order items, credit memos, products, categories, stock and reviews. Anything outside that set is refused.
Magento system and authentication tables are explicitly blocked, including admin_user, admin_passwords, core_config_data and the OAuth tables. A query naming any of them is rejected before it reaches your database.
Customer contact fields are blocked at the query layer. Names, email addresses, postal addresses, telephone numbers, dates of birth and tax identifiers cannot be selected. Against the two customer tables we go further and permit only an explicit list of non-personal columns, so a column added by a future Magento version or a third-party extension is refused by default rather than allowed by default.
Wildcard selects are refused entirely. A query cannot ask for every column and receive personal data it never named.
Individual customers appear only as an internal ID, and only where a count or an aggregate requires it.
A cold dashboard load runs a small number of aggregate queries over a single connection. Repeat views inside the cache window are served from memory and do not touch your database at all. The most expensive query, which resolves category revenue, is cached for an hour because category structure rarely changes.
Every query is bounded by a timeout, so a slow statement cannot sit holding a connection open on your server.
In practice a store with several people watching the dashboard generates a handful of aggregate queries every few minutes, not per click.
We would rather be precise than reassuring here.
The AI executive brief and the priority review targets send aggregated metrics to OpenAI. Revenue totals, session counts, click through rates, category and product level revenue. No customer records.
AI Chat, on the Growth and Agency tiers, runs a read-only query against your database and sends the result to OpenAI so it can phrase the answer. Those results are subject to every restriction above, so they contain no customer contact information.
OpenAI does not train on data submitted through their API.
If the AI is unavailable, both the brief and the review targets fall back to a rule-based version built from the same numbers, so the dashboard still works.
Your Google and Magento credentials are never sent anywhere. They exist only in a configuration file on your deployment's server.
Each client gets a separate deployment: its own process, its own service account on the operating system, its own configuration file and its own user database. One client's deployment cannot read another's configuration or data. Configuration files containing credentials are readable only by the service account for that one deployment.
Servers are hosted with Hetzner in Hillsboro, Oregon, United States. If you are in the EU or UK and need a data transfer agreement, ask and we will put one in place before go live.
Traffic is HTTPS only, with HSTS, a content security policy, and standard protective headers on every response.
We do not store your commerce data. Orders are queried live and held in memory only for the cache window described above, a few minutes for most views and an hour for category revenue, then discarded. There is no copy of your database on our infrastructure and no historical archive of your orders. What we keep on disk is limited to your deployment's configuration and the list of email addresses authorised to sign in, and those disks are not encrypted at rest.
Access is by one-time link sent to an email address you have authorised. There is no password to leak or reuse. Links expire after fifteen minutes and work once. Sessions last twenty four hours.
You control the seat list. Adding or removing a person, or changing their role, takes effect immediately and is recorded in an audit log visible to your administrators.
Each deployment answers only on its own hostname. A request for an unknown host is refused rather than served.
Vysible support holds an administrative account on every deployment, used for setup, debugging and incident response. That account signs in the same way yours do, and every sign-in appears in your audit log. On tiers with AI Chat it can run the same restricted, read-only queries your own users can, subject to every limit described above, and each query it runs is written to that same audit log. Vendor access should be as visible to you as anyone else's.
Administrative access to our infrastructure is restricted and key based. Security updates are applied automatically, and dependencies are pinned to exact versions and checked for known vulnerabilities before each release.
Your database is not exposed to anyone else. The connection runs outbound from our server to yours, and is not proxied, shared, or reachable from the public internet through us.
Deployment databases are backed up daily, verified readable, and encrypted with a key that is not held on the server. Every release runs an automated test suite covering the query restrictions described above.
Vysible is a small operation and it would be strange to pretend otherwise.
We are not SOC 2 certified. If that is a hard requirement for you, we are not the right fit today and we would rather say so now.
A data processing agreement is available on request. We do not publish one because the terms depend on your jurisdiction.
We do not offer a contractual uptime guarantee, and our terms say so plainly. Every client deployment is monitored for availability, we are alerted if a dashboard stops responding, and deployments are backed up daily and restored from the most recent backup if one fails.
If any of the above is a blocker, tell us. We would rather lose the deal than misrepresent what we run.
If your security reviewer needs something not covered here, write to hello@vysible.io and we will answer it directly rather than send a form.