Best Practices 7 min read 11 August 2026

AI Vendor Security: What the tl;dv Breach Teaches

A missing tenant-isolation rule left 181,874 meetings from an AI notetaker queryable by any logged-in stranger for six months after it was reported. If your business hands calendar, CRM, or call data to an off-the-shelf AI tool, you've made the same bet — without knowing it.

AI Vendor Security: What the tl;dv Breach Teaches

In January 2026, a security researcher told tl;dv — an AI notetaker plugged into Zoom, Google Meet, and Teams calls for tens of thousands of companies — that its database had no tenant-isolation rule. Any authenticated user, on any account, could query a shared Firestore collection and pull back meeting records belonging to every other customer: the organizer's email, the conferencing provider, timestamps, recording status, and a conference ID that pointed straight at the live call. The researcher followed up repeatedly through July. The company's CTO never responded. By the time it became public this month, 181,874 meetings across 84,312 users and 35,003 email domains — government agencies and corporations among them — had been sitting exposed for six months.

For any meeting still in recording status, that conference ID wasn't historical data. It was a door. An attacker watching the collection in real time could see a call start recording, grab the ID, and walk into someone's meeting uninvited. This is not a hypothetical about AI going wrong in the abstract — it's a concrete failure in a mainstream, well-funded AI product that thousands of small and mid-size businesses installed because it saved someone twenty minutes of note-taking a day.

This Is a Pattern, Not an Outlier

The tl;dv disclosure landed in the same week an Australian user's AI agent found an unpatched flaw in a gym booking app and used it to jump the class waitlist by canceling another member's spot — a small, almost funny example of the same underlying issue: AI systems now have enough autonomy and tool access that a single overlooked permission boundary turns into a real-world incident. It's also the same week OpenAI expanded Daybreak, its AI-driven cyber defense platform, directly responding to Anthropic's Mythos — both labs racing to build AI that can find and fix these holes faster than attackers exploit them. When the frontier labs are building dedicated defensive AI because the offensive side is outpacing manual review, that's a signal about the maturity of the entire AI tooling ecosystem your business is plugging into, not just one vendor's bug.

The actual problem

tl;dv is not an obscure product. It's a well-reviewed, VC-backed AI meeting assistant that plenty of legitimate businesses trusted with their calendars and conversations. If a breach this basic — a missing tenant filter on a database query — can sit unfixed for six months at a company like that, the assumption that "the vendor has security handled" is not a safe default for any AI SaaS tool, no matter how polished the product looks.

What You Actually Hand Over When You Adopt an AI Tool

Most small businesses don't think of an AI notetaker, AI scheduling assistant, or AI inbox tool as a security decision — it's a productivity decision, approved by whoever tried the free trial and liked it. But every one of these tools requests scopes that, pooled together, add up to a full picture of how your business operates:

  • Calendar access — who you meet, how often, and with whom, across your entire company
  • Meeting audio, video, and full transcripts — including anything discussed with clients, candidates, or your own team in confidence
  • CRM and contact data — every prospect, client, and deal detail the tool needs to "personalize" its output
  • Email content, in tools that summarize or draft on your behalf
  • A live connection to the platform itself, in agentic tools with standing permission to take actions, not just read data

None of that is unreasonable for the tool to request — it's what makes the product useful. The problem is that almost no SMB has a process for evaluating whether the vendor is actually isolating that data correctly, and "the app works great and the trial was free" tells you nothing about whether a tenant-isolation bug is sitting in production right now.

A Short Vendor Security Checklist Before You Adopt the Next AI Tool

You don't need a security team to ask better questions before rolling out an AI tool company-wide. Five questions catch most of what matters:

  1. 1How is my data isolated from other customers' data — is it a shared database with row-level rules, or genuinely separate storage? (A missing rule in the first model is exactly what broke tl;dv.)
  2. 2What happens when a researcher or customer reports a vulnerability — is there a published response SLA, and can you find evidence they've honored it before?
  3. 3Does the vendor train its models on your data by default, and is opting out actually enforced, not just a checkbox in a settings page?
  4. 4Who are the subprocessors — which other companies and infrastructure providers touch your data downstream of the tool you're signing up for?
  5. 5If this tool were breached tomorrow, what specifically would be exposed — and would you find out from the vendor, or from a security researcher's blog post six months later?

If a vendor can't answer the first two clearly, that's the answer. It doesn't mean don't use AI tools — it means don't skip the five-minute question just because the demo was smooth.

Off-the-Shelf vs. Purpose-Built: Where the Risk Actually Lives

The deeper issue is architectural, not just a checklist item. Off-the-shelf AI SaaS tools pool customers into shared infrastructure by design — that's how they keep the price low enough for an SMB to swipe a credit card and self-serve. Your data sits in the same database as thousands of other companies', separated only by application logic that, as tl;dv proved, can have a hole in it. You have no visibility into that logic and no ability to audit it. You're trusting a stranger's code review process with your client conversations.

A custom-built AI agent — one scoped, architected, and deployed specifically for your business — doesn't remove risk, but it changes who controls it. Data isolation, access scoping, and what the agent is actually permitted to touch become decisions your implementation partner makes deliberately, for your environment specifically, instead of inherited defaults baked into a product built for the widest possible customer base.

How Wizeb Approaches This

This is why Wizeb treats data isolation and access scoping as an architecture decision made before a single workflow is built, not a settings toggle checked after the fact. When we design a custom AI agent — for meeting intelligence, document processing, or customer-facing automation — the agent only gets read or write access to the specific systems and records the task requires, nothing broader, and your data isn't pooled behind a shared multi-tenant layer built for someone else's threat model. Every agent we deploy comes with a plain-language answer to "what could this touch if something went wrong," before it goes live, not after.

A realistic scenario

A 25-person recruiting firm had every client and candidate call running through a popular AI notetaker for over a year, syncing transcripts straight into their CRM. When a client asked, during a security review ahead of a contract renewal, exactly how that data was isolated from the vendor's other customers, nobody at the firm could answer — and the vendor's support team took ten days to reply with a generic privacy-policy link. Wizeb rebuilt the workflow as a scoped custom agent: call transcription and CRM sync running on infrastructure dedicated to the firm, with access limited to the specific calendar and CRM fields the workflow needed. The client's security review passed on the resubmission, and the firm now has a documented answer to give the next client who asks.

Three Questions Before Your Next AI Tool Purchase

Before your team adopts the next AI notetaker, scheduling assistant, or agent tool, ask:

  1. 1What is this tool allowed to access, and does that access match what it actually needs to do its job — or is it broader "just in case"?
  2. 2If this vendor had tl;dv's exact bug, would you find out from them, or from a researcher's writeup months later?
  3. 3Is the convenience of a $20-a-month self-serve tool worth pooling your client conversations into infrastructure you can't inspect — or does this workflow deserve to be built on infrastructure your business actually controls?

AI tools aren't going away, and they shouldn't — the productivity gains are real. But six months of exposed meetings at a mainstream vendor is a reminder that "AI-powered" is not a security credential, and the businesses that get burned aren't the ones using AI — they're the ones who never asked how it was built. If you want a second opinion on the AI tools already running inside your business, or you're ready to build something with the access controls scoped to your business specifically, that's exactly the conversation to start at wizeb.com/services/ai-agents.

Ready to act on this?

We build exactly what this article is about.

Tell us about your situation — we'll come back with a realistic assessment.