Security

Data storage

• Account and project data: Accounts, projects and members, monitoring items, incidents, memory, audit logs, Cloudflare Tunnel settings and Cloudflare D1 and BigQuery authorizations are stored in a TiDB Cloud database.
• Monitoring state and collected values: Monitoring schedules and the history of values returned by monitor item queries are stored in Cloudflare Durable Objects storage, separated per project.
• Connection strings and integration credentials: Encrypted with AES-256-GCM before storage. The encryption key is managed as a Cloudflare Workers secret and is not kept in the database. Plaintext never appears in the UI, API responses or AI input.
• Encryption at rest: TiDB Cloud and Cloudflare Durable Objects encrypt stored data on their side. Credentials such as connection strings are additionally encrypted by Scandock (see above).
• Retention: Monitor item value history is kept for 30 days on Starter, 90 days on Business and 365 days on Enterprise. Audit logs are kept for 30 days on Starter, 365 days on Business and 3 years on Enterprise. Older records are deleted daily. When a subscription ends, the previous plan's period still applies for 30 days, and the shortest period (30 days) applies after that. AI judgment history is deleted after 30 days. Incidents, investigation records, conversations and memory remain until you delete the connection, conversation, memory or project.
• Storage region: TiDB Cloud, which holds accounts, projects, connection details, incidents and similar data, is in the Tokyo region. Cloudflare Durable Objects, which hold value history and monitoring schedules, are placed by Cloudflare, so their location is not fixed to a region.

Database connections

• Read-only users: Monitoring and investigation use only a read-only user. If you register a connection string that can write, Scandock creates a monitoring user on the spot and confirms that it cannot write before finishing the registration.
• Privileges granted to the monitoring user: Only reading tables and statistics. On PostgreSQL: pg_read_all_data (or per-schema SELECT where unavailable) and pg_monitor. On MySQL: SELECT and PROCESS. On SQL Server: db_datareader and VIEW DATABASE STATE / VIEW SERVER STATE. Privileges that the environment does not allow are skipped.
• Writes blocked at the connection too: On top of the user's privileges, PostgreSQL sessions are fixed to read-only, and SQL Server queries run inside a transaction that is always rolled back. MySQL sessions are also set to read-only, but on databases that don't accept this setting, such as TiDB, writes are stopped by the user's privileges alone.
• Checks on AI-generated queries: Queries written by the AI are checked to be a single read statement before they run. PostgreSQL and MySQL allow SELECT, EXPLAIN, SHOW and WITH (with a SELECT body); SQL Server allows only SELECT and WITH; Cloudflare D1 allows only SELECT, EXPLAIN and WITH (with a SELECT body); BigQuery allows only SELECT and WITH (with a SELECT body). Multiple statements and MySQL/MariaDB executable comments (such as /*! */) are rejected. Each query is cut off after 15 seconds and returns at most 200 rows.
• Admin connection strings: Connection strings that can write are stored encrypted. They are used only to create and drop the monitoring user and to run remediations registered as "run on the admin connection". If you register only a read-only connection string, Scandock never holds a connection that can write (remediations that write are then unavailable).
• Encryption in transit: Connections over the internet to PostgreSQL, MySQL and SQL Server always use TLS (1.2 or later) and always verify the server certificate. Connection strings that turn off encryption or certificate verification (sslmode=disable, ssl-mode=DISABLED, encrypt=false, trustServerCertificate=true and similar) are rejected when you register them. For connections through Cloudflare Tunnel, the tunnel encrypts the path from Cloudflare to your cloudflared. Scandock then talks to the database without TLS, so the hop from cloudflared to the database (inside your network) is not encrypted. Run cloudflared in the same network as the database, ideally on the same machine.
• Source IP addresses: Direct connections are made from Cloudflare Workers, and the source IP address is not fixed. If your database isn't exposed to the internet, or you restrict access with an IP allowlist, you can use Cloudflare Tunnel. cloudflared running in your network connects outbound to Cloudflare, so you don't need to expose the database to the internet or open inbound firewall ports. For each tunnel, Scandock creates hostnames that are hard to guess on a dedicated domain separate from Scandock's main domain. The database address you enter is written only into the tunnel's configuration and is never published in public DNS. These hostnames are all protected by Cloudflare Access, and only connections carrying a service token held by Scandock can enter the tunnel. The token used to start cloudflared is not stored; it is fetched from Cloudflare and shown only when an owner or admin asks for it.
• Cloudflare D1: For Cloudflare D1, Scandock reads the D1 databases in the account you authorize through Cloudflare OAuth, using the Cloudflare API. D1 has no database users, so instead of a read-only user Scandock requests only read permissions (D1, account analytics and account settings). Cloudflare itself rejects writes, and Scandock confirms at registration that writing actually fails. Permissions are granted per account rather than per database, so every D1 database in the authorized account becomes readable, but Scandock monitors and investigates only the database you register. The refresh token received from the authorization is stored encrypted; access tokens, which expire after one hour, are not stored. You can revoke the authorization at any time from your profile in the Cloudflare dashboard.
• BigQuery: For BigQuery, Scandock reads BigQuery in the project you choose through the BigQuery API, with the permissions of the Google account you authorize through Google OAuth. Scandock requests only permission to read BigQuery. Google itself rejects writes, and Scandock confirms at registration that writing actually fails. Scandock can read the data the authorizing Google account can see. To narrow that, authorize with a Google account dedicated to monitoring that has only permission to run jobs in the project (BigQuery Job User) and to read the datasets you want monitored (BigQuery Data Viewer). Queries run in the project you choose, and BigQuery charges for the data they read go to that project. Data billed per query is capped at 1 GiB, and BigQuery refuses to run queries that would exceed it. The refresh token received from the authorization is stored encrypted; access tokens, which expire after one hour, are not stored. You can revoke the authorization at any time from "Third-party apps & services" in your Google Account.

