Who can legitimately read my source code and my customers' data?

This is not an article about being hacked. Everything in it is legitimate, disclosed and agreed to, which is exactly why it is worth an hour of your attention — nobody is going to alert you to access you granted yourself.

If you build software with AI tools, several companies can read some part of your work. That is not a scandal and it is not avoidable in any meaningful sense. What is avoidable is not knowing the list, because a few of the entries on it have settings, and at least one of them has a deadline that is close.

The date, first, because it is close

Lovable's documentation states that from 9 September 2026, content from free and Pro accounts — prompts, code, project files and outputs — may be used to train its models unless the account holder opts out. Business and enterprise accounts are excluded by default and, according to the same page, cannot switch it on. The setting is in account preferences under AI model training.

The mechanic that makes this time-sensitive is the asymmetry: opting out before the date prevents the use entirely. Opting out afterwards stops only future use.

I want to flag something honestly rather than presenting this more cleanly than the sources allow. When I checked, the company's documentation and its privacy policy did not read consistently on this point — the privacy policy, with an earlier effective date, does not carry the September date and describes a narrower position. I could not reconcile them. I have reported the documentation because it is the more specific and more recent statement, and because being wrong in this direction costs you nothing but a toggle.

Go and look at the setting. If it is not there, or reads differently, you have lost two minutes. If it is there, you have made a decision that becomes irreversible on a known date.

Why this is different if you have clients

If you build only for yourself, this is a preference and reasonable people will land on both sides of it.

If you build for other people, it may be an obligation. Contracts with confidentiality clauses, data processing agreements, anything in a regulated sector, anything where you told a client their work stays between you — a default that feeds project files into a training corpus is in tension with all of it, and the tension does not resolve just because nobody asked.

The concrete action: if you have signed anything promising confidentiality about work you built with these tools, read the clause again this week and set the toggle accordingly. This is a five-minute task that is much easier to do now than to explain later.

What the terms actually say about ownership

Since people ask, and since the answer is more reasonable than the folklore suggests.

Lovable's terms were updated on 16 June 2026 and took effect on 15 August 2026. In substance: you own the output generated for you, subject to third-party rights that may exist in the underlying models and their training data. There is a prohibition on using AI output unreviewed in medical, legal, financial and safety-critical contexts. Liability is capped at the fees you paid in the preceding twelve months. And credits are forfeited if the account is terminated for abuse.

Three observations.

The ownership position is normal and not alarming. "Subject to third-party rights in the models and training data" is a lawyer declining to promise something nobody can promise, not a claim on your work.

The liability cap is the one worth registering. If a platform failure costs your business fifty thousand, your contractual recourse is bounded by what you paid them, which for most readers of this article is a few hundred. That is standard across the industry, and it is also the argument for owning your own backups rather than relying on anybody's promises.

And the credits-forfeited clause connects to a scenario I have written about separately — the account action that takes your app and your data at the same time, which is locked out of your own app.

Your editor's vendor, which just changed hands

On 14 August 2026 Cursor announced it had been acquired by SpaceX, completing a process that began as a partnership earlier in the year.

I am going to be careful here, because there is a difference between a bad answer and no answer yet. The announcement is silent on product continuity, existing subscriptions, pricing, customer data handling, privacy and terms. That is not evidence of anything except that it was published two days ago at the time of writing.

What was true before the acquisition, from the previously published terms: suggestions are assigned to you, and your code is not used for training unless you agree to it. Those are good terms. What was also true, and is a separate matter from terms: your requests pass through the vendor's backend, files are temporarily cached in the course of serving them, and your codebase is chunked and embedded to make search work. That is how the product functions, it is disclosed, and it is not a criticism — but "they do not train on it" and "it never leaves your machine" are different claims, and only the first one was ever made.

The practical advice: if you are in a regulated sector or under a client confidentiality obligation, this is a relationship worth re-reading in a few months when there is something to read. Not a reason to switch tools today.

