Draft — under review

Data and privacy

Your code, your keys, your model. How we handle data.

Your repo and Figma stay the sources of truth. Loom governs them and flags anything that drifts. This page explains what we store, where it lives, how long we keep it and who else is involved.

This is a draft for the closed demo and our first pilots. It is not yet a contract. For a paid engagement, the signed terms and data processing agreement take precedence. Last updated 25 October 2026.

In short

  • Your design system lives in your repository. Loom’s output reaches it as files or pull requests that your team reviews. Loom never merges. Loom opening draft pull requests itself is built and tested, but not yet used on a client repository.
  • Agents run where you choose. Today that is your own machines; a packaged CI step and Loom cloud are planned.
  • Agents use your model and your keys: Anthropic Claude, OpenAI or any OpenAI-compatible gateway.
  • We do not use your code, designs, prompts or outputs to train models, and we never sell or share them.
  • Drafts and reports that Loom generates are labelled, in a machine-readable way, as AI- or machine-generated and not yet reviewed by a person.
  • Every Loom tool call is logged, and you can cap how many calls, tokens and how much spend a run may use.

What we store, and where

On this website and in the free health check. While you answer, everything stays in your browser. If you ask for your full report, we receive your name, work email, company and role, your profile (role, team size, organisation size and starting point) and your score for each area. Your individual answers and your free-text note never leave your browser. This data is stored in a Cloudflare D1 database. The site uses no tracking cookies and no advertising tools. See the health check privacy notice.

Spam protection on the report form. The form uses Cloudflare Turnstile to block spam: Cloudflare processes your IP address and browser details (user agent and TLS fingerprint) to tell people from bots. We hold IP addresses briefly in memory for rate limiting and never store them. Built, switching on The check is built and tested and its secret key is set on the live site; it runs from the first release that includes it.

In a client engagement. The converted system (tokens, component contracts, rules, governance and documentation) is written to your repository, where you control it. Loom keeps working copies of audit reports, drafts and evidence only for the engagement, so that the work can be reviewed and repeated.

What we do not store. We do not keep copies of your source code beyond the working copies an engagement needs, and we do not keep your model provider’s keys when agents run in your CI.

How long we keep it

Health check details: 12 months, then deleted, unless we are working together by then and you have agreed otherwise. You can ask for a copy or for deletion at any time. A daily job that deletes details older than 12 months is built and tested Built, not yet running. It starts when the site goes live; until then, we delete on request.

Engagement working copies: deleted at the end of the engagement, with a written confirmation. Everything you need stays in your repository. Every clone, cache and derived file of an engagement is kept in one place, and one command deletes it all, checks that nothing remains and writes the confirmation: what was deleted, when, and a fingerprint of each file Built, not yet used in an engagement.

Where agents run

On your own machines Working. The Loom command line and MCP server run on your own machines, from a copy of the Loom repository. Your code stays inside your infrastructure, except for what your chosen model provider receives under your account. If you share the MCP server over a network, it requires a secret access token on every request and refuses to start without one Working. This is a shared secret, not the MCP authorisation standard (OAuth), so hosted agents that need OAuth cannot connect yet.

In your CI Planned. Your CI can run the same commands from a copy of the repository today. A packaged command line with a ready-made CI step is planned.

In Loom cloud Planned. If you would rather we run the agents, they will run in Loom cloud with access limited to the repositories you select. The processing region will be stated in the engagement terms.

Repository access. We ask for the least access that works, and read-only by default. The Loom GitHub App asks for three permissions only: repository metadata (read), code (read, and write only to create Loom’s own loom/ branches) and pull requests (to open draft pull requests). Every access token covers one repository and only what the task needs, and Loom refuses a token that grants more. Write access is added only if you want pull requests, and only for the repositories you select. Loom never needs to administer a repository, change workflows, read secrets or merge, and your branch protection stays in force. You can also run Loom yourself and give us no access at all; when Loom runs in your CI, it uses an App you create with the same permissions, and its key stays in your secrets. The Loom GitHub App is Built, not yet registered; until it is registered, we use a fine-grained token with the same limits that expires at the end of the engagement. Access is revoked at the end of the engagement.

Bring your own model

Agents use your model and your keys: Anthropic Claude, OpenAI, or any OpenAI-compatible gateway, including one your organisation already runs. Your provider’s terms apply to what the model sees. Where your provider offers zero data retention, we recommend turning it on.

Any agent that speaks MCP can already use your system with the model you choose Working. Setting up providers for agents that Loom runs for you is In development. Loom’s checks give the same answer whichever model produced a result. Today agents call them as tools; making them a required step before review is planned.

Cost controls Working. Every call to a Loom tool, through MCP or the conversion command line, is written to a run log: which tool, how long it took, the model and provider, token counts and a cost estimate. The log keeps fingerprints of inputs and outputs, not your code. You can cap a run by number of calls, tokens or estimated cost, and Loom refuses further calls once a cap is reached. Loom’s current tools do not call a model themselves, so the token figures are estimates of what their answers add to your agent’s context, and cost estimates use the prices you configure.

No training on client data

We do not use your code, designs, prompts, outputs or health check answers to train or fine-tune any model. We do not sell or share your data. We use it only to deliver the work you asked for.

AI transparency

We follow the transparency duties of the EU AI Act (Article 50), which apply from 2 August 2026.

  • Drafts written by agents through Loom carry a machine-readable label: AI-generated, the model and provider when the agent reports them, the time, and that no person has reviewed them yet Working.
  • Conversion reports and generated files carry the same label, plus a visible note in every Markdown file. They state plainly when no AI model was used Working.
  • Pull requests built from Loom output carry the label loom:agent-generated and a disclosure in the description. When Loom opens a pull request itself, it applies both, naming the model and provider when the agent reports them, and the run fails if the label is missing Built, not yet used on a client repository. When a person opens the pull request, they apply them.
  • Autonomy modes per area are a concept in design. Until they exist, every change waits for a person: this matches Suggest, the planned default. Pilots do not use full autonomy.
  • The Japanese version of this site is an AI draft translation, and each Japanese page says so until a native speaker has reviewed it.

Sub-processors

Placeholder list, to be confirmed before the first pilot.

ProviderPurposeWhen
CloudflareWebsite hosting, the database for health check reports and the spam check on the report form (Turnstile)Always
Your model provider (Anthropic, OpenAI or your gateway)Runs agentsUnder your own account when agents run in your CI; listed in your engagement terms if Loom cloud runs them
GitHub, or your Git hostRepository access through pull requestsDuring an engagement, under your organisation’s account
Email provider (to be confirmed)Sending your report and replying to youWhen you contact us or ask for a report

Security contact

If you find a security issue in this website, the health check or Loom’s tools, please write to hello@loom.example with the details. We will confirm that we received it and keep you informed. Please do not access data that is not yours, and give us reasonable time to fix the issue before you share it publicly.

Our contact details for security reports are also published in security.txt, following RFC 9116. The address above is a placeholder until our domain is registered.