Your code stays in your repository
Loom writes its output as files your team reviews and commits, or as pull requests. Nothing is kept anywhere you cannot leave. Partial What does not work yet: opening pull requests automatically, with checks on each, has been built and tested against simulated git hosts but not yet used on a client repository.
Loom never merges. Your branch protection stays in force.
The least access that works
The Loom GitHub App asks for three permissions only: repository metadata (read), code (read, and write only to Loom's own branches) and pull requests (to open draft pull requests). Every access token covers one repository, and Loom refuses a token that grants more. Loom never needs to administer a repository, change workflows, read secrets or merge. Partial
What the GitHub App may do, and nothing more
From the codeOpens labelled, AI-disclosed draft pull requests with Loom's design-system changes for human review. Never merges, never changes settings, CI or secrets.
| Operation | Code | Pull requests | Metadata |
|---|---|---|---|
| Audits and scans | read | none | read |
| Posting a report on a pull request | read | write | read |
| Opening Loom's draft pull requests (on Loom's own branches) | write | write | read |
Never requested: administration, workflows, secrets, checks write, or merge.
github-app/manifest.json and src/git-host/github-app.ts when this page is built; a unit test checks that every token stays inside the manifest.What does not work yet: the App is not yet registered on GitHub. Until it is, we use a fine-grained token with the same limits that expires at the end of the engagement.
GitLab and Azure DevOps use the same interface and the same labelled draft changes. Partial What does not work yet: they have been tested against simulated hosts only.
Agents run where you choose
Today the command line and the MCP server run on your own machines. Your code stays inside your infrastructure, except for what your chosen model provider receives under your own account. Partial A packaged CI step and Loom cloud are planned. Concept
For the first pilot, we plan to run Loom in the client's own CI, so that code does not leave the client.
The MCP server is closed by default
Over a network, the server requires a secret token of at least 32 characters, compared in constant time, and refuses to start without one. Without a token it listens only on the local machine. Working Run one server per client: one token opens every project on a server.
Your files cannot instruct the agent
Tool results that quote your repository, docs or Figma are fenced, neutralised and marked as untrusted data, not instructions. This lowers the risk of prompt injection. It does not remove it. Working
Every AI output is labelled
Drafts, reports and generated files carry a machine-readable label. This is the real label at the top of the takenote audit report:
{"schema": "loom.provenance/1.0.0", "generator": "loom-conversion",
"model": null, "provider": null, "ai_generated": false,
"human_reviewed": false, "label": "loom:agent-generated",
"method": "Deterministic static analysis of the repository (no AI model)"}
The label records whether the output is AI- or machine-generated, the model and provider when reported, and that no person has reviewed them yet. Reports say plainly when no model was used. Working Working Pull requests Loom opens carry the loom:agent-generated label and a disclosure. Partial What does not work yet: Loom opening pull requests has not yet been used on a real repository. This follows the transparency duties of the EU AI Act (Article 50).
Costs and actions are capped
Every tool call is logged. The log keeps fingerprints of inputs and outputs, not your code. You can cap a run by calls, tokens or estimated cost. Working
Deleted at the end of an engagement
Every clone, cache and derived file of an engagement is kept in one place. One command deletes it all, checks that nothing remains and writes a receipt with a fingerprint of each deleted file. Partial What does not work yet: it has not yet been used in a client engagement.
Survey answers only the consultant can read
In a discovery, team survey answers are encrypted in the respondent's browser to the consultant's key before they leave it. Nothing is posted to Loom. No group smaller than five people is shown on its own. Partial
The health check sends only what it says
Only your contact details, profile and area scores leave the browser, and only if you ask for the full report. Working Report requests are kept for 12 months, then deleted. A daily deletion job is built and tested. Partial What does not work yet: the job is not yet running; until it runs, we delete on request.
No training on your data
We do not use your code, designs, prompts or outputs to train models, and we never sell or share them. Our commitment
What we do not have yet
We do not hold ISO 27001 or SOC 2 certification today. We will answer your security questionnaire directly.
Draft documents are available on request while they are with our lawyer: a security overview, a data processing agreement, the list of sub-processors, an AI use policy and an incident response plan. They are drafts, not signed commitments. Ask for them through the contact form.
Your code and your designs stay yours. Every control on this page says whether it works today.
Questions
Can we run Loom without giving you any access? Yes. You can run Loom yourself in your own environment, with an App you create and keys that stay in your secrets.
Where is data stored? Your system stays in your repository. Health check report requests are stored in a Cloudflare database. Engagement working copies stay with the engagement and are deleted at its end.
How do we report a security issue? Through the contact page. We confirm receipt and keep you informed.