A security reviewer asks four questions: what stays in the database, what the tool keeps, what the AI model sees, and what the vendor gets. Here are the answers, sourced to the TestGen docs as of TestGen 5.134.0 in October 2026.
What runs where
TestGen is self-hosted. DataKitchen hosts no part of it, per System Architecture and Security. The default install is Docker Compose with two containers: the engine, which holds the UI, REST API, MCP server, and scheduler, and its PostgreSQL database. Enterprise adds a Helm chart for Kubernetes.
TestGen connects with read-only credentials. For a database, profiling, test, and monitor queries run as SELECT statements inside the database engine. Access Requirements lists the grants for each source and states that TestGen never executes INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP. Keep the account read-only anyway, because a custom test runs SQL you write.
Files and DuckDB work differently. A query engine inside TestGen reads CSV, Parquet, and JSON files on a local path, in Amazon S3, or in Azure Blob Storage, and never modifies them. Two cases leave a temporary copy on TestGen’s own disk: each run copies the CSV and JSON files it reads from S3 or Azure, and a run that needs more memory than it has writes part of its data to disk. TestGen deletes the copy when the run ends. The sizing page has the disk numbers.
What TestGen stores
Everything TestGen keeps goes into its own PostgreSQL application database: projects, connections, profiling results, test definitions, run history, schedules, and users. By default that database runs in a container next to TestGen. You can point it at a PostgreSQL server you provide, such as Amazon RDS, Azure Database for PostgreSQL, or Google Cloud SQL.
The architecture page says this database “does not store your data.” That holds for rows and tables. It doesn’t hold for every value. Profiling records statistics per column that come straight from your data: the most frequent values and patterns, minimum and maximum text values, minimum and maximum dates, and for numbers the minimum, maximum, and 25th, 50th, and 75th percentiles. Test results keep a measure and a message, and for a few test types the measure is an actual data value. Tell your reviewer before they find it in the UI.
Sample rows are fetched, not kept. The Source Data button on a test result or hygiene issue queries your database live when someone clicks it. So does Data Preview in the Data Catalog, up to 100 distinct rows. The Issue Report PDF a user downloads includes sample data.
Database passwords and keys are encrypted at rest with AES-256-CBC. User passwords are hashed with bcrypt, and with single sign-on TestGen stores no passwords at all.
What an AI assistant receives
The MCP server runs inside the TestGen engine on the API port, 8530 by default. A client connects with a bearer token tied to a TestGen user. The setup guide names Claude Code, OpenAI Codex, Microsoft Copilot, and Cursor for its OAuth 2.1 sign-in, which issues a one-hour access token and a 30-day refresh token. Enterprise adds personal access tokens, which are long-lived and work until they expire or are revoked. Every tool call runs with that user’s role, so the assistant sees only the projects the user belongs to.
As of October 2026, the Supported Tools page lists 112 tools in eight groups. Most return what TestGen already stores: profiling statistics, hygiene issues, test definitions and results, monitor events, schedules, and scores. Two return rows from your database. get_source_data looks up the rows that match or violate a test or hygiene issue, and get_table_sample fetches sample rows from a table. The docs don’t tie either tool to a specific role.
Many tools write, and they change TestGen, not your database: create_test, delete_tests, run_tests, create_notification_destination, and on Enterprise set_project_membership. The Supported Tools page doesn’t flag them, but DataKitchen’s MCP cheat sheet marks every tool that writes with an orange dot.
Your AI client sends tool output to its model provider. If the assistant calls get_table_sample, those rows go to the provider. So does a column’s list of frequent values. That is the feature, too: in While You Slept, the assistant turns “the email format test is failing” into the 37 customer rows behind it.
To stop it, TestGen Enterprise has source data protection, released October 14, 2026. With it on, get_source_data and get_table_sample stop returning data, and the other tools drop top values, extrema, percentiles, result messages, and calibrated thresholds. Counts, ratios, aggregate and length statistics, structure, and configuration stay visible. Set TG_MCP_SOURCE_DATA_PROTECTION=strict and the source-only tools never appear in the client. A system administrator can instead turn it on in System Settings, where those tools stay listed but refuse to run. The docs add one warning: the REST API still returns source-derived values, so don’t give a compliance-bound agent API credentials.
What DataKitchen receives
No data content. TestGen sends anonymous usage analytics to Mixpanel: installer actions and errors, OS and Python versions, whether sign-in succeeded, an anonymous token, and approximate location. DataKitchen doesn’t receive IP addresses and keeps the events for 365 days. The installer tells you the first time it runs. Opt out with --no-analytics on install or upgrade, or set TG_ANALYTICS=no, which is the switch on Kubernetes.
Support sees logs only when you download and email them yourself.
One optional path does reach DataKitchen. If you connect TestGen to Observability and export, test results go as Test Outcomes events to the Observability API you configure. The docs give https://api.datakitchen.io for Enterprise Observability, alongside self-hosted addresses.
Where alerts go
Notifications go to email through your SMTP server, to Slack through an incoming webhook, to Microsoft Teams through the Workflows app, and to any HTTPS endpoint as JSON. TestGen refuses webhook deliveries to private addresses unless you allow the host. A payload carries names and counts, plus up to 20 failing tests, each with its type, table, columns, and message. It carries no rows. The MCP docs count result messages as source values, so an alert can carry one.
What goes where
| Item | In your database | In TestGen’s PostgreSQL (you host it) | Sent to an AI client over MCP | Sent to DataKitchen |
|---|---|---|---|---|
| Table rows | Yes, read in place | No | Only from get_source_data and get_table_sample; withheld under source data protection | No |
| Counts, ratios, length statistics | Computed there | Yes | Yes, even under source data protection | No |
| Frequent values, minimums, maximums, percentiles | Computed there | Yes | Yes; withheld under source data protection | No |
| Test definitions and thresholds | No | Yes | Yes; calibrated thresholds withheld under source data protection | No |
| Test results and messages | No | Yes | Yes; messages withheld under source data protection | Only if you export to a DataKitchen-hosted Observability |
| Quality scores | No | Yes | Yes | No |
| Users, roles, tokens | No | Yes, passwords hashed with bcrypt | Project members and roles (Enterprise tool) | No |
| Usage analytics | No | No | No | Yes, anonymous, through Mixpanel, unless you opt out |
In Enterprise, PII-flagged values are masked across the application for users whose role has no PII access: Analyst, Business, and Catalog.
How to tighten it
Serve the UI, API, and MCP server over HTTPS. TestGen defaults to HTTP until you configure HTTPS. Open ports 8501 and 8530 to other machines only when you mean to, following Access TestGen from Another Machine. In Enterprise, turn on single sign-on and assign per-project roles. Give each connection its own read-only database user.
For AI clients, sign the assistant in as a user with the Business role, which is read-only with PII redacted. Put only the tables you want exposed in that user’s project. Prefer OAuth’s one-hour access tokens to a personal access token, and revoke a token the day nobody needs it. Turn on source data protection. Leave your client’s tool-approval prompts on, so you see each call before it runs.
The core profiling, testing, and monitoring engine is free and open source. Enterprise adds team access, security, Commercial Pharma tests, source-data controls for AI, and support.
Documentation: System Architecture and Security, Access Requirements, Manage Connections, Size TestGen for DuckDB and File Data Sources, Use an External PostgreSQL Database, Profiling Statistics, Data Catalog, Investigate Test Results, Investigate Profiling Results, MCP Server, Set up the MCP Server, Supported Tools, Access Tokens, Personal Access Tokens, OAuth Clients, API Authentication, Notifications, Anonymous Analytics, Troubleshooting, Connect to Observability, Configure HTTPS, Access TestGen from Another Machine, Configure Single Sign-On, User Access, Manage Projects, Install on Mac/Linux, Install on Kubernetes, Release notes, 14 October 2026