Data processing and access
Last updated: 11 August 2026
This page describes how Turnado processes your project data on your instruction: which parties are involved, which access we ask for and why, and what we may and may not do with your runs. It is the factual basis under the processing agreement, not a replacement for it.
Controller and processor
For the content of your projects your organisation is the controller and we are the processor. We process on your instruction and for no purpose of our own, with one exception that requires your explicit permission: improving Turnado‑1, described below and switchable at any time.
A processing agreement under article 28 GDPR is part of the contract. [[Link to the signed agreement, or how to request it.]]
Sub-processors
These parties may process your data on our behalf. Which model providers actually come into play depends on the models your organisation chooses.
| Party | Role | Region |
|---|---|---|
| Mistral | Inference for Turnado‑1 and for EU model choices | EU (France; Scaleway Paris/Amsterdam) |
| Anthropic | Inference for Claude models, when chosen | [[region per contract]] |
| OpenAI | Inference for GPT models, when chosen | [[region per contract]] |
| [[hosting provider]] | Application hosting and database | [[region]] |
| Mollie | Payment processing | EU (Netherlands) |
| [[mail provider]] | Transactional email | [[region]] |
We announce a new sub-processor before it goes live, so that you can object. [[How we announce: email to administrators, or this page with a subscription.]]
Which access we ask for, and why
Turnado only works if it can reach your repository. We ask for the narrowest access that still does the job, and every item below is there because a specific feature needs it.
| Access | What we do with it | Why it cannot be narrower |
|---|---|---|
| Read repository contents | Build the context for an agent: the files a task touches, conventions, the code map | An agent that cannot read the code cannot reason about it |
| Create branches and commits | Put a proposed change on its own branch | Proposals have to live somewhere before a person can review them |
| Open and read pull requests | Deliver the work as a reviewable pull request and follow the review | The review is where a person decides; without it there is no gate |
| Read checks and CI results | Show whether the gates pass | A green board with a red build is a lie |
| Webhooks | Notice a push, a comment or a finished build | Otherwise we would have to poll, which is slower and noisier |
- We never push to your default branch. Work lands on its own branch and goes through a pull request.
- We do not merge on your behalf. Merging is a human decision.
- A CI token is scoped to one organisation and can be revoked at any time.
- You can withdraw the connection whenever you like; the board keeps working, the code work stops.
What we may do with your runs
A run is one piece of work by an AI colleague: what went in, what it did, what came out, and how it was judged. What may happen with it depends entirely on the permission setting, and the boundary is enforced in code rather than in this text.
| Permission | Kept for your board | Figures for improvement | Content for improvement |
|---|---|---|---|
| None | Yes | No | No |
| Figures only | Yes | Yes | No |
| Full | Yes | Yes | Process work only |
Security incidents
If a breach affects your data we tell you without undue delay and within 72 hours of becoming aware, with what we know, what we are doing and what you can do. Details are on the security page.
Last updated: 11 August 2026.