Skip to content

Services, Wiki-Artikel und Blog-Beiträge durchsuchen

↑↓NavigierenEnterÖffnenESCSchließen
Shadow AI in the workplace: identifying and managing risks
Security Awareness

Shadow AI in the workplace: identifying and managing risks

The tl;dv incident of 2026: 181,874 meeting metadata records without tenant isolation. How an approval process including a DPA check provides protection.

Chris Wojzechowski Managing Director
Updated: August 11, 2026 8 min read read
IT-Grundschutz-Praktiker (TÜV) IT Risk Manager (DGI) § 8a BSIG Prüfverfahrenskompetenz Ausbilderprüfung (IHK) T.I.S.P. Board-Mitglied

TL;DR

Shadow AI has a different risk profile in 2026 than it did in 2023. The tl;dv incident shows that the risk lies with the provider who stores meeting recordings. Protection is provided by an authorisation process including a data processing agreement (DPA) check in accordance with Article 28 of the GDPR.

Table of Contents (7 sections)

What is Shadow AI?

Shadow AI refers to AI tools that employees use within a company without IT authorisation or a data protection assessment. The term is closely related to Shadow IT, but specifically covers systems that generate or process content autonomously. The spectrum ranges from text and code generation, through image generators, to automatic meeting recorders. In 2026, the main risk no longer lies in the prompt, but with the provider who automatically stores and processes meeting recordings.

In 2023, the dominant question was: What data ends up in the provider’s training corpus? This risk persists. Specialised AI meeting recorders automatically record conversations, transcribe every sentence and store the result with the provider. Participants do not make a conscious decision - not even if the recorder was introduced into the call by another person.

A meeting recorder runs as a bot in the background. It requires no local installation. Tools without IT approval are not visible to the IT department; they receive no notification and have no opportunity to respond.

The tl;dv incident: 181,874 meeting metadata records without tenant isolation

tl;dv deploys a bot into Google Meet, Zoom or Teams, records, transcribes and summarises. In January 2026, a security researcher reported a misconfiguration in the provider’s Firestore database.

The meetings collection lacked tenant isolation. All other collections - users, transcripts, recordings - responded correctly with an HTTP 403. Only in the meetings collection could any authenticated user query metadata from other accounts: organiser’s email, conference ID, provider, recording status, timestamp.

181,874 meeting records belonging to 84,312 users from 35,003 email domains were stored in the exposed collection. This included government appointments from 23 countries with .gov domains.

The conference ID of an ongoing meeting is a room that can be joined. At any given time, around 1,000 meetings were in recording mode. The researcher retrieved a conference ID from the database and joined an ongoing meeting of the Malaysian Ministry of Education with over 157 participants. The tl;dv bot was already on the list of participants.

Of the 27,334 meeting IDs examined, over 1,000 were configured as public. These provided full transcripts as well as 715 participants’ email addresses from 228 domains. Around 69,000 meetings examined were protected by correct privacy settings.

The researcher reported the vulnerability on 28 January 2026. The CTO of tl;dv never replied. Follow-up enquiries in March and July 2026 failed to change this. A press enquiry from Dark Reading also went unanswered. The provider’s security page promises SOC 2, GDPR compliance, EU AI Act compliance, EU hosting, AES-256 and a response within 24 hours via privacy@tldv.io.

A compliance seal is no substitute for an independent audit. The tl;dv case shows that providers can claim SOC 2, GDPR certification and EU hosting whilst simultaneously ignoring a known misconfiguration for months.

Detecting Shadow AI

Meeting recorder bots do not require local installation and run as a cloud service in the background of the video conferencing client. The use of a tool such as tl;dv is invisible to the IT department - the bot only appears in the list of participants. No installation process, no helpdesk ticket, no entry in the software asset management system.

Technical detection approaches operate at several levels. Network monitoring reveals connections to domains of known AI providers, provided that access is routed via the corporate network. Endpoint detection systems identify browser extensions or processes that unexpectedly transmit data externally. Cloud Access Security Brokers (CASBs) catalogue the cloud services in use, flag unauthorised applications and help to comprehensively map the software portfolio actually in use.

Purely technical detection reaches its limits as soon as employees work via personal devices or mobile data plans. Anonymous surveys or moderated discussion formats often provide clearer insights than any technical log - because employees who do not fear consequences are more open in their reporting. The Shadow IT Management Guide describes both technical and organisational approaches in detail.

6 Signs of unauthorised AI use

  1. Individual employees’ writing style or code format changes noticeably.
  2. Content contains clichéd phrasing or factual errors that suggest it has been generated by AI.
  3. Network monitoring reveals regular connections to AI provider domains.
  4. Employees refer to tools that are unknown to the IT department.
  5. Personal devices or VPN access are being used more intensively than before.
  6. Project decisions or content can no longer be clearly traced.

Who reviewed the data processing agreement?

Under Article 28(1) of the GDPR, every organisation must enter into a data processing agreement before using an AI service for the first time. If this is missing, the processing of personal data is formally unlawful.

