Why Tenant Isolation Breaks Later: 180,000 Meetings and One Missing Rule

Hello, this is Ryuta Hamamoto from TIMEWELL.

A vulnerability in an AI notetaking service has been published. Over 180,000 meeting records were readable by users from other organisations.

The number is large enough that the natural reading is "another sloppy vendor." Reading the report, that turns out not to be the story. Within the same system, nine of ten containers were correctly protected. Exactly one was not.

And that failure mode, dropping exactly one, is structurally present in every company building multi-tenant services, ours included. It is not something to file under other people's problems, so let me take it in order.

This is not written for engineers. It aims to give someone evaluating a SaaS product a sense of what to ask the vendor.

What happened

According to a report published on 4 August 2026 by security researcher BobDaHacker, one container in the database holding meeting metadata at the AI notetaker tl;dv had no cross-tenant access control configured¹.

The result was that any authenticated user could read meeting records belonging to other organisations on the platform. The scope: 181,874 meeting records, 84,312 users, 35,003 email domains. Government bodies in 23 countries, several universities and a large number of companies were reported to be among the meetings covered¹.

The visible fields included the creator's email address, recording status, timestamps, and the meeting ID. That last one is the awkward part, because it was the number you use to join the Google Meet or Teams room. As a demonstration the researcher actually joined two live meetings he had not been invited to: one a 157-person meeting at Malaysia's Ministry of Education, the other a 21-person meeting at a US university spinout where a screen was being shared¹.

The report was made on 28 January 2026. Six months had passed at publication¹. After publication tl;dv indicated that the issue had been resolved shortly after the report, and the researcher responded that it still reproduced six months later. That factual disagreement stands. This article does not adjudicate it. What is worth looking at is the structure that produced the hole.

Multi-tenancy, in apartment terms

One piece of vocabulary.

Multi-tenancy means one system shared by many customer organisations. Picture an apartment building. The structure, the lift and the plumbing are shared; each company uses only its own unit. The partition between units is what is called tenant isolation.

The reason SaaS is cheap is this sharing. Standing up a separate server for every customer costs far more. So multi-tenancy is not a flaw; it is the premise of modern cloud services.

But it means safety rests on that partition. One gap and you can see into the next unit. That is precisely what happened.

If you want to place your own organisation on the AI adoption curve first, the AI readiness check will help you map what follows onto your own situation.

Nine were locked. One was not.

This is the heart of it.

Per the researcher's account, nine containers in the same system covering users, chats, transcripts, clips, recordings, videos, notes, teams and organisations were all correctly denying access¹. The video itself was protected. So were the transcripts of the conversations.

What was not protected was the meeting metadata, one container.

So this is not "a company that disregarded security left everything open as you would expect." It is an organisation that held the design intent of isolation, implemented most of it correctly, and dropped exactly one.

I find that more unsettling, not less. If getting nine out of ten right still produces an incident, then most companies are standing in the same place.

There is a second lesson attached. What was exposed was not "the video" but "the metadata." Metadata is not the real thing, so it matters less is a widespread instinct. Except that this metadata contained the meeting ID. What was sitting there was not the contents but the key to the contents.

Classify sensitivity as "primary data versus incidental data" and you will step on this every time. The test is not what is written in a field but what that field lets you do. Meeting IDs, invite links, share tokens, guessable file paths. None hold content on their own. All function as keys.

Why the hole opens later

Something that was properly isolated at design time develops a gap as revisions accumulate. This is not laziness. It is the product of a few forces. Three of them.

One: the design locks only where you wrote a lock.

If protection rules are written per container, one at a time, then what you have is "the places you explicitly closed are closed." When a new container appears, if nobody writes anything, it is open.

That structure penalises fast-moving organisations, because containers are added faster than rules are written. The correct shape is the inverse: declare deny-by-default at the root, and pass only what you explicitly allow. Then a new container starts closed without anyone doing anything. That single design difference decides where you end up after five or ten years of operation.

And this kind of hole is not caught by compliance badges.

Security pages for services like this typically carry a row of certification and encryption badges. Those are not lies. But this exposure was the result of a database responding to an authenticated session as an authorised request.

• Third-party certification attests to the existence of a process, not to the correctness of the implementation in every container, every route and every new feature
• Encryption at rest protects against someone without the decryption key, not against someone the authorisation check let through

"Certified, therefore safe" does not hold. Certification is a floor, not a ceiling.

Incidentally, we make a point of not listing certifications we do not hold in our own product descriptions. It is the sort of thing companies that can list them are tempted to lean on, so I will say it explicitly.

Two: feature work keeps generating legitimate reasons to cross the boundary.

