Security
QueryRev AI security Read-only access, isolated workspaces and a plain list of what is not in place.
QueryRev AI reads Google Search Console and Google Analytics 4 through read-only access and cannot change anything in your Google accounts. Each workspace is isolated in the database by row-level security, Google refresh tokens are stored encrypted, and no password, Google token or payment detail ever goes to an AI provider. No third-party audit has been completed.
- In place
- Read-only Google accessEncrypted tokensRow-level security
- Not in place
- Third-party auditSingle sign-on
Updated
Data path
Five hops, and what protects the row at each one.
Search Console API
Google: read-only scope
QueryRev asks only for the read-only Search Console permission, so it can read performance data for the properties you attach and change nothing. You can remove the access in your Google Account at any time.
Railway · United States
Worker: encrypted token
Only the refresh token is stored, encrypted with AES-256-GCM and bound to its workspace and connection, so a copy placed in another row does not decrypt. Only the worker’s database role can read it. The access token it is exchanged for lives in memory for the run and is never stored.
Before anything is stored
Boundary: query strings cleaned
Before a page address is stored, known tracking parameters are removed from its query string, and so is any query parameter whose value contains “@” or is 32 or more hexadecimal characters, since it may be an email address or a token. The path of the address is not inspected. What Google sends is translated to QueryRev’s own format and validated here.
Postgres on Neon · AWS, United States
Database: row-level security
The row is written with its workspace’s id. Row-level security makes the database itself refuse a read or a write from any other workspace. The connection is encrypted and its certificate verified, and the provider encrypts stored data at rest.
Web app on Vercel · HTTPS
Your screen: workspace on every read
Every query the web app runs on workspace data runs inside the signed-in member’s workspace, and its database role cannot read the token column at all. The page reaches your browser over an encrypted connection.
Not on the path
- Scheduling (Inngest)
- Ids, dates and counts. Never the row.
- Error tracking (Sentry)
- Error reports with personal data removed.
Workspace isolation
Isolation is enforced by the database, not only by application code. Every table that holds a workspace’s data carries the workspace’s id and a row-level security policy.
For an agency, each client workspace is separate in exactly the same way. The rule is tested, not assumed: an automated suite runs the attempts shown here against a real Postgres database, once as the web app’s database role and once as the worker’s, every time the code changes. If one of them succeeds, the build fails.
A second layer limits what each part of the system may touch at all. The web app’s database role cannot read the encrypted token column, and the sign-in service’s role has no rights on search, analytics or crawl data.
Crawler
QueryRevBot visits only sites that were connected by someone who owns them or is authorised to have them crawled. It reads robots.txt before anything else and makes one request a second over one connection.
Only with authorisation
A crawl can be switched on only after a member with the right to manage data sources confirms, per site, that they own it or are authorised to have it crawled. The confirmation is recorded in the audit trail.
robots.txt first
robots.txt is fetched before any page and obeyed under RFC 9309; a group for QueryRevBot takes precedence over the general one. If robots.txt answers with a server error, the host is not crawled in that run. A change takes effect within 24 hours.
One request a second
One connection per host, one request a second. The pace is halved after a 429 or a 503 and when the site answers slowly. Retry-After is honoured up to 10 minutes, and Crawl-delay up to 10 seconds.
It reads and nothing else
GET requests only. It never submits a form, never signs in and never changes anything on a site.
No way into private networks
A link that points at a private or internal network address is refused before any request is made, and the check is repeated at every redirect.
JavaScript runs apart
Pages that need JavaScript are rendered in a separate service, hosted on Fly.io, that holds no customer credentials and has no network access of its own: the crawler fetches every resource a page asks for, under the same rules.
How it identifies itself, and how a site owner can slow it down or stop it, is on the page About Our Crawler.
Hosting and providers
Data is stored and processed in the United States. Each provider that runs a part of the service receives only what its job needs.
The legal detail is in the Privacy Policy, which is updated before a new provider starts to receive personal information. Google is not one of our providers: at your direction, QueryRev retrieves your own data from Google.
QueryRev Intelligence is built on frontier AI models from a major US provider, behind our own Decision Gateway. It is designed to send only the parts of a workspace’s data a task needs, and never a password, a Google token or payment details. The Privacy Policy states what each provider receives.
Data received from Google APIs, and anything derived from it, is never used to train AI or machine-learning models, and it is not sold or used for advertising.
Deletion
A workspace administrator can disconnect a source at any time. This is what the product does, step by step.
The token goes first
After a disconnect, once no other source in the workspace uses that connection, a background job deletes the stored Google refresh token, normally within minutes. If no other QueryRev connection uses the same Google account, the job also asks Google to revoke QueryRev’s access; the token is deleted whether or not Google confirms.
History is yours to keep or delete
By default the stored history stays readable and stops updating. If you choose to delete it, deletion runs 24 hours later, and during those 24 hours an administrator can undo it.
Then the data is removed
After the window, the source’s search, analytics or crawl data is removed. The audit record that the deletion happened remains, with job and cost records; they contain no search data.
A whole workspace, on request
Deleting an account or a workspace is done on request: write to business@queryrev.com from the address on the account, and it is done within 30 days. Database backups keep restore points for no more than 30 days.
Limits
A security page that lists only strengths is not much use. These are the gaps, said plainly.
- Not in place
No third-party audit or certification
No independent security audit has been completed, and QueryRev AI holds no security certification.
- Not in place
No single sign-on
Sign-in is by email and password or with Google. SAML and other single sign-on are not available.
- Not in place
No two-factor authentication
A second factor is not offered for password sign-in.
- Not in place
No self-service account deletion
Deleting an account or a workspace is done on request, within 30 days.
- Not in place
No choice of data region
All data is stored and processed in the United States. Region-resident or private deployment is not offered.
Security FAQ
Short answers first. Ask anything else, or report a security concern, at business@queryrev.com.
Every AI call goes through our own Decision Gateway and is recorded with its workspace and cost.
Is QueryRev AI’s access to Google read-only?
Yes. QueryRev AI asks only for the read-only Search Console and Google Analytics permissions, plus openid and email to show which account is connected. It never asks for permission to change anything in Search Console or Google Analytics.
Can one workspace see another workspace’s data?
No. Every table that holds workspace data carries a workspace id and a row-level security policy, so the database itself refuses reads and writes across workspaces. Automated tests run those attempts against a real database every time the code changes.
How are Google tokens stored?
Only the refresh token is stored, encrypted with AES-256-GCM and bound to its workspace and connection. The web app’s database role cannot read it; only the background worker can. Access tokens are never stored.
Is my data sent to an AI provider?
QueryRev Intelligence is built on frontier AI models from a major US provider, behind our own Decision Gateway, and is designed to send only the data a task needs: never a password, a Google token or payment details. The Privacy Policy states what each provider receives, and it is updated before any provider starts to receive personal information.
Is QueryRev AI audited or certified?
No. No third-party security audit has been completed, and QueryRev AI holds no security certification. Single sign-on and two-factor authentication are not offered either. This page lists what is in place and what is not.
What happens to my data when I disconnect a source?
The Google refresh token is deleted by a background job, normally within minutes, once no other source in the workspace uses the connection. If no other QueryRev connection uses the same Google account, Google is also asked to revoke the access. Stored history is kept unless you choose to delete it; deletion then runs after a 24-hour window in which it can be undone. The audit record of the deletion remains.
Keep exploring