A data processing agreement would not have prevented the Firestore misconfiguration at tl;dv. However, it would have ensured that the affected client organisations were informed. Without authorisation, the organisation will not be made aware of an incident at the provider’s end. Compliance with the obligation to notify the supervisory authority cannot then be verified. The actual safeguard is the authorisation process.

What is data processing on behalf of a controller?

Data processing on behalf of a controller, as defined in Article 28 of the GDPR, occurs when an external service provider processes personal data on behalf of the controller. The controller must enter into a data processing agreement (DPA) for this purpose. This sets out the service provider’s obligations, the controller’s right of audit and the obligations to provide evidence under Article 28(3)(h) of the GDPR.

Article 32(1)(d) of the GDPR also requires a procedure for regularly reviewing the effectiveness of technical and organisational measures.

Approval process: What a usage policy does not achieve

An AI meeting recorder stores everything said during the call, regardless of the prompt. This applies to all participants, not just those who have activated the recorder.

An approval process for AI tools must include at least the following:

  1. Identify data categories: What information does the tool process?
  2. Enter into a data processing agreement with the provider and ensure auditability in accordance with Article 28(3)(h) of the GDPR
  3. Check whether a data protection impact assessment is required under Article 35 of the GDPR
  4. Fulfil information obligations under Article 13 of the GDPR towards meeting participants
  5. Check technical configuration: Are recordings set to private by default with the provider?

Measures: Governance, Technology and Training

The approval process for individual tools forms the operational core. For this to be effective, it requires an organisational framework - otherwise, individual measures will remain ineffective. Five building blocks complement one another:

  1. A governance framework specifies which AI categories may be used under which conditions. IT, data protection, specialist departments and senior management make decisions jointly. This prevents unilateral decisions within individual teams and ensures commitment.

  2. A usage policy defines which categories of data must not be entered into external systems. It must be easily accessible and clearly worded. General prohibitions without explanation are ignored.

  3. Vetted tools are officially authorised with a GDPR-compliant configuration and a documented data processing agreement (DPA). Those who can use a reliable, authorised alternative are less likely to resort to unauthorised services. Whitelisting is more effective than blanket bans.

  4. DNS blocking or proxy filters restrict access to unauthorised services. DLP (Data Loss Prevention) systems detect sensitive data before it reaches external systems. Both measures operate at different points in the data flow and complement one another.

  5. Training sessions convey not only rules, but also the reasons behind them. Staff who have a concrete understanding of what happened during the tl;dv incident act differently than they would if following an abstract policy. Practical formats - short learning modules, live demonstrations of attack vectors - are better retained than manuals alone.

Context

At the time of publication of this article, the misconfiguration at tl;dv had been reported for over six months and remained unresolved. Compliance claims on the provider’s website are no substitute for an independent audit - and no certificate can replace a verified data processing agreement. Anyone deploying AI tools must assess them regularly in accordance with Article 32(1)(d) of the GDPR - not just once upon introduction, but as an ongoing process.

Next Step

Our certified security experts will advise you on the topics covered in this article — free and without obligation.

Free · 30 minutes · No obligation

Share this article

About the author

Chris Wojzechowski
Chris Wojzechowski

Managing Director

E-Mail

Managing Director of AWARE7 GmbH with many years of expertise in information security, penetration testing and IT risk management. Graduate of the Internet Security master's program at Westfälische Hochschule (if(is), Prof. Norbert Pohlmann). Bestselling author with Wiley-VCH and lecturer at the ASW-Akademie. His assessments of cybersecurity and digital sovereignty have appeared in Welt am Sonntag, WDR, Deutschlandfunk and Handelsblatt, among others.

10 Publikationen
  • Einsatz von elektronischer Verschlüsselung - Hemmnisse für die Wirtschaft (2018)
  • Kompass IT-Verschlüsselung - Orientierungshilfen für KMU (2018)
  • IT Security Day 2025 - Live Hacking: KI in der Cybersicherheit (2025)
  • Live Hacking - Credential Stuffing: Finanzrisiken jenseits Ransomware (2025)
  • Keynote: Live Hacking Show - Ein Blick in die Welt der Cyberkriminalität (2025)
  • Analyse von Angriffsflächen bei Shared-Hosting-Anbietern (2024)
  • Gänsehaut garantiert: Die schaurigsten Funde aus dem Leben eines Pentesters (2022)
  • IT Security Zertifizierungen - CISSP, T.I.S.P. & Co (Live-Webinar) (2023)
  • Sicherheitsforum Online-Banking - Live Hacking (2021)
  • Nipster im Netz und das Ende der Kreidezeit (2017)
IT-Grundschutz-Praktiker (TÜV) IT Risk Manager (DGI) § 8a BSIG Prüfverfahrenskompetenz Ausbilderprüfung (IHK) T.I.S.P. Board-Mitglied
Certified ISO 27001ISO 9001AZAV

Rufen Sie uns an

Mo-Fr, 8:00-17:00 Uhr - persönlich und unverbindlich.

0209 8830 6764
Jetzt anrufen