Your hosting provider, and what a real incident actually exposed

In April 2026 Vercel published a bulletin about a security incident, and the chain of events is instructive enough to be worth walking through.

A third-party AI tool used by an employee was compromised. That led to the hijack of the employee's workspace account. That was escalated into their Vercel account and from there into internal systems.

What was exposed for a limited subset of customers: environment variables that had not been marked sensitive — that is, the ones stored in a form that decrypts to plaintext. In practice that means API keys, tokens, database credentials and signing secrets, for anyone who had not used the sensitive-variable option. No customer count was published.

Sit with that for a second, because it is the most transferable lesson in this article. The blast radius was decided by a setting most affected people had never consciously chosen. Not by an attack technique, not by anything they did wrong, but by a default. The customers who had marked their variables sensitive had a boring week.

The action: go and mark your production secrets as sensitive if your platform offers it, and rotate anything that has been sitting in plaintext storage since before you read this. The remediation advice from that bulletin is still worth following in general: rotate, enable multi-factor authentication, review activity logs and recent deployments.

The terms change that makes you liable for your tools

In June 2026 Vercel updated its legal terms, and one change deserves attention from anybody wiring agents into their infrastructure: customers are made responsible for actions taken by Vercel's AI services and by connected third-party tools.

That is a reasonable position for a platform to take and it is also a meaningful shift in where risk sits. If you connect an agent to your hosting account and it does something expensive or destructive, that is contractually yours. Combined with the observation from the incident above — that a compromised AI tool was the first link in the chain — the message is fairly clear. Every AI tool you connect to an account with real credentials in it is a new party on your list, and now an explicitly indemnified one.

The one-hour pass

Nothing here requires a project. It requires an hour and a willingness to open five settings pages.

Set the training preference on your builder platform, before 9 September if that is the one you use.

Mark your production secrets as sensitive wherever the platform supports it, and rotate anything that has been in plaintext storage for a long time.

List every AI tool that has access to a real account — your repository, your hosting, your inbox, your database, your project tracker. Then revoke the ones you tried once and stopped using. Nearly everybody has two or three of these, and an unused integration holding live credentials is the worst possible ratio of value to risk.

Check what you promised anyone. Client contracts, data processing agreements, your own privacy policy. It is common to discover you have promised something more restrictive than what your tooling actually does, and that is much better to discover on a quiet Tuesday.

Separate personal and business accounts. If your company's production infrastructure is under a login you also use for hobby projects and a password manager you share with a family member, the list of people who can reach your customers' data is longer than any of the above.

The honest framing

You cannot use modern development tools and have zero third-party access to your work. Anyone selling you that is selling something, and the tools that avoid it are enough worse at the job that almost nobody actually uses them.

The realistic goal is different and entirely achievable: know who is on the list, and have chosen each one.

Most people building this way have never seen the list. Not because they were careless, but because it was never presented — it accumulated one signup at a time, each individually sensible. An hour spent writing it down puts you in a position where the next terms update or acquisition or incident is something you can assess rather than something that happens to you.

If you would rather have somebody map it for you

If you have read this and realised you could not actually produce that list, that is the normal position, particularly if somebody else set up any part of your stack.

I do a Production-Ready Audit that includes it: every third party with access to your code, your infrastructure or your data identified from the outside, what each one's current terms actually say about your work, which secrets are stored in a form that would be exposed in an incident, which integrations hold credentials nobody uses any more, and a written list of what to change with the reasoning for each. From $499, back in five to seven days.

You can also just tell me which platforms and tools you use, and I will tell you which of them have a setting worth checking, at no charge and with nothing attached.

The audit and remediation work is on the AI SaaS rescue page. The related question of what you can take with you when you leave a platform is in what you actually own when you export, and the harder version — what happens when the platform ends the relationship rather than you — is in locked out of your own app. If your concern is specifically about keys sitting somewhere they should not be, that is a different and more urgent check, and it is in are my API keys exposed.