Suno's Training Data Is Now an Itemised List

One employee, one worm, the whole pipeline

The route into Suno was a single person's machine. A hacker infected an individual employee with a worm that harvested credentials for GitHub and for the company's cloud services, and from there reached the systems that mattered. What came out was not a customer database in the ordinary sense, although hundreds of thousands of customer records including email addresses and phone numbers were exposed, along with Stripe payment information. What came out was the source code from 2023 and 2024: the scripts that built the model, and the comments the engineers left for each other while building it.

This is the modern shape of a breach and it deserves to be understood as a category rather than an incident. Nobody attacked Suno's product. Nobody found a flaw in the model. Someone compromised a developer, and a developer's credentials open the repository, and the repository is where a company keeps the most candid account of what it actually did. Your security programme probably treats source code as intellectual property to be protected from competitors. The more expensive reading is that source code is a contemporaneous record of your decisions, written by people who assumed the only readers would be colleagues.

Suno's account of the timing is the part that should unsettle anyone running an incident process. The company says the intrusion occurred in November 2025, that it was quickly contained, and that no sensitive personal information was compromised. Take that at face value and it changes nothing about the outcome, because the material surfaced in July 2026, roughly eight months later, on a reporter's desk. Containment describes what you did to the attacker. It says nothing about the calendar of the person holding the copy, and they choose the publication date, not you.

The numbers the code was keeping

The specificity is what makes this different from every previous story about AI training data. A comment in one file lists the sources being pulled: genius_hq, youtube_music, freesound, jamendo, imp, deezer, ytm_tagged. A file named youtube_music records the ingestion of 2,013,545 music clips. Another set of comments enumerates the datasets by duration: 113,879 hours of youtube_music, 152,162 hours of ytm_tagged, 62,117 hours of pond5_music, 19,514 hours of material from the International Music Score Library Project, 17,615 hours of genius_hq, 12,287 hours of deezer, 3,726 hours of jamendo, 410 hours of freesound and 103 hours of musescore_lyrics. The code also describes filtering to strip out what was not music, and podcasts were pulled via RSS feeds.

Read those figures as an engineer would and they are mundane. Read them as a lawyer would and they are an inventory. Until now the argument about what AI music systems consumed has been conducted in adjectives. The rights holders said vast quantities. The companies said publicly available material. Both statements are unfalsifiable in a useful way, which suited everybody, because an abstraction can be argued about for years. A number cannot. Deezer is not a vague corner of the open internet; it is a named European service with a catalogue and terms, and the code says 12,287 hours.

There is also the matter of how the material was reached. The reporting indicates Suno may have used proxy services to pull music from YouTube, including acapella versions of songs, which are the isolated vocal stems that a model would want and that a listener would not casually find. Proxying is an ordinary engineering answer to rate limits and blocks. It is a considerably less ordinary fact when the question in front of a court is whether access was authorised, because a proxy exists to make a request look like it came from somewhere it did not.

Suno was not caught lying, which is worse

The company's statement after the breach is not a retraction. Suno said that, as it has stated in public filings and disclosures, its models have been trained on publicly available music files and related metadata accessible on third-party websites on the open Internet. Hold that sentence against the code and there is no contradiction. YouTube Music is on the open internet. So is Deezer, so is Genius, so is Jamendo. The company has previously said it trained on essentially all music files of reasonable quality accessible on the open internet, and has argued that this constitutes fair use. Everything the code shows is consistent with everything the company said.

That consistency is the problem, not the defence. The public sentence and the private comment describe the same act at two different resolutions, and only one of them can be cross-examined. A judge cannot do much with publicly available music files. A judge can do a great deal with 2,013,545 clips and a source-by-source ledger of hours, because that converts a question of characterisation into a question of scale, and scale is what damages are calculated from. Suno's legal position may well survive. Its negotiating position just changed, because the other side no longer has to prove the size of the thing.

The commercial history around the case shows exactly what is at stake. Record labels sued Suno for copyright infringement, and Warner Music Group subsequently withdrew from the action in exchange for a licensing deal. That is the tell. This dispute was never heading for a principled ruling on machine learning and copyright; it was heading for a set of licences at a price. Every fact that pins down how much was taken from whom is a fact that moves that price, and an itemised list with hour counts is the most price-moving document in the entire matter.

Your repository is a witness

Generalise past the music industry, because the mechanism has nothing to do with music. Any organisation training or fine-tuning a model has a pipeline, and that pipeline has sources, and somewhere a competent engineer has written down what those sources are and how much came from each, because that is what competent engineers do. It might be a comment, a dataset name, a configuration file, a row in a manifest. Under normal conditions that documentation is a sign of a well-run system. Under litigation, or under a breach, it is the clearest available statement of what the organisation ingested, authored by the organisation itself, in a tone that no communications team ever reviewed.

The gap that matters is between what your lawyers believe you did and what your repository records that you did. Those two accounts are written by different people, at different times, for different audiences, and only one of them is checked before it goes out. The engineer naming a bucket after the site it was scraped from is not being reckless. They are being precise, at a moment when nobody told them precision would be read aloud. If those accounts have drifted apart in your own company, a breach is one of several ways you find out, and it is the one where you learn at the same time as everybody else.

None of which argues for writing worse comments. An engineering culture that hides what it is doing from its own repository produces systems nobody can audit, and that failure costs more than any lawsuit. The argument is for closing the gap from the other end: know what your pipeline consumed, be able to state it in the same terms your code states it, and make sure the public sentence and the private comment describe the same act at the same resolution. If they do, a breach is a security incident. If they do not, it is a disclosure.

What to do with this before the quarter ends

Write down your model's provenance while it is still your document. For every model you train, fine-tune or commission, record which sources the data came from, on what authority, and roughly how much of each. If producing that list is difficult, that difficulty is the finding, and it is better to meet it now, in your own time, than during discovery or in a reporter's inbox. The organisations that will handle the next few years well are the ones whose answer to what did you train on is a document rather than an adjective.

Treat developer endpoints as the crown jewels, because they are. Suno lost its pipeline through one employee's credentials to GitHub and cloud services. The control that matters is not a bigger perimeter but the blast radius of a single compromised developer: phishing-resistant authentication on the code platform, short-lived cloud credentials rather than durable ones, and enough separation that one machine does not unlock the whole estate. That is unglamorous work with no product to buy, and it is the difference between an incident and an inventory.

Finally, stop treating containment as closure. Suno contained an intrusion in November 2025 and read about its own source code in July 2026. When data leaves, the exposure clock does not stop when the intruder is evicted; it stops when the copy is worthless, and the copy is worthless only when the facts inside it no longer matter. If you have had an incident that was contained but where data left, the honest status is not closed. It is pending, and someone else holds the release date.

Read next: TfL Paid No Ransom and Still Lost 29 Million  |  One Commit Is Not an Audit Trail