Who we are
m82 Labs (“we”, “us”) builds a developer tool that watches third-party APIs for breaking changes, finds the code in your repositories those changes affect, writes a fix with an AI agent, and opens a pull request carrying the evidence. The product is called m82 Labs.
m82 Labs is the data controller for the personal data described in this policy. For the contents of your repositories, you or your organisation remain the owner and we act on your instructions, which are the permissions you grant on GitHub’s own consent screen.
The closed beta
This policy covers a closed beta open to a small invited group. During the beta:
- Billing runs in test mode. You enter a card on a checkout page hosted by Stripe and no real charge is made. We never see your card number, and we do not copy the billing email you enter there.
- We may ask for your feedback by email or in a call. It is used only to shape the product and is never attached to your repository data.
- At the end of the beta we will tell you what happens next. If the product does not continue, we delete every installation’s data as described in section 11 within 30 days, without you having to ask. If it does, this policy is updated before any production launch.
- Adding a subprocessor is a notification, not a deploy. If we add anyone to the list in section 6, we email you before that party receives any data.
What we collect
Your account
You sign in with GitHub. There is no separate signup form and no password. From GitHub we receive and store:
| Data | Why | Notes |
|---|---|---|
| GitHub user ID | Your identity in our system | Handles can change; this cannot. It is the only field we treat as identity. |
| GitHub handle, display name, avatar | Showing you who is signed in | Name and avatar are optional on GitHub, so they are optional here. Refreshed on every login. |
| Primary email | Sending alert emails about detected changes | Only if GitHub shares it. Nothing in the product requires it. You can turn alert emails off in settings. |
| OAuth tokens | Checking which organisations and installations you are allowed to see | Encrypted at rest and short-lived. Used only to ask GitHub what you may access, never to touch a repository. |
| Last login time | Deciding when to ask you to sign in again |
When your organisation installs our GitHub App, GitHub sends us the installation ID, the organisation’s name and ID, and the names and IDs of the repositories you selected. GitHub’s consent screen is the only place you pick repositories, so the grant you see there is exactly the scope we hold.
Your repositories
Four kinds of data derived from your code leave your repository, and nothing else does. How long each is kept is in section 7.
| Leaves your repository | Goes to | Why |
|---|---|---|
| Symbol names, file paths, line numbers | Our database | The index that lets us find which repositories a vendor change touches, without re-scanning every repository each time |
| Vendor markers | Our database | Which files reference a vendor we watch, so we know which vendors you use. No values are collected. The evidence view shows you the exact files these came from so you can check the claim yourself |
| Excerpts of files at confirmed call sites | Anthropic’s API | The agent cannot write a fix without reading the code it is fixing. Only the affected call sites and the context around them are sent, not the repository |
| The diff the agent produced | GitHub, as a pull request | This is the product |
| Run logs: commands, exit codes, test output, the agent’s raw output | Our object store | So you can inspect what the agent saw and did when a pull request looks wrong, and so we can measure how often our pull requests are correct |
What never leaves
| Never collected, stored, logged, or transmitted | How that is enforced |
|---|---|
The contents of .env or any real-value environment file | Never opened by the indexer or the agent. Any change touching .env* fails the run. |
| The value of any credential | Where a committed example file is read to identify a vendor, any value in it is discarded on the spot. It is never written to a database row, a log line, or a pull request. |
| The contents of Markdown files | Not read at all. Documentation is not code we need to fix. |
| Anything outside the repositories you selected on GitHub | The token used to clone is scoped to one repository for about an hour. There is no wider token to misuse. |
| File contents, diffs, or vendor specifications in application logs | Logs carry repository names, file paths, and IDs, which are already visible in the pull request. Content lives only in the object store. |
Website visitors
If you only visit this site, we count the visit and nothing more. We use Google Analytics 4 with consent set to “denied” for every visitor and never granted, the mode Google documents as cookieless: the tag sets no cookie, stores nothing in your browser, and sends a ping carrying the page you viewed, the site that referred you, your browser’s user agent, and a coarse location derived from your IP address, which Google does not store. Google Signals and advertising personalisation are off, so nothing is joined to a Google account or an ad profile. We see totals: page views, referrers, countries, and whether a visit ended with a waitlist signup, never the address that signed up. There is no other script and no third-party embed. If you join the waitlist, we store the email address you enter and send one acknowledgement to it. It is not linked to any account or repository.
How we use it
- To run the product: detect vendor changes, match them to your code, write a fix, open a pull request, and email you when we found something but chose not to open a pull request.
- To show you evidence: every pull request links to the run log and the files that produced the match, so you can verify the change rather than trust us.
- To measure precision: the only number we optimise is how many of our pull requests are correct. We compute it over structured records: change type, confidence score, outcome, and whether you merged, closed, or edited the pull request.
- To keep the service secure and working: debugging, abuse prevention, and spend caps.
We do not use your data for advertising, we do not sell it, we do not share it with data brokers, and we do not build profiles of you. We do not train any machine learning model on your source code, and we do not permit our model provider to do so.
The AI agent and your code
The fix is written by an AI agent running Anthropic’s Claude models. This is the part of the product most worth understanding, so here is what is guaranteed and how.
The agent has no network access beyond the model API, and no credentials of any kind.
Enforced byThe agent's environment is built empty and filled deliberately, never inherited from the machine. Before the agent starts, we check that no credential of any kind is present and abort the run if one is. That check is covered by automated tests.
The agent can only edit files in one directory. Git, tokens, and the decision to open a pull request all sit outside it.
Enforced byAfter the agent exits, we check its diff against a fixed list of forbidden paths and a limit on how far the change may reach, then run your tests ourselves. What appears in the pull request body is our test run, not the agent's own report.
Your code and vendor text are treated as untrusted input to the model.
Enforced byFile contents and changelog prose are placed in explicitly labelled untrusted blocks, never mixed into instructions. Model output is checked against a fixed schema and against the vendor specification we observed. A model-only judgement never opens a pull request.
So the honest worst case is this: a fully compromised agent, whether by prompt injection in a code comment, a model failure, or a bug in our code, cannot exfiltrate anything, because it has nowhere to send it and nothing to authenticate with. It can at most produce a bad diff, which is caught by the diff checks, by our test run, and finally by a human who has to press merge.
What Anthropic receives
Anthropic receives three things: the vendor’s changelog prose (which is public), excerpts of your files at the confirmed call sites, and the diff as the agent constructs it. We use Anthropic’s commercial API under terms that do not permit Anthropic to train on this data, and we have not opted in to any training or feedback programme. Anthropic’s own retention of API inputs is governed by its commercial terms and its data processing agreement, not by us.
Who else receives data
These are the only parties that process data on our behalf. This list is versioned, and adding to it means we email you first.
| Processor | Role | Receives | Repository content? |
|---|---|---|---|
| Anthropic | Model provider for the agent and the change classifier | Public changelog prose, file excerpts at confirmed call sites, the diff under construction | Excerpts |
| Fly.io | Hosting for our services and the throwaway machine each job runs in | Everything we store, encrypted at rest. The job machine holds a clone of one repository for the life of one job, then is destroyed | Transient clone |
| Tigris | Object storage | Vendor specification snapshots, run logs, run diffs, raw webhook payloads | Run logs |
| Upstash | Job queues and a short-lived token cache | Job IDs and encrypted GitHub installation tokens that expire within the hour | None |
| GitHub | Identity, authorisation, and delivery of pull requests | The pull request, its branch, and its body. GitHub already holds your code | Yours already |
| Stripe | Subscription billing | Billing identifiers and the card and email you enter on Stripe's page. Never repository data | None |
| Google (Analytics 4) | Visit counting on the public site, consent denied, cookieless | Page URL, referrer, user agent, and a coarse location from your IP address, which is not stored. Nothing from the app after you sign in | None |
| Resend | Email delivery | Recipient address, vendor and repository names, a one-line change summary, and the reason for the match. Waitlist acknowledgements: the address only | None |
Beyond this list, we disclose data only if the law requires it, to protect the rights and safety of you, us, or others, or to a successor if m82 Labs is acquired. In that last case we notify you before your data transfers and you can delete it first.
How long we keep it
Retention follows one question: when someone asks why we edited their code, can we show them what we saw? Data that answers that question is kept until you ask us to delete it. Data that does not is deleted on a schedule, and the schedule is enforced by storage lifecycle rules and checked by tests, not by someone remembering.
| Data | Retention | Reason |
|---|---|---|
| Run logs and run diffs | 90 days | Your repository material. Kept long enough for you to audit a pull request, no longer |
| Raw GitHub webhook payloads | 30 days | Organisation and repository names, for debugging deliveries |
| GitHub installation tokens | About an hour | Encrypted, and expired automatically |
| Your OAuth access token | Hours | Rotated on every login |
| Session cookie | 30 days | Or until you sign out |
| Symbol index, vendor markers, change and pull request records | Until you ask us to delete it | The evidence behind every pull request we opened. Uninstalling stops all processing but does not delete this; section 11 says why |
| Vendor specification snapshots a change cites | Indefinite | Public vendor documents, not your data. Kept as evidence that a change happened |
| Waitlist address | Until you ask | Or until you are invited and sign in, when the account record takes over |
| Account record | Until you ask | Deleted on request |
Security
- Ephemeral compute. Every job runs on a machine created for that job and destroyed afterwards. There is no shared filesystem and no worker reuse.
- Narrow tokens. The token used to clone is scoped to one repository for about an hour and is removed from the clone before the agent starts. Compromising a job machine costs one repository for one hour.
- Encryption. All traffic uses TLS. Tokens are encrypted at rest.
- Verified after the fact. Forbidden paths (
.github/workflows/,.env*,.git/) are checked on the actual diff after the agent exits, not requested in a prompt. - Incident notice. If we discover a breach affecting your data, we notify affected organisations within 72 hours of confirming it, with what was affected and what we did.
If you find a security issue, email contact@m82labs.dev. We will acknowledge within two business days. Customers who need more detail on how these controls are built can ask at the same address.
Cookies and tracking
We set one cookie, and only after you sign in with GitHub. It holds a sealed session that tells the app who you are and lasts 30 days or until you sign out. It is strictly necessary for the app to function, so no consent banner is shown for it.
The public site counts visits with Google Analytics 4 in consent-denied mode, described in section 3 under “Website visitors”. It sets no cookie and keeps no identifier, which is why there is no consent banner: there is nothing to consent to. We use no advertising or social pixels, no session recording, and no fingerprinting, on the site or in the product.
Your rights and choices
Wherever you are, you can exercise these by emailing contact@m82labs.dev. We answer within 30 days and never charge for it. If you are in the UK, EEA, or Switzerland these are your rights under data protection law; if you are in California they correspond to your rights under the CCPA. We treat every requester the same regardless of location.
- Access
- A copy of the personal data we hold about you, and the indexed symbols and paths for your repositories.
- Correction
- Your profile fields come from GitHub and refresh on login. Fix them there and sign in again.
- Deletion
- Everything in section 11, on request, with the two exceptions stated there.
- Portability
- Your indexed data and change history as JSON.
- Restriction and objection
- Turn off alert emails in settings. Deselect a repository on GitHub to stop all processing of it immediately.
- Complaint
- You may complain to your local supervisory authority. We would rather hear from you first, but that is your choice, not a condition.
We do not sell or share personal information as those terms are defined under the CCPA, and we do not use it for targeted advertising. We do not discriminate against anyone for exercising these rights.
Uninstalling and deletion
Uninstalling the GitHub App revokes our access immediately. No token can be minted, no clone can be made, and nothing further is processed. Deselecting a single repository has the same effect for that repository.
Uninstalling does not delete your data; asking does. We keep the index and records after an uninstall so that the evidence behind pull requests we already opened stays available to you. Email us to delete it, and we delete for your installation: the symbol index, vendor markers, run logs, run diffs, notification records, and your account record. The same deletion runs automatically at the end of the beta if the product does not continue. Deletion completes within 30 days.
Two things survive, and you should know before you ask.
- Pull requests we opened live in your own repository and are yours. We cannot and should not delete them.
- A labelled evaluation case derived from a run may survive as a purely structural record: the change type, the confidence score, the outcome, and the label. It contains no repository content, no symbol names, and no file paths. If that distinction is not acceptable to you, say so and we remove those cases too. The measurement is not worth a trust failure.
International transfers
Our infrastructure runs in the United States, and every processor in section 6 is a US company. If you are in the UK, EEA, or Switzerland, your data is transferred to the United States. We rely on the EU-US Data Privacy Framework where a processor is certified, and on Standard Contractual Clauses in our agreements with processors otherwise. A copy of the relevant clauses is available on request.
Legal bases
| Processing | Basis |
|---|---|
| Running the product on the repositories you selected, opening pull requests, alert emails | Performance of our contract with you or your organisation |
| Security, debugging, and precision measurement | Our legitimate interest in operating a safe, correct service. We have weighed this against your interests, and the data involved is minimised as described in section 3 |
| Counting visits to the public site | Our legitimate interest in knowing whether the site is read. The counter keeps no identifier and sets no cookie, which is what keeps the interest proportionate |
| Beta feedback you choose to give | Your consent, withdrawable at any time by asking us to delete it |
| Billing records | Legal obligation, where tax or accounting law requires retention |
Children
The product is for software teams and requires a GitHub account. It is not directed at anyone under 16 and we do not knowingly collect data from children. If you believe we have, contact us and we will delete it.
Changes to this policy
This is version 1.3, written for the closed beta. We will update it before any production launch. If a change reduces your protections, adds a subprocessor, or changes what leaves your repository, we email every account holder at least 14 days before it takes effect. Smaller clarifications are noted here. Continuing to use the product after the effective date means the new version applies; if you disagree, uninstall and ask us to delete your data.
Versions 1.1 and 1.2 (5 September 2026) added the cookieless visit counter on the public site, before the first account holder existed. Version 1.3 (7 September 2026) shortened the policy, removed implementation detail that described how controls are built rather than what they guarantee, and corrected two retention rows that said data was deleted on uninstall: it is deleted on request, as section 11 always said. No promise was removed, and no subprocessor changed.
Contact
m82 Labs
Email: contact@m82labs.dev (privacy requests and security reports)
Web: m82labs.dev
If any statement in this policy stops being true of the running system, that is a bug in the system and we will fix the system, not the wording. Tell us if you find one.