As a product matures, these requests always arrive. We want search across the whole company. Administrators want a usage dashboard for the whole organisation. We need bulk export. We want to recommend similar cases. The query is slow, so let us build an aggregate table.

Every one of these is a legitimate business requirement. And every one of them demands an implementation that crosses tenant boundaries. No malice, no shortcuts, and the reasons for a gap keep stacking up. Aggregate tables and caches built for speed are especially dangerous. The source table may carry the identifier that marks which organisation a row belongs to, and it very often falls off the derived aggregate. The boundary has to hold not "where you first drew it" but everywhere data is copied or reshaped.

Three: building got faster, so the surface keeps growing.

The report comes with a coda. An internal World Cup prediction app at tl;dv had an unauthenticated API exposing the names and corporate email addresses of 19 of its own employees¹. Internal, a bit of fun, temporary. Something built with that framing sat under a production domain and became a real attack surface.

Generative AI has cut the cost of building this kind of casual surface dramatically. Building got faster, so closing has to be automatic or it will not keep up. Which returns you to the first point.

Adding AI changes the shape of the leak

Here is the part that matters most to those of us working with AI.

AI features inherently want to cross. A search index is more accurate and more efficient built across tenants. A knowledge graph earns its value by connecting nodes. Features that surface "similar cases" and "comparable past matters" are most useful precisely when they cross a boundary. Embeddings, summaries and caches drop the structure of the source data and store it in another form.

So adding AI brings in that second force in its strongest available form. And because there are more intermediate representations, there are more places for the organisation identifier to fall off.

The nature of the damage changes as well.

Classic tenant isolation incidents meant "another organisation's data is searchable." Put AI in the path and another tenant's data enters the context passed to the model, and the model volunteers it. No attacker has to probe for anything. An ordinary user asks an ordinary question and someone else's information ends up in the answer.

Detection gets harder too, because the access logs contain nothing but normal questions.

For a multi-tenant SaaS with AI features, then, I would treat the following as mandatory. Split the index by tenant, or at minimum partition before the search rather than filtering after it (filtering afterwards causes both quality degradation and disclosure the moment your top-k candidates are eaten by another tenant's data). Carry the organisation identifier through embeddings, summaries, caches and every intermediate artefact, and test that it has not vanished. Put a layer immediately before the model that asserts tenant consistency on the context being passed in.

General cautions about handing internal data to AI are in the risk of giving data straight to LLM vendors.

Three questions a buyer can ask

Finally, three things to ask from the buying side. None require you to be an engineer.

One: "when you add a new feature, is it closed or open by default?" A company that answers immediately is running deny-by-default. "We write rules each time" means the force described above is at work. Not good or bad; just a fact to have.

Two: "do you verify that tenants cannot cross, with automated tests?" Is there something that mechanically takes A's credentials, reaches for B's data and confirms the refusal? Manual testing repeats the same failure mode as manual rules: someone forgets to write the test for the new thing.

Three: "on average, how long from a vulnerability report to a fix?" The heaviest part of this case was not the misconfiguration but the time after the report. Misconfigurations happen. Any team, however good, will drop one eventually. Security maturity is not measurable by whether vulnerabilities exist. What is measurable is the time from being told to being closed.

We run ZEROCK on AWS servers in Japan and control who can reach which knowledge because we want that line inside the product rather than outside it. Meetings, internal documents and review processes are all going to be handed to AI services at an accelerating rate. What the party handing them over should be asking is not "which certifications do you hold" but "is the boundary closed by default" and "how many hours until you move when told."

If you want to talk through how to hand over your own knowledge base, you can reach us here.

---

Footnotes

1. Public report by security researcher BobDaHacker (published 4 August 2026). The absence of cross-tenant access control on the meetings collection in the Firestore database used by tl;dv, leaving records readable by any authenticated user; the scope of 181,874 meeting records, 84,312 users and 35,003 email domains; the exposed fields including creator email address, meeting ID (a joinable Google Meet or Teams room), provider information, recording status and timestamps; the users, chats, transcripts, clips, recordings, videos, notes, teams and organizations collections each correctly returning 403; the demonstration joins into a 157-person meeting at Malaysia's Ministry of Education and a 21-person meeting at a US university spinout; the report date of 28 January 2026 and the position that it remained unfixed at publication; and the internal application at worldcup.tldv.io whose /api/entities/Player endpoint returned, without authentication, data including the names and corporate email addresses of 19 of the company's own employees, are all from that report. https://bobdahacker.com/blog/tldv-hack — after publication, tl;dv indicated that the issue had been resolved shortly after the report, and the researcher responded that it still reproduced six months later. That disagreement stands, and this article does not adjudicate it. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