Writes and approval

• Only registered remediations: Remediations that write are limited to those registered in advance by a project owner or admin. AI only picks from them and proposes one; it never composes and runs arbitrary writes.
• Approval required: By default, running a remediation requires approval by an owner or admin. Remediations that run on the admin connection always require approval. Only remediations that do not use the admin connection, and for which an owner has explicitly enabled auto-execution, run without approval.
• Records: Queries run by AI, decisions and their reasons, approvals and rejections, and execution results are all kept on the incident.

Data sent to AI

Scandock uses the OpenAI API. To design monitor items, judge anomalies, investigate causes and answer chat, it sends connection names, schema information and database annotations, monitor item definitions and values, past incidents and their outcomes, queries run by AI and their results, memory, and your instructions and questions. Connection strings are never sent.

Text values in your tables, such as names and email addresses, are masked before anything is sent to OpenAI. Numbers and dates, table and column names, connection states, and what you write in chat are sent as they are. Under OpenAI's API terms, data sent is not used to train models by default.

Only what each monitoring or investigation step needs is sent to OpenAI. Investigation conversations are sent with store: false, so their state is not kept on the OpenAI side. Under OpenAI's API terms, data sent may be retained by OpenAI for a limited period (up to 30 days) to monitor for abuse.

Data is sent to AI only for monitoring and investigating your databases. Your data is not used to make judgments for other customers or to train Scandock's own AI.

Accounts and roles

• Email verification: You cannot sign in until you open the verification link.
• Passwords: 8 to 128 characters, stored hashed. Reset links expire after 1 hour.
• Two-factor authentication: You can turn on two-factor authentication (TOTP) with an authenticator app, plus backup codes, from your account settings. The authenticator key and backup codes are stored encrypted. After repeated failures, verification is temporarily refused.
• SSO: On the Enterprise plan, members can sign in with their company accounts through SAML 2.0 or OpenID Connect IdPs (Microsoft Entra ID, Okta, Google Workspace and others). An IdP cannot be used to sign in until ownership of the email domain is confirmed with a DNS TXT record.
• SCIM: On the Enterprise plan, IdPs that support SCIM 2.0 (Microsoft Entra ID, Okta and others) can add and remove members automatically. Only people with email addresses in domains verified through DNS are provisioned. Unassigning or deactivating a user in the IdP removes them from that project. SCIM tokens are stored hashed and shown only once when generated.
• Sessions: Cookies are HttpOnly, Secure and SameSite=Lax, and sessions last 30 days.
• Bot protection: Cloudflare Turnstile is used on the sign-in, sign-up and password reset pages.
• Roles: There are four roles: owner, admin, member and viewer. Only owners and admins can register connections and remediations or approve remediations. Viewers cannot change anything.

Audit logs

Member operations are recorded in the audit log, including adding and deleting connections, creating and deleting Cloudflare Tunnels, inviting members and changing or removing roles, registering and changing actions and notification channels, approving and rejecting actions, dismissing incidents, pausing monitoring, and setting up SSO and SCIM. Members added, updated or removed by the IdP through SCIM are also recorded. The audit log can be searched on screen and exported as CSV.

Data deletion

• Deleting a connection: Scandock drops the monitoring user it created from your database, and deletes the connection string, the connection's monitor items, and its incidents and investigation records.
• Deleting a project: Besides removing the monitoring user, the project's data is deleted: monitoring schedules and collected values, connections, monitor items, incidents, investigation records, conversations, memory, audit logs and more. If a Cloudflare Tunnel was created, the tunnel and its DNS records are deleted too. Tokens received for Cloudflare D1 and BigQuery are deleted as well (revoke the authorizations recorded on the provider side from the Cloudflare dashboard or your Google Account settings).
• Deleting an account: You can delete your account in your account settings. If you belong to a project that has other members but no other owner, or one with an active subscription, you need to resolve that first.

Subprocessors

• Cloudflare: (United States) Hosting, storing monitoring state, sending email, bot protection (Turnstile), request and error logs, connections through Cloudflare Tunnel (tunnels, DNS records and Access), and reading Cloudflare D1 (the D1 API and GraphQL Analytics).
• TiDB Cloud (PingCAP): (United States) Storage of accounts, projects, monitor items, incidents, audit logs and similar data, kept in the Tokyo region.
• OpenAI: (United States) Designing monitor items, judging anomalies, investigating causes and answering chat.
• Stripe: (United States) Subscriptions and payments, consumption tax calculation and invoicing. Card and billing details are entered directly into Stripe, and card details are not stored by Scandock.

Incident details are also sent to the notification channels you configure (Slack, Microsoft Teams, Google Chat, LINE, webhooks and so on).

Contact and vulnerability reports

Send security questions, requests to fill in security questionnaires, and vulnerability reports to support@scandock.ai.