Security at Kin

How Kin protects your data and what you control. Questions: contact@thinkingdbx.com.

Where Kin runs

Kin is a cloud service operated by ThinkingDBx Private Limited. The application, its database and your files are hosted by OVHcloud in Germany. Status and uptime are public at kin.thinkingdbx.com/status.

Your data sources

• Read-only by default. Kin can only read a data source until a workspace owner allows writes to it. Even then, each change waits for approval unless you choose otherwise, and an organization admin can require approval for every change or forbid changes entirely.
• Use a read-only database user. The safest setup is a user that can only read. See how to create one below.
• Fixed addresses. Kin connects to your databases from these addresses, so you can allow only them: 57.129.71.152 and 2001:41d0:701:1100::7530.
• Private networks. Databases that aren't reachable from the internet can be queried through the ThinkingLanguage local runner, which keeps the credentials on your machine and connects out to Kin. Ask us to set it up.
• Credentials are encrypted at rest with AES-256-GCM and are never shown back in the app or sent to the AI model.

The AI model

• Kin's included model is currently provided by Groq, Inc. (United States). You can connect your own provider and key instead, and an organization admin can restrict which models kin may use.
• We don't use your data to train AI models.
• Admins can switch on personal-data masking: email addresses, phone numbers, card numbers and national ID numbers in query results, files and web pages are replaced with placeholders before the model sees them, and before they are stored.
• Every figure in a kin's answer is checked against the data it actually retrieved, and numbers for metrics with an approved definition must come from that definition.

Access and accountability

• Workspace roles (owner, editor, viewer) apply everywhere, including the MCP and definitions APIs; tokens act as the member who created them and stop working when that member leaves.
• Optional two-factor sign-in (TOTP) with recovery codes.
• An audit log records every query, change, message, outside call and approval, and every change people make, with who did it. It is kept for 400 days, can be exported as CSV or JSON Lines, and can stream to your SIEM through a signed webhook.
• Organization policy: monthly spending caps, allowed models, which abilities kin have (web, email, Slack, webhooks, outside apps), write approvals, and how long task data is kept.

Platform

• All traffic uses TLS. Backups are encrypted and kept for up to 14 days.
• Code a kin runs executes in a sandbox with no access to other workspaces. Web requests are checked at connection time so kin can't reach internal networks.
• Automated monitoring checks the task runner, the queue, failure rates and the AI provider every minute and alerts our team.
• Changes to Kin are checked by automated type checks and tests before release.

Subprocessors and legal

The companies that process data for Kin are listed on the subprocessors page. See also the Privacy Policy. For a Data Processing Agreement, email contact@thinkingdbx.com.

Reporting a vulnerability

Email contact@thinkingdbx.com with the details. We aim to reply within two working days. Please don't access other customers' data or disrupt the service while testing.

Give Kin read-only access

Create a database user that can only read the data Kin needs, then use it when you add the data source in Kin. Replace the names and password with your own, and limit access to Kin's addresses where your database supports it.

CREATE ROLE kin_reader LOGIN PASSWORD 'choose-a-strong-password';
GRANT CONNECT ON DATABASE analytics TO kin_reader;
GRANT USAGE ON SCHEMA public TO kin_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO kin_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO kin_reader;

CREATE USER kin_reader PASSWORD 'Choose-a-strong-password1';
GRANT USAGE ON SCHEMA public TO kin_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO kin_reader;

CREATE USER 'kin_reader'@'57.129.71.152' IDENTIFIED BY 'choose-a-strong-password';
GRANT SELECT ON analytics.* TO 'kin_reader'@'57.129.71.152';

CREATE LOGIN kin_reader WITH PASSWORD = 'Choose-a-strong-password1';
USE analytics;
CREATE USER kin_reader FOR LOGIN kin_reader;
ALTER ROLE db_datareader ADD MEMBER kin_reader;

CREATE ROLE KIN_READER;
GRANT USAGE ON WAREHOUSE ANALYTICS_WH TO ROLE KIN_READER;
GRANT USAGE ON DATABASE ANALYTICS TO ROLE KIN_READER;
GRANT USAGE ON ALL SCHEMAS IN DATABASE ANALYTICS TO ROLE KIN_READER;
GRANT SELECT ON ALL TABLES IN DATABASE ANALYTICS TO ROLE KIN_READER;
GRANT SELECT ON FUTURE TABLES IN DATABASE ANALYTICS TO ROLE KIN_READER;
CREATE USER KIN_READER PASSWORD = 'Choose-a-strong-password1' DEFAULT_ROLE = KIN_READER;
GRANT ROLE KIN_READER TO USER KIN_READER;

CREATE USER kin_reader IDENTIFIED BY 'choose-a-strong-password' HOST IP '57.129.71.152' SETTINGS readonly = 1;
GRANT SELECT ON analytics.* TO kin_reader;

db.getSiblingDB("admin").createUser({
  user: "kin_reader", pwd: "choose-a-strong-password",
  roles: [{ role: "read", db: "analytics" }]
})

Create a service account for Kin and grant it:
  - BigQuery Data Viewer on the datasets Kin may read
  - BigQuery Job User on the project (to run queries)

If you later allow a kin to change data, give it a separate user with only the write permissions it needs.