Privacy policy
Last updated 2026-10-19
This policy explains what personal data the hosted Atoma service at atoma.run processes, why, who receives it, how long it is kept, and the rights you have over it. It applies to the website, the web app, the MCP server at https://atoma.run/mcp and the Atoma plugins for Claude and Codex, which connect to that server.
In short. We keep what is needed to sign you in and to run the work you ask for. We use no advertising, no analytics and no tracking cookies, and we do not sell or rent personal data. The content of your requests is sent to the AI model providers that carry out the work. What a run learns can be reused by other users' runs (see shared learning), so do not put confidential, personal or sensitive data in your requests or files.
Who is responsible
The controller of your personal data is Matthieu Foillard, a sole proprietor established in Greece, Pavlou Mela, 1, 15233 Athens, Greece ("we", "us"). For any privacy question or request, write to mgf@atoma.run. We have not appointed a data protection officer.
Atoma is also open-source software. This policy covers only the service we operate at atoma.run, not instances that other people run with the same code.
What we collect
Your account
- Sign-in identity. When you sign in with GitHub, Google or ChatGPT, we receive and store the provider's identifier for your account, your email address and whether the provider verified it, your display name and your profile picture. We fetch the picture once and serve it from atoma.run, so your browser does not contact the provider to show it. For GitHub we request no extra permission scope.
- Organisations and roles. The organisations you belong to, your role in each (owner, admin, member or viewer), invitations you create or accept, and your organisation's plan.
- Access credentials. Sessions, API tokens for the MCP server, and the authorisations you grant to MCP clients such as Claude or Codex. We store only hashes of session tokens, API tokens and refresh tokens, never the tokens themselves.
Your work
- Projects and runs. The goals and acceptance criteria you write, the files and repositories you give a project, project context and decisions, the project conversation, answers you give to questions a run asks, and what each run produces: its trace (the record of each step, including model prompts and responses), its log, its workspace and its delivered files, along with run metadata such as duration, cost and outcome.
- Connections you add. If you connect a GitHub account or GitHub App installation, an organisation's model-provider API key, your organisation's own MCP servers, or a personal Claude or ChatGPT subscription, we store what is needed to use it. GitHub tokens, provider API keys and MCP connection secrets are encrypted at rest (AES-256-GCM). A personal subscription's login is held in a private, access-restricted file on the server.
- Notifications. If you allow browser notifications, we store your browser's push subscription (an endpoint address and its encryption keys) and your language.
Technical data
- Audit journal. We record security and administrative events, such as sign-ins, organisation changes, token creation and revocation, and administrator access, with the account and organisation involved. The journal never contains tokens or the text of your work.
- IP addresses. The application uses your IP address only in memory to limit repeated sign-in and authorisation attempts, and does not store it. Our web server keeps standard access logs, which include IP addresses and browser user agents, for security and troubleshooting.
Why we use it, and on what legal basis
| Purpose | Legal basis (GDPR) |
|---|---|
| Creating and securing your account, signing you in, and managing organisations, roles and invitations | Performance of our contract with you (Art. 6(1)(b)) |
| Running the work you request, delivering the results, previewing them and, when you accept, publishing them to GitHub | Performance of our contract (Art. 6(1)(b)) |
| Shared learning: extracting reusable recipes and trust history from runs, for every user's later runs | Performance of our contract, since shared learning is part of the service (Art. 6(1)(b)), and our legitimate interest in improving it (Art. 6(1)(f)) |
| Reviewing finished runs, including with an AI model, to find and fix defects in Atoma | Our legitimate interest in a reliable service (Art. 6(1)(f)) |
| Security: rate limits, the audit journal, server logs and abuse prevention | Our legitimate interest in protecting the service and its users (Art. 6(1)(f)) |
| Browser notifications | Your consent, given through your browser's permission prompt (Art. 6(1)(a)), which you can withdraw at any time in your browser |
| Answering your requests and meeting legal obligations | Legal obligation (Art. 6(1)(c)) and legitimate interest (Art. 6(1)(f)) |
We do not make decisions about you that produce legal or similarly significant effects based solely on automated processing. Automated decisions inside a run, such as choosing which agent takes a step, concern the work, not you.
Who receives your data
- AI model providers. Requests, files and intermediate work are sent to the model providers that carry out each run, according to the models configured for your organisation or by us. These may include Anthropic, OpenAI, Google, xAI, Meta, Mistral, Alibaba Cloud (Qwen), DeepSeek, Moonshot AI and Zhipu AI (Z.ai). When you connect your own API key or subscription, that provider processes your requests under its own terms with you.
- TypeSafe. Every run uses TypeSafe's Decision model (typesafe.ai) for bounded decisions, such as which agent or recipe takes a step and whether a plan or result can be approved without a model review. For each decision we send its content: the step's task text and constraints, descriptions of the candidates, and the plan or result under review with excerpts of its evidence. TypeSafe processes it under its own terms and may retain it.
- GitHub. If you sign in with GitHub, connect a GitHub App installation or publish a result, GitHub receives what that requires, including the delivered files and a commit message that contains the run's goal.
- Your organisation's own MCP servers, if your organisation connects them, receive the requests that runs make to them.
- Hosting and infrastructure. The service runs on a server rented from Hetzner Online GmbH in Germany. Let's Encrypt issues our TLS certificates, and Gandi provides our domain names. They do not receive the content of your work, except that Hetzner hosts the server that stores it.
- Browser push services. Notifications travel through the push service your browser vendor operates (for example Google, Mozilla or Apple). The content is encrypted end to end and limited to a short status, an excerpt and a link.
- Map tiles. When you open a geographic data file in the file viewer, your browser loads map tiles from OpenStreetMap's tile servers, which then see your IP address.
- Other users. Members of your organisation see its projects and runs. Platform administrators can read across organisations for operation and support. These reads are recorded in the audit journal, and organisation owners are notified. Platform administrators do not read other users' project conversations.
- Authorities, where the law requires it.
We use no email provider. Invitations are links that you pass on yourself.
Transfers outside the European Economic Area
Our server is in the EU. Several of the recipients above, including most AI model providers, GitHub and TypeSafe, process data outside the European Economic Area, including in the United States and, for some model providers, in China or Singapore. Where such a transfer takes place, it relies on an adequacy decision (such as the EU–U.S. Data Privacy Framework, where the recipient is certified) or on the standard contractual clauses or other safeguards that the recipient provides under Article 46 GDPR. Write to us for more information about the safeguards for a given recipient.
Shared learning
Atoma is a shared-learning service. Every run can use the platform's catalogue of agents, learned recipes and trust history, and what a run learns can update them for later runs, including other organisations' runs. Learned recipes can contain code and wording derived from the work that produced them, and there is no individual approval step before they are reused. Your projects, workspaces, traces and files stay within your organisation. A recipe, however, can carry details of the work it came from, and removing a run's data does not automatically withdraw what was learned from it. This is why you should not submit personal, confidential or sensitive data. The terms of service describe shared learning in full.
How long we keep it
- Account, organisation and project data, including project conversations and context, are kept while your account or organisation exists, and deleted on request (see your rights).
- Run traces, logs and workspaces become eligible for deletion 90 days after the run ends. We keep them longer while they are still needed: the latest run a project builds on, a result you accepted, or a publication or continuation that is not finished. Run records and their summary metadata are kept for as long as the project exists.
- Sessions expire after 7 days. MCP access tokens expire after one hour, and an MCP client's authorisation lasts at most 30 days before it must sign in again.
- The audit journal keeps events for 90 days.
- Backups of the service are rotated, so deleted data disappears from them as older snapshots are replaced.
- Data that TypeSafe or a model provider receives is kept according to that provider's own policy.
Your rights
Under the GDPR you have the right to access your personal data, to have it corrected or erased, to restrict or object to its processing, to receive it in a portable format, and to withdraw any consent you gave, without affecting processing that took place before. Some of this is self-service: you can change your display name, revoke API tokens and MCP authorisations, disconnect personal subscriptions, remove provider keys and MCP connections, and turn off notifications. For anything else, including deleting your account, an organisation or a project, write to mgf@atoma.run from the address linked to your account. We answer within one month.
You can also lodge a complaint with a supervisory authority, in particular the Hellenic Data Protection Authority (dpa.gr) or the authority where you live or work.
Cookies and browser storage
We use only cookies that are strictly necessary for the service. All of them are first-party and secure, and scripts cannot read them.
| Cookie | Purpose | Lifetime |
|---|---|---|
__Host-atoma_session | Keeps you signed in | 7 days |
__Host-atoma_oauth_tx | Protects the sign-in exchange with your provider | 10 minutes |
__Host-atoma_mcp_return | Returns you to an MCP client's authorisation after sign-in | 5 minutes |
__Host-AtomaPreview | Lets you open the preview of a run's result | Until you close the browser |
__Host-AtomaHosted | Lets you open an application that Atoma hosts for your project | 5 minutes, renewed while you use it |
The web app also stores preferences in your browser (language, theme, the assistant model you chose, whether you dismissed a notification prompt) and keeps an offline copy of the app shell. These never leave your device.
Security
Traffic is encrypted with TLS. Organisations are isolated from one another, credentials are encrypted or hashed as described above, and model-written code runs in isolated containers. Atoma is under active development and has not been independently audited, so we cannot guarantee that no defect exists. Please report vulnerabilities as described on the support page.
Children
The service is not directed at children, and you must be at least 18 to use it.
Changes
When this policy changes, we update the date at the top of this page. For a significant change, we will also tell signed-in users in the app.