Security and trust at Data Workers

1. Architecture and data flow

Where the agents run. The agents run inside the coding tool your engineers already use, Claude Code, Cursor, Codex, OpenCode or another MCP-compatible client, or inside your VPC. There is no Data Workers-operated cloud that your warehouse traffic is routed through in order for the agents to work.

Bring your own model key. You supply the LLM key, from Anthropic, OpenAI or another provider, and it stays on your account. Prompts, schemas, samples and results go to the model account you control, under your agreement with that provider. They do not pass through a Data Workers model account. We do not mark up model spend and we do not meter agent runs.

The open-source core runs entirely locally. The Apache-2.0 core is a set of MCP servers you clone, build and run yourself. It reads, analyses and recommends. It talks to your warehouse with your credentials and to your model provider with your key. Nothing in that path involves us.

Enterprise deployment. These are the commitments published on our pricing page for the Enterprise tier, quoted as such: a dedicated VPC, your own cloud, or on-premise, with SSO and private networking marked Coming. They are what we commit to deliver on that tier, agreed in writing at contract, not a description of infrastructure already running for you.

If your review needs the specifics for your stack, ask. We would rather answer a concrete question about your deployment than have you infer it from a diagram.

2. Governed writes

The question a security reviewer actually has about data agents is what stops one from doing something irreversible at 3am. This is the answer, and it is the same on every tier that has writes at all.

1. 1.Propose first. An agent does not write. It produces a proposed change, in the same form a colleague would open for review: the SQL, the model change, the config diff, and the reasoning that led to it.
2. 2.Sandboxed dry run. The proposal is executed against a dry run or sandbox path where the platform supports one, so the effect can be observed before anything in production moves.
3. 3.Human approval for anything irreversible. A named person approves. Irreversible actions, drops, overwrites, deletions, permission changes, cannot proceed on the agent's own authority.
4. 4.Receipt on every change. Each applied change carries a receipt: the diff, who approved it, when, the blast radius the change was assessed to have, and the rollback path.
5. 5.Provenance in the context graph. The change and its provenance are written into the context graph, so the next agent run knows what happened, who changed it and why, rather than re-deriving it.
6. 6.Audit trail. The receipts form the audit trail. The record of an agent-made change is the same record a human change would leave, and it is queryable after the fact.

The open-source core does not write at all. It reads, analyses and recommends, which is a different and simpler risk conversation.

3. Data handling

We do not train models on your data. Data Workers does not use customer data to train or fine-tune models. We do not operate the model; your provider does, under your account and your agreement with them, and their training and retention terms are the ones that apply to your prompts.

Credentials stay in your environment. Warehouse credentials, model keys and connector secrets are held where the agents run, which is your machine, your coding tool or your cloud. We do not ask you to hand them to us to get started.

This website is a separate matter, and here is what it collects. dataworkers.io runs Google Analytics 4 and Amplitude. Between them they record page views, clicks, and session replay with all form inputs masked by default. We do not set a user identifier in Amplitude. What you type into the demo or contact form is submitted to us by email and recorded in our CRM; it is not sent to Amplitude. You can opt out of both tools by visiting dataworkers.io/?dw_optout=1 once in each browser you use, which sets a local flag that both tools honour, and ?dw_optout=0 opts back in. None of this touches the product: the analytics on this marketing site have no connection to a deployment of the platform.

What we do with personal data from the site is set out in the privacy policy.

4. Compliance status

If a specific report or attestation is a requirement before a pilot, raise it on the first call and we will walk through it with you before procurement.

Two things do exist and you can read them today: our text and data mining reservation and AI usage terms, in the IP and AI usage notice, and our published privacy policy and terms of use.

5. Documents you can request

Ask for any of these and we will turn them around. Nothing here sits behind a portal.

• •Security questionnaire responses. Send us yours, in your format. We complete it rather than returning a standard answer sheet.
• •Mutual NDA. Signed on request, before a questionnaire or an architecture conversation if you prefer.
• •Data processing agreement. Signed on request, ahead of a pilot.
• •Deployment and data-flow walkthrough. A working session with your reviewer, on your stack, covering where the agents run and where the approval gate sits.

For anything not listed here, such as audit reports, ask us on a call and we will tell you plainly what we can provide.

6. Responsible disclosure

If you have found a vulnerability in this site or in the open-source core, tell us. Email hello@dataworkers.io with the subject line Security. Include what you found, how to reproduce it, and how you would like to be credited.

A dedicated security address is coming. Until it is live, the subject line is what routes your report, so please use it.

We ask for the usual in return: give us a reasonable window to fix the issue before publishing, do not access or modify data that is not yours, and do not run tests that degrade the service for anyone else. We will acknowledge your report and tell you what we did about it.

7. Subprocessors

These are the services we use to run this website and to handle a demo or contact request. The list is current as of October 25, 2026.

The product is a different list, and when the platform is self-hosted it is an empty one. In a self-hosted deployment there is no Data Workers-operated subprocessor handling your data, because the agents run in your environment against your model provider. Your model provider is yours, on your account, and is not a Data Workers subprocessor.

8. Request the security packet

We will complete your security questionnaire, sign an NDA or a DPA, and walk your reviewer through the deployment and the approval gate on a call.

• •Ask by email: dataworkers.io/contact
• •Bring your reviewer to a working session: dataworkers.io/book-demo

9. Common questions